From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 13 08:48:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA1E116A4CE for ; Sat, 13 Mar 2004 08:48:39 -0800 (PST) Received: from atomicpile.sk (webhosting.soto.sk [81.0.210.135]) by mx1.FreeBSD.org (Postfix) with SMTP id B5B3543D2F for ; Sat, 13 Mar 2004 08:48:38 -0800 (PST) (envelope-from iso@atomicpile.sk) Received: (qmail 12495 invoked by uid 523); 13 Mar 2004 16:48:37 -0000 Date: Sat, 13 Mar 2004 17:48:37 +0100 From: Karol Mares To: Neil Fenemor Message-ID: <20040313164837.GA12295@atomicpile.sk> References: <1079136183.29695.9.camel@acer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1079136183.29695.9.camel@acer> User-Agent: Mutt/1.4.1i X-Editor: Vim http://www.vim.org/ X-Operating-System: BSD/isoBSD 1.1 (i386) X-Uptime: 5:39PM up 2 days, 21:20, 1 user, load averages: 0.07, 0.10, 0.08 cc: freebsd-hackers@freebsd.org Subject: Re: IPSEC/NAT/Gateway Query X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2004 16:48:39 -0000 Hi there, * Neil Fenemor (Neil@ts.co.nz) wrote: > 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. > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Do u use UDP-encapsulation? Coz when u use IPsec ESP, there is a incompatability btw IPsec ESP and the NAT/PAT, also there is problem with the checksum, the value of checksum is zero, so there is a little imcompatibility with the NAT checksum functions.IPsec packet without udp-encapsulation is like IP/esp/encrypted data/HA SH/ so there is and error in esp, ipsec packet with udp-encapsulation looks like this: IP/P a y l o a d/ - OK. km