I''ve got a working shorewall implementation - it starts and everything, and i''ve also configured the traffic shaping rules. Everything *appears* to work, but the problem i''m having is that most traffic appears to be escaping my marks - and go out via the default rule. Built into the kernel i''ve already got the SIP conntrack module, and the IPP2P module - but they don''t seem to be tracking much. Is something wrong with my iptables? Or is it a configuration problem with shorewall? Or is it actually working, but just outputting wrong? (evidence attached - renamed to .txt) Shorewall version 3.4.6 Gentoo Linux 2.6.22-gentoo-r9 Any help appreciated, thanks. Terence ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Sat, 2007-12-22 at 00:59 +0800, Terence Parker wrote:> I''ve got a working shorewall implementation - it starts and > everything, and i''ve also configured the traffic shaping rules. > > Everything *appears* to work, but the problem i''m having is that most > traffic appears to be escaping my marks - and go out via the default > rule. > > Built into the kernel i''ve already got the SIP conntrack module, and > the IPP2P module - but they don''t seem to be tracking much. > > Is something wrong with my iptables? Or is it a configuration problem > with shorewall? Or is it actually working, but just outputting wrong? > > (evidence attached - renamed to .txt) > > Shorewall version 3.4.6 > Gentoo Linux 2.6.22-gentoo-r9 > > Any help appreciated, thanks.Several things: a) You are marking in the PREROUTING chain. That means that: 1. You are not marking traffic that originates on the firewall. 2. You are marking traffic that enters the firewall on your external interface (input traffic). You might want to move your marking to the FORWARD chain where you could mark P2P in both directions but only mark the other traffic outbound. You don''t appear to have significant traffic generated by processes running on the firewall itself so the first issue probably isn''t a big concern. b) From the dump: Mangle Table Chain PREROUTING (policy ACCEPT 317K packets, 225M bytes) pkts bytes target prot opt in out source destination 317K 225M tcpre all -- * * 0.0.0.0/0 0.0.0.0/0 So 317K packets entered your firewall (from all interfaces) Chain POSTROUTING (policy ACCEPT 315K packets, 227M bytes) pkts bytes target prot opt in out source destination 315K 227M tcpost all -- * * 0.0.0.0/0 0.0.0.0/0 Hence, 315K packets left the firewall (on all interfaces) Chain tcpre (1 references) pkts bytes target prot opt in out source destination 23 2615 MARK icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8 MARK set 0x6 2 956 MARK icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 0 MARK set 0x6 317K 225M CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x0/0xffff CONNMARK restore mask 0xff 306K 224M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match !0x0/0xffff 11617 736K MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK set 0x1 So of the 317K that entered your firewall, 306K of them had a connection mark already or were echo-request/response. The remaining 11k got an initial mark of 1. They then went through the rest of the rules where you''ve got ONE CHANCE to mark them. Because at the end, you save the mark so that no packets from the connection will go through the marking rules again. I have three suggestions: a) Move the marking to the FORWARD chain. b) Get rid of the unconditional rule that marks all packets with 1. c) Except for the ipp2p rule, you only want to execute the other marking rules if the output interface is ppp0. HTH, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Thanks Tom for the detailed reply ~ much appreciated! Just a quick question about your suggestion (b) - I did this thinking I could set a lower priority for traffic that I can''t identify (since i''ve specified specifically which traffic I want higher priority on). Or should I not do this? What happens to unspecified traffic if I remove the unconditional rule, in terms of priority? Thanks again, Terence On 22 Dec 2007, at 1:39 AM, Tom Eastep wrote:> I have three suggestions: > > a) Move the marking to the FORWARD chain. > b) Get rid of the unconditional rule that marks all packets with 1. > c) Except for the ipp2p rule, you only want to execute the other > marking > rules if the output interface is ppp0. > > HTH, > -Tom > --------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Terence Parker wrote:>Just a quick question about your suggestion (b) - I did this thinking >I could set a lower priority for traffic that I can''t identify (since >i''ve specified specifically which traffic I want higher priority on). >Or should I not do this? > >What happens to unspecified traffic if I remove the unconditional >rule, in terms of priority?When setting up TC, there is (in my setup anyway *) a definition in the qdisc setup specifying the default class for unclassified traffic. * I have TC configured in tcstart, directly configuring TC rather than indirectly via Shorewall. It was copied from the ''Wondershaper'' config given in the Linux Advanced Routing & Traffic Control howto (google for LARTC). This is my tcstart file># clean existing down- and uplink qdiscs, hide errors >tc qdisc del dev eth0 root 2> /dev/null > /dev/null >tc qdisc del dev eth0 ingress 2> /dev/null > /dev/null > ># install root HTB, point default traffic to 1:20: >run_tc qdisc add dev eth0 root handle 1: htb default 20 > ># shape everything at uplink speed - this prevents huge queues in your ># DSL modem which destroy latency: >run_tc class add dev eth0 parent 1: classid 1:1 htb rate xxxxkbit burst 6kbit > > ># high priority class 1:10: >run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate xxxxkbit >ceil xxxxkbit burst 6kbit prio 1 > ># medium priority class 1:20: >run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate xxxxkbit >ceil xxxxkbit burst 6kbit prio 2 > ># low priority class 1:30: >run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate xxxxkbit >ceil xxxxkbit burst 6kbit prio 3 > ># extra-low priority class 1:40: >run_tc class add dev eth0 parent 1:1 classid 1:40 htb rate 50kbit >ceil xxxxkbit burst 6kbit prio 4 > > ># Give each class stochastic fair queuing >run_tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 >run_tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 >run_tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10 >run_tc qdisc add dev eth0 parent 1:40 handle 40: sfq perturb 10 > ># Filter by Firewall marks into classes : >run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw >flowid 1:10 >run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 2 fw >flowid 1:20 >run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw >flowid 1:30 >run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 4 fw >flowid 1:40 > > >########## downlink ############# ># slow downloads down to somewhat less than the real speed to prevent ># queuing at our ISP. Tune to see how high you can set it. ># ISPs tend to have *huge* queues to make sure big downloads are fast ># ># attach ingress policer: >run_tc qdisc add dev eth0 handle ffff: ingress > ># filter *everything* to it (0.0.0.0/0), drop everything that''s ># coming in too fast: >run_tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 >match ip src 0.0.0.0/0 police rate xxxxkbit burst 10k drop flowid :1And then my tcrules file contains rules like this :># DNS >1 0.0.0.0/0 0.0.0.0/0 udp 53 >1 0.0.0.0/0 0.0.0.0/0 udp - 53 >1 0.0.0.0/0 0.0.0.0/0 tcp 53 >1 0.0.0.0/0 0.0.0.0/0 tcp - 53 ># ># SMTP Traffic >3 0.0.0.0/0 0.0.0.0/0 tcp 25 >3 0.0.0.0/0 0.0.0.0/0 tcp - 25 >#------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Terence Parker wrote:> > What happens to unspecified traffic if I remove the unconditional > rule, in terms of priority? >They are placed in the outgoing interface''s default class as specified in /etc/shorewall/tcclasses. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/