Hi, I have setup a IPSEC VPN using Openswan to connect a Draytek router to a CentOS 5.2/Shorewall 4.2.9 firewall. The VPN establishes OK but I''m getting a problem with packets from the left hand subnet getting masqueraded rather than routed down the IPSEC VPN as though they were going out onto the net. I''ve spent the last day searching Google and so far I''ve hit a brick wall and was hoping someone could help point me in the right direction. If anyone thinks they can help let me know what info you need and I''ll be happy to provide it. Thanks Simon This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Onebyte. This email has been scanned for viruses and has been certified as clean by Symantec, Kapersky & Clam AV. Onebyte is the trading name of Landmark Computer Services and is a limited company registered in England & Wales. Registered number: 5329402. Registered Office 145-157 St. John Street, London, EC1V 4PY ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what''s new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
Simon Buckner wrote:> I have setup a IPSEC VPN using Openswan to connect a Draytek router to a > CentOS 5.2/Shorewall 4.2.9 firewall. The VPN establishes OK but I’m > getting a problem with packets from the left hand subnet getting > masqueraded rather than routed down the IPSEC VPN as though they were > going out onto the net. I’ve spent the last day searching Google and so > far I’ve hit a brick wall and was hoping someone could help point me in > the right direction.Try reading this: http://www.shorewall.net/IPSEC-2.6.html -- Tuomo Soini <tis@foobar.fi> Foobar Linux services +358 40 5240030 Foobar Oy <http://foobar.fi/> ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simon Buckner wrote:> I have setup a IPSEC VPN using Openswan to connect a Draytek router > to a CentOS 5.2/Shorewall 4.2.9 firewall. The VPN establishes OK but > I’m getting a problem with packets from the left hand subnet getting > masqueraded rather than routed down the IPSEC VPN as though they were > going out onto the net.This is almost always an IPSEC configuration problem that has nothing to do with Shorewall.> I’ve spent the last day searching GoogleIt would have likely been profitable to have spent part of that time reading http://www.shorewall.net/IPSEC-2.6.html.> and so far I’ve hit a brick wall and was hoping someone could help > point me in the right direction.Temporarily 'shorewall clear' then try to establish a connection from the 'left subnet' through the VPN. Does it work? I'm guessing not. (be sure to 'shorewall start' after the test). Unless the connection suddenly starts working, then the immediate problem has nothing to do with Shorewall. If it does start working, then the above URL will undoubtedly be useful.> > > > If anyone thinks they can help let me know what info you need and > I’ll be happy to provide it.For us to be of any help, we need the output of 'shorewall dump' collected exactly as described at http://www.shorewall.net/support.htm#Guidelines. - -Tom - -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkqDG0EACgkQO/MAbZfjDLKMAACfQpjypMPCLESo04NGk6MJqmZ1 /94An0vUW5YYkwySu6g1RCZhFSBWvk2N =yRkg -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Eastep wrote:> Simon Buckner wrote: > >> I have setup a IPSEC VPN using Openswan to connect a Draytek router >> to a CentOS 5.2/Shorewall 4.2.9 firewall. The VPN establishes OK but >> Im getting a problem with packets from the left hand subnet getting >> masqueraded rather than routed down the IPSEC VPN as though they were >> going out onto the net. > > This is almost always an IPSEC configuration problem that has nothing to > do with Shorewall.Actually, that''s not true. The fact that connections are masqueraded could also mean that you haven''t followed the instructions at http://www.shorewall.net/IPSEC-2.6.html. Here''s why. Normally, an entry in /etc/shorewall/masq generates an iptables rule of the (simplified) form: -A POSTROUTING -o <iface> -s <src> -j MASQUERADE or -A POSTROUTING -o <iface> -s <src> -j SNAT --to-src <ip> where <iface> is the interface named in the INTERFACE column. <src> is the set of IP addresses corresponding to the SOURCE column; and <ip> is the address specified in the ADDRESS column So the rule masquerades/SNATs *all* traffic from <src> that is routed out through <interface>. That will include traffic that is scheduled to be encrypted by IPSEC! When you configure your gateway as described in the above-mentioned article, the rule will include the additional match: -m policy --dir out --pol none That additional match restricts rewriting of the source IP address to those connections that will *not* be encrypted by IPSEC. If, with this additional match in place, the traffic is *still* being masqueraded, *then* there is a problem with your IPSEC setup. - -Tom - -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqEIcEACgkQO/MAbZfjDLKUFACdHr738Pf1IRm3YE7mTRd/jCEE QqMAoMB3TD0qzmjTz+hYYK4E3r19j000 =4KCb -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what''s new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
Thanks for the responses. My first port of call was http://www.shorewall.net/IPSEC-2.6.html so thanks to all those who so helpfully suggested that I read it! It was actually one of the first documents returned by Google when I started searching. The above instructions use Racoon to create the IPSEC VPN but unfortunately Racoon doesn''t support the same encryption protocols as the Draytek that is used at the other end. Therefore I have used OpenSwan (NETKEY as opposed to KLIPS) as that provides a very nice match. I have already raised this issue with the Openswan mailing list and they have confirmed my IPSEC configuration is currect and that the problem is caused by Shorewall/iptables masquerading the packets destined for the tunnel. As yet I have not worked out which entry in which file would prevent the IPSEC packets from being MASQ''ed. All the examples I''ve looked at seem to relate to Racoon which creates an interface for each tunnel (e.g. IPSEC0) whereas Openswan/NETKEY doesn''t. Based on the above shall I still provide a shorewall dump? Thanks Simo -----Original Message----- From: Tom Eastep [mailto:teastep@shorewall.net] Sent: 13 August 2009 15:23 To: Shorewall Users Subject: Re: [Shorewall-users] Shorewall (Openswan) IPSEC VPN MASQ Problem -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Eastep wrote:> Simon Buckner wrote: > >> I have setup a IPSEC VPN using Openswan to connect a Draytek router >> to a CentOS 5.2/Shorewall 4.2.9 firewall. The VPN establishes OK but >> Im getting a problem with packets from the left hand subnet getting >> masqueraded rather than routed down the IPSEC VPN as though they were >> going out onto the net. > > This is almost always an IPSEC configuration problem that has nothing to > do with Shorewall.Actually, that''s not true. The fact that connections are masqueraded could also mean that you haven''t followed the instructions at http://www.shorewall.net/IPSEC-2.6.html. Here''s why. Normally, an entry in /etc/shorewall/masq generates an iptables rule of the (simplified) form: -A POSTROUTING -o <iface> -s <src> -j MASQUERADE or -A POSTROUTING -o <iface> -s <src> -j SNAT --to-src <ip> where <iface> is the interface named in the INTERFACE column. <src> is the set of IP addresses corresponding to the SOURCE column; and <ip> is the address specified in the ADDRESS column So the rule masquerades/SNATs *all* traffic from <src> that is routed out through <interface>. That will include traffic that is scheduled to be encrypted by IPSEC! When you configure your gateway as described in the above-mentioned article, the rule will include the additional match: -m policy --dir out --pol none That additional match restricts rewriting of the source IP address to those connections that will *not* be encrypted by IPSEC. If, with this additional match in place, the traffic is *still* being masqueraded, *then* there is a problem with your IPSEC setup. - -Tom - -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqEIcEACgkQO/MAbZfjDLKUFACdHr738Pf1IRm3YE7mTRd/jCEE QqMAoMB3TD0qzmjTz+hYYK4E3r19j000 =4KCb -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what''s new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simon Buckner wrote:> All the examples I''ve looked at seem to relate to Racoon which > creates an interface for each tunnel (e.g. IPSEC0) whereas > Openswan/NETKEY doesn''t. >The Shorewall configuration is independent of which tool you use to configure IPSEC. - -Tom - -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqEMb0ACgkQO/MAbZfjDLKARgCfSPNbs/cf4cFJgXx2rFzh5+ig NvUAnAiGE8WYtFvgSwdOMHyz4W3BkdAc =zOEu -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what''s new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
Simon Buckner wrote:> The above instructions use Racoon to create the IPSEC VPN but > unfortunately Racoon doesn''t support the same encryption protocols as > the Draytek that is used at the other end. Therefore I have used > OpenSwan (NETKEY as opposed to KLIPS) as that provides a very nice > match.Shorewall configuration with racoon and NETKEY and openswan and NETKEY is exactly same!> I have already raised this issue with the Openswan mailing list and > they have confirmed my IPSEC configuration is currect and that the > problem is caused by Shorewall/iptables masquerading the packets > destined for the tunnel. As yet I have not worked out which entry in > which file would prevent the IPSEC packets from being MASQ''ed. All > the examples I''ve looked at seem to relate to Racoon which creates an > interface for each tunnel (e.g. IPSEC0) whereas Openswan/NETKEY > doesn''t.Racoon only recognizes NETKEY and will never create ipsec0 interface like openswan + klips. -- Tuomo Soini <tis@foobar.fi> Foobar Linux services +358 40 5240030 Foobar Oy <http://foobar.fi/> ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what''s new with Crystal Reports now. http://p.sf.net/sfu/bobj-july