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 ->  : works perfectly
rfc 1918 -> x.y.z.11 -> x.y.z.254 : Fails
rfc 1918 -> x.y.z.11 -> x.y.z.254 -> : 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

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.


Neil Fenemor

Senior Systems Administrator
ThePacific.net Ltd.

[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to