wireless Digest, Vol 2, Issue 3

[Jim Carter]

On Wed, 5 Feb 2003, Vic Berdin wrote:
> "FreeS/WAN can't stand nonunique IP addresses on
> clients, such as 192.168.0.1"

> See, I've been trying a VPN FSwan/WIN2K InterOp wherein the internal ifc
> of my WIN2K becomes 192.168.0.1 as a result of WIN2K internet sharing.
> And I've been trying, with no luck, to establish a subnet-2-subnet tunnel
> between my Linux sub and this WIN2K 192.168.0.0/24 sub to form. Could
> this "non-unique" IP you mention be the cause of my short comings?

If the FreeS/WAN server is at the same time trying to communicate with
another 192.168.0.0/24 subnet, then strange things will happen.  I'm not
expert enough to predict exactly where it will break, but definitely it
won't work.  But if, for testing purposes, you can guarantee only one
192.168.0.0/24 at a time, you should be able to set it up.

This assumes that at the remote end, replies to 192.168.x.x will go to the
FreeS/WAN machine.  The sample configurations assume you're going to run
FreeS/WAN on the egress router of your net, which satisfies the
requirement.  In my case (Cisco routers) I have FreeS/WAN on a bastion
host, and it uses NAT on the IPSec payload packets, so the answers come
back to it rather than going out the default route and being lost.

In the case I envisioned, two "road warriors" using identical NAT
configurations each set up a tunnel to 192.168.0.1/32 (their machines
only), and there's a shootout in FreeS/WAN over which tunnel is real and
which gets replaced.  I think.  Ignoring the minor detail that Pluto
doesn't like ISAKMP through NAT, so you would have to use manual keying.
The issue is not specifically the 192.168.x.x net, it's uniqueness of IP
addresses.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc at math.ucla.edu  http://www.math.ucla.edu/~jimc (q.v. for PGP key)