Hello, Forgive me if this has been covered somewhere else but I didn''t find it on the net and I have spent a good chunk of the day on this one. I have a working version of Openswan on Debian Sarge which is a 2.4.27 kernel with the 2.6 ipsec back port built into it. As a result there is no ipsecX virtual interface, the tunnels work but I have to treat the vpn addresses as a net interface which makes the rule set quite confusing. I have used the older Debian / Shorewall builds with virtual ipsec interfaces for a long time but this implementation is new to me. I read and read the ipsec how to and the one thing I am having trouble with is the policy match requirement. I have compiled iptables 1.3.5 which has the policy match stuff built in according to the change log but I have not been able to figure out what kernel patches if any, I need for netfilter. I really had not planned to move to 2.6 on these servers so if I can get something to work with Debian 2.4.27 I would rather go that route. Any direction on patching or what''s required to get ipsec policy matching to run on Debian would be appreciated. Thanks in advance, Doug Leece ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Douglas Leece wrote:> I have a working version of Openswan on Debian Sarge which is a 2.4.27 > kernel with the 2.6 ipsec back port built into it. As a result there is > no ipsecX virtual interface, the tunnels work but I have to treat the > vpn addresses as a net interface which makes the rule set quite > confusing. I have used the older Debian / Shorewall builds with virtual > ipsec interfaces for a long time but this implementation is new to me. > > I read and read the ipsec how to and the one thing I am having trouble > with is the policy match requirement.You might spend some time reading http://www.shorewall.net/IPSEC.html -- you should soon realize that it too has instructions for using the 2.6 kernel and that those instructions *don''t* require policy match. That would be my recommendation. -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 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Douglas Leece wrote:> ... on Debian Sarge which is a 2.4.27 kernel ...I am compelled to clarify that the Debian Sarge kernel is linux-2.6.8. What you are using is the latest 2.4 series kernel which is still supported under Sarge. That is not quite the same thing. I did not want people to get the wrong impression. Debian makes 2.4 kernels available for those people who still need or want to run 2.4 kernels for whatever reason. But it is not the recommended kernel.> I really had not planned to move to 2.6 on these servers so if I can > get something to work with Debian 2.4.27 I would rather go that > route.If you do decide to upgrade to the 2.6 kernel make sure that you have installed the Sarge module-init-tools package. This is a new package for Sarge. The older modutils from Woody will not create a functional initrd.img file with the linux-2.6 kernel packages and will install but will fail to boot due to missing kernel modules. (Been there, done that, hoping to save you the same problem.) Bob -- ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Thanks Tom, I did wade down the 2.6 path, and the kernel and OPenswan seem to get along so I dug in further. Everything works as expected, pings to each IPSEC partner show up in the logs as accepted by that policy. However, it looks like the full size packets need to be forced down to 1432 so the IPSEC overhead doesn''t make them two big to transport. I tried setting the in and out options to mss=1432 but that didn''t seem to fix it so I guess I don''t quite understand which other files I am supposed to adjust to make this work. I am sure it''s documented because the 2.6 ipsec info on the site talks about this exact issue but I must have missed a step some where. Any leads would be appreciated, Thanks Doug Leece P.S Thaks to Bob as well about the modules tool, it''s in there but good info for future moves to 2.6 -----Original Message----- From: shorewall-users-bounces@lists.sourceforge.net [mailto:shorewall-users-bounces@lists.sourceforge.net]On Behalf Of Tom Eastep Sent: Sunday, July 09, 2006 7:44 PM To: Shorewall Users Subject: Re: [Shorewall-users] IPSEC & Debian, policy match problem Douglas Leece wrote:> I have a working version of Openswan on Debian Sarge which is a 2.4.27 > kernel with the 2.6 ipsec back port built into it. As a result there is > no ipsecX virtual interface, the tunnels work but I have to treat the > vpn addresses as a net interface which makes the rule set quite > confusing. I have used the older Debian / Shorewall builds with virtual > ipsec interfaces for a long time but this implementation is new to me. > > I read and read the ipsec how to and the one thing I am having trouble > with is the policy match requirement.You might spend some time reading http://www.shorewall.net/IPSEC.html -- you should soon realize that it too has instructions for using the 2.6 kernel and that those instructions *don''t* require policy match. That would be my recommendation. -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 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Douglas Leece wrote:> Thanks Tom, > > I did wade down the 2.6 path, and the kernel and OPenswan seem > to get along so I dug in further. Everything works as expected, > pings to each IPSEC partner show up in the logs as accepted by that > policy. However, it looks like the full size packets need to be > forced down to 1432 so the IPSEC overhead doesn''t make them two > big to transport. > > I tried setting the in and out options to mss=1432 but that didn''t > seem to fix it so I guess I don''t quite understand which other files > I am supposed to adjust to make this work. I am sure it''s documented > because the 2.6 ipsec info on the site talks about this exact issue > but I must have missed a step some where. > > Any leads would be appreciated,I''m very unclear about which approach you are using -- are you using ''policy match'' or are you using the approach outlined in http://www.shorewall.net/IPSEC.htm? If the latter, there is no way to do what you want with Shorewall short of setting CLAMPMSS=1432 in shorewall.conf. -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 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Hello Tom, I followed the approach you documented in ipsec.htm. I believe I understood it and I could see it working with a 2.6 kernel without policy match compiled in. As packets went through the various VPN gateway to gateway policies were activated so I am pretty sure I got it right. The large packets still fail to get across the ipsec tunnel even with clampmss set to 1432. I found some other information in the Shorewall archives about 2.6 kernel at http://www.shorewall.net/IPSEC-2.6.html#id2451053 and it says clampmss won''t work with the native ipsec mode. There is this instruction to define the MSS at the zone level instead but I think this still needs policy match installed but I mss=<number> - Sets the MSS field in TCP syn packets forwarded to/from this zone. May be used to compensate for the lack of IPSEC pseudo-devices with their own MTU in the 2.6 Kernel IPSEC implementation. If specified in the IN OPTIONS, TCP SYN packets from the zone will have MSS altered; if specified in the OUT OPTIONS, TCP SYN packets to the zone will have MSS altered. I have included my zone file and hosts file as well as policy in case I am doing something wrong that is glaringly obvious. Zone file: # #ZONE type IN OPTIONS OUT OPTIONS gw ipv4 mss=1400,mss=1400 gw1 ipv4 mss=1400,mss=1400 gw2 ipv4 mss=1400,mss=1400 gw3 ipv4 mss=1400,mss=1400 net ipv4 loc ipv4 #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE hosts file: #ZONE HOST(S) OPTIONS gw eth0:192.168.58.0/27,142.179.156.47 ipsec gw1 eth0:192.168.100.0/24,142.179.174.144 ipsec gw2 eth0:192.168.150.0/24,206.163.232.247 ipsec gw3 eth0:192.168.200.0/24,207.195.103.19 ipsec #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE Policy: #CLIENT SERVER POLICY LOG LEVEL LIMIT:BURST loc net ACCEPT info loc gw ACCEPT info loc gw1 ACCEPT info loc gw2 ACCEPT info loc gw3 ACCEPT info loc $FW REJECT info $FW gw ACCEPT info $FW gw1 ACCEPT info $FW gw2 ACCEPT info $FW gw3 ACCEPT info $FW loc DROP info $FW net DROP info gw $FW ACCEPT info gw1 $FW ACCEPT info gw2 $FW ACCEPT info gw3 $FW ACCEPT info gw loc ACCEPT info gw1 loc ACCEPT info gw2 loc ACCEPT info gw3 loc ACCEPT info net $FW DROP info net loc DROP info net all DROP info all all REJECT info #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE krusty:/etc/shorewall# -----Original Message----- From: shorewall-users-bounces@lists.sourceforge.net [mailto:shorewall-users-bounces@lists.sourceforge.net]On Behalf Of Tom Eastep Sent: Monday, July 10, 2006 8:21 AM To: Shorewall Users Subject: Re: [Shorewall-users] IPSEC & Debian, policy match problem Douglas Leece wrote:> Thanks Tom, > > I did wade down the 2.6 path, and the kernel and OPenswan seem > to get along so I dug in further. Everything works as expected, > pings to each IPSEC partner show up in the logs as accepted by that > policy. However, it looks like the full size packets need to be > forced down to 1432 so the IPSEC overhead doesn''t make them two > big to transport. > > I tried setting the in and out options to mss=1432 but that didn''t > seem to fix it so I guess I don''t quite understand which other files > I am supposed to adjust to make this work. I am sure it''s documented > because the 2.6 ipsec info on the site talks about this exact issue > but I must have missed a step some where. > > Any leads would be appreciated,I''m very unclear about which approach you are using -- are you using ''policy match'' or are you using the approach outlined in http://www.shorewall.net/IPSEC.htm? If the latter, there is no way to do what you want with Shorewall short of setting CLAMPMSS=1432 in shorewall.conf. -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 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Douglas Leece wrote:> Hello Tom,Would you *please* post in plain text? After HTML->text translation, each of your paragraphs is one long line which I have to break up manully so I can reply.> > I followed the approach you documented in ipsec.htm. I believe I understood > it and I could see it working with a 2.6 kernel without policy match > compiled in. As packets went through the various VPN gateway to gateway > policies were activated so I am pretty sure I got it right. > The large packets still fail to get across the ipsec tunnel even with clampmss set to 1432.I found that I had to go all the way down to 1420 to make it work.> I found some other information in the Shorewall archives about 2.6 kernel > at http://www.shorewall.net/IPSEC-2.6.html#id2451053 and it says clampmss > won''t work with the native ipsec mode.It does NOT say that -- is says that CLAMPMSS=Yes won''t work; it says nothing about CLAMPMSS=<number>. There is this instruction to define the MSS at the zone level instead but I think this still needs policy match installed but I> > mss=<number> - Sets the MSS field in TCP syn packets forwarded to/from this zone. May be used to compensate for the lack of IPSEC pseudo-devices with their own MTU in the 2.6 Kernel IPSEC implementation. If specified in the IN OPTIONS, TCP SYN packets from the zone will have MSS altered; if specified in the OUT OPTIONS, TCP SYN packets to the zone will have MSS altered. > > I have included my zone file and hosts file as well as policy in case I am doing something wrong that is glaringly obvious. > > Zone file: > # > #ZONE type IN OPTIONS OUT OPTIONS > gw ipv4 mss=1400,mss=1400----------------- Why are you specifying mss twice???? Also, the columns are: ZONE, TYPE, OPTIONS, IN OPTIONS, OUT OPTIONS so I assume that you are trying to set mss in OPTIONS?> gw1 ipv4 mss=1400,mss=1400 > gw2 ipv4 mss=1400,mss=1400 > gw3 ipv4 mss=1400,mss=1400 > net ipv4 > loc ipv4 > #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE > > hosts file: > > #ZONE HOST(S) OPTIONS > gw eth0:192.168.58.0/27,142.179.156.47 ipsecSetting the ipsec option here requires policy match -- I thought you said that you don''t have policy match! I think it''s time for me to see the output of "shorewall dump", collected as described at http://www.shorewall.net/support.htm. -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 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642