From owner-freebsd-questions@FreeBSD.ORG Fri Mar 12 16:10:07 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5509216A4CE for ; Fri, 12 Mar 2004 16:10:07 -0800 (PST) Received: from sage.ts.co.nz (sage.tasman.net [202.49.92.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5C1543D1F for ; Fri, 12 Mar 2004 16:10:06 -0800 (PST) (envelope-from Neil@ts.co.nz) Received: from sage.ts.co.nz ([172.16.21.1]) by sage.ts.co.nz (8.12.3/8.12.10) with ESMTP id i2D070rZ014305 for ; Sat, 13 Mar 2004 13:07:00 +1300 Received: from 6-allhosts (gateway-nelson.thepacific.net [202.49.95.33]) by sage.ts.co.nz (8.12.3/8.12.10) with ESMTP id i2D056WZ014036 for ; Sat, 13 Mar 2004 13:05:06 +1300 From: Neil Fenemor To: freebsd-questions@freebsd.org Content-Type: text/plain Message-Id: <1079136251.29695.11.camel@acer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 13 Mar 2004 13:04:11 +1300 Content-Transfer-Encoding: 7bit Subject: IPSec/NAT/Gateway Question X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2004 00:10:07 -0000 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.