From owner-freebsd-current@FreeBSD.ORG Thu Mar 11 13:02:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D063E16A4CE for ; Thu, 11 Mar 2004 13:02:02 -0800 (PST) Received: from sage.ts.co.nz (sage.tasman.net [202.49.92.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27AC543D1D for ; Thu, 11 Mar 2004 13:02:02 -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 i2BKwuZJ026282 for ; Fri, 12 Mar 2004 09:58:56 +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 i2BKuWqG025629 for ; Fri, 12 Mar 2004 09:56:33 +1300 From: Neil Fenemor To: freebsd-current@freebsd.org Content-Type: text/plain Message-Id: <1079038531.29695.2.camel@acer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Fri, 12 Mar 2004 09:55:31 +1300 Content-Transfer-Encoding: 7bit Subject: IPSec/NAT/Gateway Query X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2004 21:02:02 -0000 Hi all, This is a little off topic, and isn't directly related to the WifiBSD project, however I believe it to be an important part of WiFi security in general, and should be discussed by the list (and it would help me work this out as well I hope). 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.