Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Mar 2004 09:55:31 +1300
From:      Neil Fenemor <Neil@TS.co.NZ>
To:        freebsd-current@freebsd.org
Subject:   IPSec/NAT/Gateway Query
Message-ID:  <1079038531.29695.2.camel@acer>

next in thread | raw e-mail | index | archive | help
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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1079038531.29695.2.camel>