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:[email protected]] 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 _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
