Date: Sat, 13 Mar 2004 13:03:03 +1300 From: Neil Fenemor <Neil@ts.co.nz> To: freebsd-net@freebsd.org Subject: IPSEC/NAT/Gateway Query Message-ID: <1079136183.29695.7.camel@acer>
next in thread | raw e-mail | index | archive | help
Hi all, I currently have an issue of how "open" the whole WiFi tends to be, so, as all good people should do, I've started implementing a IPSec encryption system rather than the rather disappointing WEP. I'm encrypting all data to and from the gateway, which isn't a problem. This was documented rather well all over the internet. What I'm having an issue, is if the "client" has a range of RFC 1918 addresses behind it, and I have to introduce NAT into the equation. I've best tracked it down to the order that the kernel looks at the packets to decide what to do with it. This is where I stand at the moment. x.y.z.11 -> x.y.z.254 : works perfectly x.y.z.11 -> x.y.z.254 -> 0.0.0.0 : works perfectly rfc 1918 -> x.y.z.11 -> x.y.z.254 : Fails rfc 1918 -> x.y.z.11 -> x.y.z.254 -> 0.0.0.0 : Fails The connection between x.y.z.11 and x.y.z.254 is there the IPSec takes place, and is the only part "off the wire" as it were. The issue presents itself as the packet, from an rfc 1918 address, goes to the client box, gets inspected by the VPN rules, which are currently set to match on the external address of the client machine, and is subsequently overlooked by the VPN. The packet then goes on, gets NATed, and goes out as a unencrypted packet, from x.y.z.11. Thats a generally undesired transport mode. On x.y.z.254, the packet goes back via the IPSec tunnel, but is then not un-NATed. All I believe should be required, is for the RFC 1918 packet to be NATed to the external IP address, BEFORE it is inspected by the IPSec system. So basically, all I'm really asking, is am I on the right line of thinking, or have I just gone off on a complete tangent to where I should be headed. Any ideas/input would be greatly appreciated. Regards Neil Fenemor Senior Systems Administrator ThePacific.net Ltd.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1079136183.29695.7.camel>