Hi there, first of all thanks for this nice peace of software. I have a problem with traffic shaping and ipsec with nat traversal at the same time. When traffic shaping is disabled ipsec works just fine. Phase 1 completes and switches over to UDP Port 4500 and encapsulates all ESP packets. As soon as I activate shorewall internal traffic shaping, ipsec stops working. Phase 1 is still starting but racoon is not switching to port 4500 even though it does detect that the peer is natted. I tested this with (kernel-2.6.13.7 with ipsec patches from 2.6.12, iptables-1.2.11) and (kernel-2.6.16-rc[56], iptables-1.3.5) both with ipsec-tools-0.6.5, iproute-20051007 and shorewall-3.0.5. No packets seem to be dropped. The racoon daemon runs on the firewall itself. Here is a short log from racoon NOT working: Mar 13 08:03:57 rancor racoon: INFO: respond new phase 1 negotiation: 194.25.18.68[500]<=>84.179.31.165[64194] Mar 13 08:03:57 rancor racoon: INFO: begin Identity Protection mode. Mar 13 08:03:57 rancor racoon: INFO: received Vendor ID: RFC 3947 Mar 13 08:03:57 rancor racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 Mar 13 08:03:57 rancor racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 Mar 13 08:03:57 rancor racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00 Mar 13 08:03:57 rancor racoon: INFO: received Vendor ID: DPD Mar 13 08:03:57 rancor racoon: INFO: Selected NAT-T version: RFC 3947 Mar 13 08:03:57 rancor racoon: INFO: Hashing 194.25.18.68[500] with algo #2 Mar 13 08:03:57 rancor racoon: INFO: NAT-D payload #0 verified Mar 13 08:03:57 rancor racoon: INFO: Hashing 84.179.31.165[64194] with algo #2 Mar 13 08:03:57 rancor racoon: INFO: NAT-D payload #1 doesn''t match Mar 13 08:03:57 rancor racoon: INFO: NAT detected: PEER Mar 13 08:03:57 rancor racoon: INFO: Hashing 84.179.31.165[64194] with algo #2 Mar 13 08:03:57 rancor racoon: INFO: Hashing 194.25.18.68[500] with algo #2 Mar 13 08:03:57 rancor racoon: INFO: Adding remote and local NAT-D payloads. Mar 13 08:04:57 rancor racoon: ERROR: phase1 negotiation failed due to time up.12213c977784b270:fae1f4067c711e9e and the same without traffic shaping enabled: Mar 13 12:10:41 rancor racoon: INFO: respond new phase 1 negotiation: 194.25.18.68[500]<=>84.179.31.165[62889] Mar 13 12:10:41 rancor racoon: INFO: begin Identity Protection mode. Mar 13 12:10:41 rancor racoon: INFO: received Vendor ID: RFC 3947 Mar 13 12:11:07 rancor racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 Mar 13 12:11:07 rancor racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 Mar 13 12:11:07 rancor racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00 Mar 13 12:11:07 rancor racoon: INFO: received Vendor ID: DPD Mar 13 12:11:07 rancor racoon: INFO: Selected NAT-T version: RFC 3947 Mar 13 12:11:07 rancor racoon: INFO: Hashing 194.25.18.68[500] with algo #2 Mar 13 12:11:07 rancor racoon: INFO: NAT-D payload #0 verified Mar 13 12:11:07 rancor racoon: INFO: Hashing 84.179.31.165[62889] with algo #2 Mar 13 12:11:07 rancor racoon: INFO: NAT-D payload #1 doesn''t match Mar 13 12:11:07 rancor racoon: INFO: NAT detected: PEER Mar 13 12:10:41 rancor racoon: INFO: Hashing 84.179.31.165[62889] with algo #2 Mar 13 12:10:41 rancor racoon: INFO: Hashing 194.25.18.68[500] with algo #2 Mar 13 12:10:41 rancor racoon: INFO: Adding remote and local NAT-D payloads. Mar 13 12:11:07 rancor racoon: INFO: NAT-T: ports changed to: 84.179.31.165[62853]<->194.25.18.68[4500] Mar 13 12:11:07 rancor racoon: INFO: KA list add: 194.25.18.68[4500]->84.179.31.165[62853] Is this a known problem and how does traffic shaping interact with ipsec? Interestingly enough does ipsec work without nat traversal. Here is my traffic shaping config: /etc/shorewall/tcclasses: eth2 1 10kbit 100kbit 1 eth2 2 full/4 full 2 tcp-ack,tos-minimize-delay eth2 3 full/4 full 3 default eth2 4 full/8 full*8/10 4 /etc/shorewall/tcdevices: eth2 1936kbit 1936kbit /etc/shorewall/tcrules: 1:P $FW 0.0.0.0/0 tcp - 20248 1:P $FW 0.0.0.0/0 udp - 20248 1:P 0.0.0.0/0 0.0.0.0/0 tcp 20248 - 1:P 0.0.0.0/0 0.0.0.0/0 udp 20248 - 2:P 0.0.0.0/0 0.0.0.0/0 tcp 22 Cheers Jan ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
On Tuesday 14 March 2006 00:46, Jan Wagner wrote:> /etc/shorewall/tcrules: > 1:P $FW 0.0.0.0/0 tcp - 20248 > 1:P $FW 0.0.0.0/0 udp - 20248Is Shorewall even starting with these rules -- the above two rules aren''t valid! You can''t specify ":P" with $FW as the source. -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
> > /etc/shorewall/tcrules: > > 1:P $FW 0.0.0.0/0 tcp - 20248 > > 1:P $FW 0.0.0.0/0 udp - 20248 > > Is Shorewall even starting with these rules -- the above two rules aren''t > valid! You can''t specify ":P" with $FW as the source.Hi, shorewall sure did start. I corrected the rules to this (my first time traffic shaping ;-): 1 $FW 0.0.0.0/0 tcp - 20248 1 $FW 0.0.0.0/0 udp - 20248 2 0.0.0.0/0 0.0.0.0/0 tcp 22 The effect stays the same. As soon as I enable traffic shaping ipsec with nat traversal (racoon) stops working. Cheers Jan ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
On Wednesday 15 March 2006 00:18, Jan Wagner wrote:> > > /etc/shorewall/tcrules: > > > 1:P $FW 0.0.0.0/0 tcp - 20248 > > > 1:P $FW 0.0.0.0/0 udp - 20248 > > > > Is Shorewall even starting with these rules -- the above two rules aren''t > > valid! You can''t specify ":P" with $FW as the source. > > Hi, > > shorewall sure did start. I corrected the rules to this (my first time > traffic shaping ;-): > > 1 $FW 0.0.0.0/0 tcp - 20248 > 1 $FW 0.0.0.0/0 udp - 20248 > 2 0.0.0.0/0 0.0.0.0/0 tcp 22 > > The effect stays the same. As soon as I enable traffic shaping ipsec > with nat traversal (racoon) stops working.We''re going to have to see the details -- there is no reason in principle why that should occur. I use traffic shaping with NAT traversal all of the time; the only differences is that my IPSEC endpoint is behind the firewall. -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
> We''re going to have to see the details -- there is no reason in principle why > that should occur. I use traffic shaping with NAT traversal all of the time; > the only differences is that my IPSEC endpoint is behind the firewall.Here we go, attached you''ll find the output of "shorewall dump". Hope that helps. Jan
On Thursday 16 March 2006 05:03, Jan Wagner wrote:> > We''re going to have to see the details -- there is no reason in principle > > why that should occur. I use traffic shaping with NAT traversal all of > > the time; the only differences is that my IPSEC endpoint is behind the > > firewall. > > Here we go, > > attached you''ll find the output of "shorewall dump". Hope that helps. >Given that this is 2.6.16-rc6, I think that I would report this problem on the netfilter-devel list. There is a lot of new code in ipsec/netfilter interaction in 2.6.16. -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
On Thursday 16 March 2006 07:57, Tom Eastep wrote:> On Thursday 16 March 2006 05:03, Jan Wagner wrote: > > > We''re going to have to see the details -- there is no reason in > > > principle why that should occur. I use traffic shaping with NAT > > > traversal all of the time; the only differences is that my IPSEC > > > endpoint is behind the firewall. > > > > Here we go, > > > > attached you''ll find the output of "shorewall dump". Hope that helps. > > Given that this is 2.6.16-rc6, I think that I would report this problem on > the netfilter-devel list. There is a lot of new code in ipsec/netfilter > interaction in 2.6.16.In case my wording wasn''t clear, I''m suggesting that *you* report this problem to the netfilter developers. -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
> Given that this is 2.6.16-rc6, I think that I would report this problem on the > netfilter-devel list. There is a lot of new code in ipsec/netfilter > interaction in 2.6.16.Hi, as I said in my first mail. This problem persists if I switch to 2.6.13.7 and iptables-1.2.11. So i doesn''t seem to be kernel related. Jan ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
On Thursday 16 March 2006 21:29, Jan Wagner wrote:> > Given that this is 2.6.16-rc6, I think that I would report this problem > > on the netfilter-devel list. There is a lot of new code in > > ipsec/netfilter interaction in 2.6.16. > > Hi, > > as I said in my first mail. This problem persists if I switch to > 2.6.13.7 and iptables-1.2.11. So i doesn''t seem to be kernel related. >Ok -- let me be completely clear about the problem definition. If you simply set TC_ENABLED=No in the Shorewall configuration *and change nothing else*, does it work? -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
> Ok -- let me be completely clear about the problem definition. If you simply > set TC_ENABLED=No in the Shorewall configuration *and change nothing else*, > does it work?So to be clear: TC_ENABLED=No works regardless of kernel and iptables, TC_ENABLED=Internal does NOT work regardless of kernel, iptables and even racoon. Took me half a day to go back to 2.6.13 and test all that out. I first thought as you, that it was kernel dependent. But once I was back the problem was still there. The only thing that did not change were the iproute tools (20051007). Could they be the problem? I could test with an older version (20041019 is in debian/stable, my version is self compiled) but not before a couple of hours ahead). The other thing could be some kernel option I enabled in both kernels. I just activated every thing concerning iptables that was not experimental. Cheers Jan ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
On Friday 17 March 2006 08:13, Jan Wagner wrote:> > Ok -- let me be completely clear about the problem definition. If you > > simply set TC_ENABLED=No in the Shorewall configuration *and change > > nothing else*, does it work? > > So to be clear: TC_ENABLED=No works regardless of kernel and iptables, > TC_ENABLED=Internal does NOT work regardless of kernel, iptables and > even racoon. Took me half a day to go back to 2.6.13 and test all that > out. I first thought as you, that it was kernel dependent. But once I > was back the problem was still there. > > The only thing that did not change were the iproute tools (20051007). > Could they be the problem? I could test with an older version (20041019 > is in debian/stable, my version is self compiled) but not before a > couple of hours ahead). > > The other thing could be some kernel option I enabled in both kernels. I > just activated every thing concerning iptables that was not > experimental.In the iptables library directory (usually /usr/lib/iptables), please rename libipt_CLASSIFY.so to libipt_CLASSIFY.so.keep and "shorewall restart" with TC_ENABLED=Internal. Does it work then? -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
> In the iptables library directory (usually /usr/lib/iptables), please rename > libipt_CLASSIFY.so to libipt_CLASSIFY.so.keep and "shorewall restart" with > TC_ENABLED=Internal. Does it work then?Hi, sorry for the late answer. I tried the above, but it did not work. Shorewall starts up normally, but racoon still stays at port 500 while it switches to port 4500 with TC_ENABLED=No. Jan ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
On Monday 20 March 2006 03:06, Jan Wagner wrote:> > In the iptables library directory (usually /usr/lib/iptables), please > > rename libipt_CLASSIFY.so to libipt_CLASSIFY.so.keep and "shorewall > > restart" with TC_ENABLED=Internal. Does it work then? > > Hi, > > sorry for the late answer. I tried the above, but it did not work. > Shorewall starts up normally, but racoon still stays at port 500 while > it switches to port 4500 with TC_ENABLED=No.Then I don''t know what else to suggest. Without the CLASSIFY module, TC_ENABLED=No and TC_ENABLED=Internal generate exactly the same Netfilter ruleset. So the problem is in the traffic shaping configuration/ruleset. Arne -- would you take a look at this problem and see if you notice anything. Thanks, -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
On Monday 20 March 2006 07:12, Tom Eastep wrote:> On Monday 20 March 2006 03:06, Jan Wagner wrote: > > > In the iptables library directory (usually /usr/lib/iptables), please > > > rename libipt_CLASSIFY.so to libipt_CLASSIFY.so.keep and "shorewall > > > restart" with TC_ENABLED=Internal. Does it work then? > > > > Hi, > > > > sorry for the late answer. I tried the above, but it did not work. > > Shorewall starts up normally, but racoon still stays at port 500 while > > it switches to port 4500 with TC_ENABLED=No. > > Then I don''t know what else to suggest. Without the CLASSIFY module, > TC_ENABLED=No and TC_ENABLED=Internal generate exactly the same Netfilter > ruleset. So the problem is in the traffic shaping configuration/ruleset. >Jan, Did you happen to verify that CLASSIFY was disabled using "shorewall show capabilities"? -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
> > > sorry for the late answer. I tried the above, but it did not work. > > > Shorewall starts up normally, but racoon still stays at port 500 while > > > it switches to port 4500 with TC_ENABLED=No. > > > > Then I don''t know what else to suggest. Without the CLASSIFY module, > > TC_ENABLED=No and TC_ENABLED=Internal generate exactly the same Netfilter > > ruleset. So the problem is in the traffic shaping configuration/ruleset.> Did you happen to verify that CLASSIFY was disabled using "shorewall show > capabilities"?Hi Tom, just checked again: CLASSIFY Target: Not available I noticed one message in the kernel log: kernel: Ingress scheduler: Classifier actions prefered over netfilter Thanks for trying to help! Jan ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
On Monday 20 March 2006 08:21, Jan Wagner wrote:> > > > sorry for the late answer. I tried the above, but it did not work. > > > > Shorewall starts up normally, but racoon still stays at port 500 > > > > while it switches to port 4500 with TC_ENABLED=No. > > > > > > Then I don''t know what else to suggest. Without the CLASSIFY module, > > > TC_ENABLED=No and TC_ENABLED=Internal generate exactly the same > > > Netfilter ruleset. So the problem is in the traffic shaping > > > configuration/ruleset. > > > > Did you happen to verify that CLASSIFY was disabled using "shorewall show > > capabilities"? >> I noticed one message in the kernel log: > > kernel: Ingress scheduler: Classifier actions prefered over netfilter >That''s normal. -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