Don''t know if this has been pointed out previously, but I have a 2 nic firewall running Shorewall, with eth1 as my public NIC and eth0 as my private NAT''d NIC. Following the instructions at http://www.shorewall.net/IPSEC-2.6.html, I had to add a per this page http://www.sherman.ca/archives/2004/11/21/linux-26-ipsec-vpns/ a statement on Firewall A "ip route add x.x.x.x/xx via y.y.y.y src z.z.z.z" where x.x.x.x/xx was the NAT''d subnet on Firewall B, y.y.y.y was the IP of my public NIC eth1, and z.z.z.z was the private (NAT''d) IP of eth0 to be able to facilitate transparent communications between the actual Firewall A host and the machines on Firewall B''s subnet. In other words, just following the instructions on http://www.shorewall.net/IPSEC-2.6.html got me VPN between firewall A and B. If I telnetted into Firewall A and tried to ping and address on Firewall B''s subnet, the ping would fail unless I issued ping with the -I parameter, and specified eth0 (the nic on the NAT''d side). Adding the "ip route add x.x.x.x/xx via y.y.y.y src z.z.z.z" statement allowed transparent communications between firewall A and all machines on Firewall B''s network. (Needed to do this because I run Nagios on firewall A). Keith Mitchell CTO Productivity Associates, Inc. http://www.gotopai.com ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
On Thursday 15 September 2005 10:30, Keith Mitchell wrote:> > Adding the "ip route add x.x.x.x/xx via y.y.y.y src z.z.z.z" statement > allowed transparent communications between firewall A and all machines on > Firewall B''s network. (Needed to do this because I run Nagios on firewall > A).Did you configure your security policies as recommented on the web site? -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
Yup. To the letter. -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net]On Behalf Of Tom Eastep Sent: Thursday, September 15, 2005 10:43 AM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] http://www.shorewall.net/IPSEC-2.6.html On Thursday 15 September 2005 10:30, Keith Mitchell wrote:> > Adding the "ip route add x.x.x.x/xx via y.y.y.y src z.z.z.z" statement > allowed transparent communications between firewall A and all machines on > Firewall B''s network. (Needed to do this because I run Nagios on firewall > A).Did you configure your security policies as recommented on the web site? -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 ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
Oops one caveat though. Firewall B is NOT a Shorewall. It is a Sonicwall. -----Original Message----- From: Keith Mitchell Sent: Thursday, September 15, 2005 10:45 AM To: ''shorewall-users@lists.sourceforge.net'' Subject: RE: [Shorewall-users] http://www.shorewall.net/IPSEC-2.6.html Yup. To the letter. -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net]On Behalf Of Tom Eastep Sent: Thursday, September 15, 2005 10:43 AM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] http://www.shorewall.net/IPSEC-2.6.html On Thursday 15 September 2005 10:30, Keith Mitchell wrote:> > Adding the "ip route add x.x.x.x/xx via y.y.y.y src z.z.z.z" statement > allowed transparent communications between firewall A and all machines on > Firewall B''s network. (Needed to do this because I run Nagios on firewall > A).Did you configure your security policies as recommented on the web site? -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 ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
On Thursday 15 September 2005 10:47, Keith Mitchell wrote:> Oops one caveat though. Firewall B is NOT a Shorewall. It is a Sonicwall.Ok -- I''ll look at it after 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
On Thursday 15 September 2005 10:49, Tom Eastep wrote:> On Thursday 15 September 2005 10:47, Keith Mitchell wrote: > > Oops one caveat though. Firewall B is NOT a Shorewall. It is a > > Sonicwall. > > Ok -- I''ll look at it after work.Lunch time here and I took a quick look at the web site that you cited. The author admits there that the routes are necessary because of the simple-minded policies that he is using. So what does ''setkey -DP'' look like on your gateway? -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
OOops sorry got tied up in the day and didn't check my mailbox... a.a.a.a/aa = private subnet Firewall A b.b.b.b/bb = private subnet Firewall B agw.agw.agw.agw = Public IP Firewall A bgw.bgw.bgw.bgw = Public IP Firewall B b.b.b.b/bb[any] a.a.a.a/aa[any] any in prio def ipsec esp/tunnel/bgw.bgw.bgw.bgw-agw.agw.agw.agw/require created: Sep 15 11:03:54 2005 lastused: Sep 15 16:45:40 2005 lifetime: 0(s) validtime: 0(s) spid=14640 seq=39 pid=1851 refcnt=3 b.b.b.b/bb[any] agw.agw.agw.agw[any] any in prio def ipsec esp/tunnel/bgw.bgw.bgw.bgw-agw.agw.agw.agw/require created: Sep 15 11:03:54 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=14656 seq=38 pid=1851 refcnt=1 bgw.bgw.bgw.bgw[any] a.a.a.a/aa[any] any in prio def ipsec esp/tunnel/bgw.bgw.bgw.bgw-agw.agw.agw.agw/require created: Sep 15 11:03:54 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=14672 seq=37 pid=1851 refcnt=1 bgw.bgw.bgw.bgw[any] agw.agw.agw.agw[any] any in prio def ipsec esp/tunnel/bgw.bgw.bgw.bgw-agw.agw.agw.agw/require created: Sep 15 11:03:54 2005 lastused: Sep 15 16:42:12 2005 lifetime: 0(s) validtime: 0(s) spid=14688 seq=36 pid=1851 refcnt=1 a.a.a.a/aa[any] b.b.b.b/bb[any] any out prio def ipsec esp/tunnel/agw.agw.agw.agw-bgw.bgw.bgw.bgw/require created: Sep 15 11:03:54 2005 lastused: Sep 15 16:45:40 2005 lifetime: 0(s) validtime: 0(s) spid=14609 seq=26 pid=1851 refcnt=9 a.a.a.a/aa[any] bgw.bgw.bgw.bgw[any] any out prio def ipsec esp/tunnel/agw.agw.agw.agw-bgw.bgw.bgw.bgw/require created: Sep 15 11:03:54 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=14617 seq=25 pid=1851 refcnt=1 agw.agw.agw.agw[any] bgw.bgw.bgw.bgw[any] any out prio def ipsec esp/tunnel/agw.agw.agw.agw-bgw.bgw.bgw.bgw/require created: Sep 15 11:03:54 2005 lastused: Sep 15 11:03:54 2005 lifetime: 0(s) validtime: 0(s) spid=14625 seq=24 pid=1851 refcnt=1 agw.agw.agw.agw[any] b.b.b.b/bb[any] any out prio def ipsec esp/tunnel/agw.agw.agw.agw-bgw.bgw.bgw.bgw/require created: Sep 15 11:03:54 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=14633 seq=23 pid=1851 refcnt=1 (per-socket policy) in none created: Sep 15 11:03:53 2005 lastused: Sep 15 12:49:08 2005 lifetime: 0(s) validtime: 0(s) spid=14595 seq=1 pid=1851 refcnt=1 (per-socket policy) out none created: Sep 15 11:03:53 2005 lastused: Sep 15 12:49:08 2005 lifetime: 0(s) validtime: 0(s) spid=14604 seq=0 pid=1851 refcnt=1 -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net]On Behalf Of Tom Eastep Sent: Thursday, September 15, 2005 12:13 PM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] http://www.shorewall.net/IPSEC-2.6.html On Thursday 15 September 2005 10:49, Tom Eastep wrote:> On Thursday 15 September 2005 10:47, Keith Mitchell wrote: > > Oops one caveat though. Firewall B is NOT a Shorewall. It is a > > Sonicwall. > > Ok -- I'll look at it after work.Lunch time here and I took a quick look at the web site that you cited. The author admits there that the routes are necessary because of the simple-minded policies that he is using. So what does 'setkey -DP' look like on your gateway? -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 HS^隊X'ujgz!jY^+az'j'ym秵v0vڙZfzt+f=#'$ek(mqzz'j)
On Thursday 15 September 2005 16:44, Keith Mitchell wrote:> OOops sorry got tied up in the day and didn''t check my mailbox... > > a.a.a.a/aa = private subnet Firewall A > b.b.b.b/bb = private subnet Firewall B > agw.agw.agw.agw = Public IP Firewall A > bgw.bgw.bgw.bgw = Public IP Firewall B >> agw.agw.agw.agw[any] bgw.bgw.bgw.bgw[any] any > out prio def ipsec > esp/tunnel/agw.agw.agw.agw-bgw.bgw.bgw.bgw/require > created: Sep 15 11:03:54 2005 lastused: Sep 15 11:03:54 2005 > lifetime: 0(s) validtime: 0(s) > spid=14625 seq=24 pid=1851 > refcnt=1 > agw.agw.agw.agw[any] b.b.b.b/bb[any] any > out prio def ipsec > esp/tunnel/agw.agw.agw.agw-bgw.bgw.bgw.bgw/require > created: Sep 15 11:03:54 2005 lastused: > lifetime: 0(s) validtime: 0(s) > spid=14633 seq=23 pid=1851 > refcnt=1Is the SonicWall acting as a passive respondent to the Linux Boxes proposal or does in have similar SPs configured? The reason that I ask is that whichever SP triggers a phase one negotiation seems to be the only policy negotiated in main mode (At least that''s my experience). So if traffic from a.a.a.a/aa to b.b.b.b/bb triggers the initial phase 1 negotiation that the a.a.a.a/aa <-> b.b.b.b/bb policies are the only one that will be generated on the SonicWall. I''ve seen that between two Linux boxes as well and in that case, adding the route that you suggest would allow <a gateway> <-> b.b.b.b/bb communication. -Tom PS -- I reproduce your setup (even with two Linux Boxes) here at the moment but I have run a similar setup from our second home. -- 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
The Sonicwall does have similar SP's configured, but experientially, does not initiate the VPN but waits passively for a Phase 1 from Racoon. This might have all changed recently as I have been using manual tunnel with setkey up until this week, when an upgrade to Fedora FC4 broke my manual keyed setup for some reason I have yet to determine. Thusly, I went to my faithful Shorewall online documentation (excellent as is the Shorewall itself) and followed the directions there including compiling a custom kernel with the appropriate patches. And lo and behold, it worked! (Except the one problem I have outlined here, which was resolved with the ip route command). The FC4 kernel I'm using is 2.6.12(-1.1447_FC4), to which I applied your 2.6.12 patches along with the patch-o-matic policy match and route target. The iptables version I am using is 1.3.0, as that is what shipped with FC4. I simply downloaded the source RPM, built it into a source package with rpmbuild --bp, and then dumped it in the /usr/src directory to be patched by patch-o-matic. The ipsec-tools shipped with FC4 show as 0.5-4, but this problem exists with manually compiled 0.5.2, 0.6.0 and 0.6.1 tools as well. In your PS - were you saying you reproduced the same problem? Or couldn't? I wasn't clear. Thanks for the feedback though. Was just throwing out an issue I had that I found an appropriate "fix" for that someone else might find useful along the way. As long as it's working, I'm happy. Man oh man this 2.6 ipsec stuff throws me for a loop. Just when I had Free/Swan all figured out... -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net]On Behalf Of Tom Eastep Sent: Thursday, September 15, 2005 5:03 PM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] http://www.shorewall.net/IPSEC-2.6.html On Thursday 15 September 2005 16:44, Keith Mitchell wrote:> OOops sorry got tied up in the day and didn't check my mailbox... > > a.a.a.a/aa = private subnet Firewall A > b.b.b.b/bb = private subnet Firewall B > agw.agw.agw.agw = Public IP Firewall A > bgw.bgw.bgw.bgw = Public IP Firewall B >> agw.agw.agw.agw[any] bgw.bgw.bgw.bgw[any] any > out prio def ipsec > esp/tunnel/agw.agw.agw.agw-bgw.bgw.bgw.bgw/require > created: Sep 15 11:03:54 2005 lastused: Sep 15 11:03:54 2005 > lifetime: 0(s) validtime: 0(s) > spid=14625 seq=24 pid=1851 > refcnt=1 > agw.agw.agw.agw[any] b.b.b.b/bb[any] any > out prio def ipsec > esp/tunnel/agw.agw.agw.agw-bgw.bgw.bgw.bgw/require > created: Sep 15 11:03:54 2005 lastused: > lifetime: 0(s) validtime: 0(s) > spid=14633 seq=23 pid=1851 > refcnt=1Is the SonicWall acting as a passive respondent to the Linux Boxes proposal or does in have similar SPs configured? The reason that I ask is that whichever SP triggers a phase one negotiation seems to be the only policy negotiated in main mode (At least that's my experience). So if traffic from a.a.a.a/aa to b.b.b.b/bb triggers the initial phase 1 negotiation that the a.a.a.a/aa <-> b.b.b.b/bb policies are the only one that will be generated on the SonicWall. I've seen that between two Linux boxes as well and in that case, adding the route that you suggest would allow <a DEFANGED_gateway> <-> b.b.b.b/bb communication. -Tom PS -- I reproduce your setup (even with two Linux Boxes) here at the moment but I have run a similar setup from our second home. -- 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 HS^隊X'ujgz!jY^+az'j'ym秵v0vڙZfzt+f=#'$ek(mqzz'j)
Keith Mitchell <keithm <at> paisd.com> writes:> In your PS - were you saying you reproduced the same problem? Or couldn''t? I > wasn''t clear. > > Thanks for the feedback though. Was just throwing out an issue I had that I > found an appropriate "fix" for that someone else might find useful along the > way. As long as it''s working, I''m happy.So, is it *my* braindead sp that is the issue? I know Tom tried to explain to me a better policy some time ago, but I didn''t clue in. What''s "braindead" about my article? Thanks! A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
On Thursday 15 September 2005 19:11, Adam Sherman wrote:> Keith Mitchell <keithm <at> paisd.com> writes: > > In your PS - were you saying you reproduced the same problem? Or > > couldn''t? I wasn''t clear. > > > > Thanks for the feedback though. Was just throwing out an issue I had that > > I found an appropriate "fix" for that someone else might find useful > > along the way. As long as it''s working, I''m happy. > > So, is it *my* braindead sp that is the issue? I know Tom tried to explain > to me a better policy some time ago, but I didn''t clue in. What''s > "braindead" about my article? >Hi Adam, Nothing wrong with your article (and I think I used the term "simple-minded", not "braindead" :-) ) -- you admit in your article that you have only net<->net SPs configured which require a routing trick to piggyback gateway traffic on top of those SPs. I was only pointing out that if fuller SPs are enforced in both gateways that those routing tricks aren''t required. -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 9/15/05, Tom Eastep <teastep@shorewall.net> wrote:> On Thursday 15 September 2005 19:11, Adam Sherman wrote: > > So, is it *my* braindead sp that is the issue? I know Tom tried to explain > > to me a better policy some time ago, but I didn''t clue in. What''s > > "braindead" about my article?> I was only pointing out that if fuller SPs are enforced in both gateways that > those routing tricks aren''t required.Mind elaborating a bit? I''ve never quite understood why I needed the routing trick, but none of the on-line docs I read mentioned it. Thanks, A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
On Thursday 15 September 2005 20:09, Adam Sherman wrote:> On 9/15/05, Tom Eastep <teastep@shorewall.net> wrote: > > On Thursday 15 September 2005 19:11, Adam Sherman wrote: > > > So, is it *my* braindead sp that is the issue? I know Tom tried to > > > explain to me a better policy some time ago, but I didn''t clue in. > > > What''s "braindead" about my article? > > > > I was only pointing out that if fuller SPs are enforced in both gateways > > that those routing tricks aren''t required. > > Mind elaborating a bit? I''ve never quite understood why I needed the > routing trick, but none of the on-line docs I read mentioned it.You had these two SPs: 10.0.1.0/24[any] 10.0.0.0/24[any] any in ipsec esp/tunnel/2.2.2.2-3.3.3.3/unique#16385 created: Nov 18 23:01:24 2004 lastused: lifetime: 0(s) validtime: 0(s) spid=1512 seq=9 pid=9800 refcnt=1 10.0.0.0/24[any] 10.0.1.0/24[any] any out ipsec esp/tunnel/3.3.3.3-2.2.2.2/unique#16384 created: Nov 18 23:01:24 2004 lastused: Nov 18 23:05:31 2004 lifetime: 0(s) validtime: 0(s) spid=1505 seq=8 pid=9800 refcnt=1 So traffic originating in either local subnet and destined for the other requires a tunnel-mode SA between the gateways. But connections originating on the gateways themselves and destined for the remote network normally assume the source IP address of the interface out of which the connection request is sent (note that I''m using the term ''connection'' here in its Netfilter sense). This would normally be the IP address of the gateway''s external interface (call it 206.124.146.176). But that traffic (206.124.146.176 -> 10.0.1.0/24) doesn''t match your ''out'' SP. By adding the extra route, you are telling the IP stack to assign a different source IP address which *does* match your ''out'' SP. If you would have added an ''out'' SP for 206.124.146.176 -> 10.0.1.0/24 (and the corresponding ''in'' SP) then you could have avoided the route. Make sense? -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 9/16/05, Tom Eastep <teastep@shorewall.net> wrote:> If you would have added an ''out'' SP for 206.124.146.176 -> 10.0.1.0/24 (and > the corresponding ''in'' SP) then you could have avoided the route.Perfect sense. So, in a normal tunneled IPsec VPN context, additional SPs are always needed for the gateways themselves to contact the more networks. Thanks Tom, A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php