[Openswan Users] overlapping networks with nat-t

[John A. Sullivan III]

On Wed, 2006-01-18 at 19:09 +0100, Paul Wouters wrote:
> On Wed, 18 Jan 2006, Marco Berizzi wrote:
> 
> > I have successfully deployed NAT-T on my various
> > linux 2.6 (netkey) gateways with OSW 2.4.4. It's
> > working good with Windoze XPsp2. Now, mobile
> > users are able to connect to my private lan (which
> > is a 172.16.0.0/23) from others company private
> > networks. My osw box is also tunnelling ipsec traffic
> > from/to a (very common) 192.168.1.0 network. This
> > prevent roadwarriors which are connected to a
> > 192.168.1.0 network to connect to my network. I
> > cannot change any network ip address. Is there any
> > solution to this problem? DHCP over IPsec? Does
> > windows XPsp2 support it?
> 
> an ugly hack is to setup a tunnel for another range,
> eg 127.168.1.0/24 and then run SNAT / DNAT on the
> packets. Be careful not to NAT the ipsec packets
> though. This will be very hard using netkey.
> 
<snip>
This can be a real pain in the neck.  For example, we built the ability
to do this with a mouse click and few keystrokes into the ISCS network
security management project (http://iscs.sourceforge.net) but it still
breaks certain protocols, e.g., network neighborhood browsing (as an
aside, this is one of the very few things that iptables can't do that a
PIX can, i.e., NAT NetBIOS packets with embedded IP information in the
NetBIOS header).

We finally opted for a slightly different solution for most of our
production installations.  Not to take anything away from openswan -- a
truly great project -- but we went with openswan for our LAN-to-LAN
connections and OpenVPN for our RoadWarriors now that it has matured
from its early days.  We have been very pleased with the results and,
since it uses virtual IP addresses for the RoadWarriors, it almost
doesn't matter what real address they have.

We can still do handy things like dynamically adapt the iptables rules
based upon the DN in a user's X.509 cert and it blends seamlessly with
our openswan IPSec WANs.

Again, this is not to take anything away from openswan; it's a great
project and we use it all the time.  But we have found the combination
of openswan and OpenVPN to be a very elegant and practical solution for
our remote access needs.

The following is adapted from an internal memo we sent about changing
our RAS solution from IPSec to OpenVPN:

Because it runs in userspace rather than having to hook into the kernel
or the IP stack, it is much simpler.  It offers very impressive
advantages:

1) There is no need to uninstall existing IPSec clients.  In fact, if
anything goes wrong during the installation, they can simply keep using
the current solution until we fix the problem.

2) There is no need to regulate the home IP address space.  All
addresses are virtualized.  This gets us around the problem of multiple
users behind the same NAT gateway when using L2TP or multiple users with
the same internal address behind different NAT gateways when using
IPSec.

3) Even though it uses virtual addresses, it maintains and, in fact,
enhances the security we have with ISCS.

4) Even though it uses virtual addresses, there are no problems with NAT
or any broken functionality such as network browsing.

5) It does not break the local network.  In other words, the other
product disabled all access to the local network when on the VPN.  The
desire was to prevent simultaneous Internet access but the downside was
it broke things like home printers and home file sharing.  This product
preserves the safety of not allowing simultaneous Internet access but
still allows access to local printers, etc.

6) The product works from virtually anywhere -- private addresses,
public addresses, even behind the most stringent firewalls.  The primary
connection uses a UDP connection but the firewall doesn't allow anything
except web browsing, we have a secondary connection which works over
HTTPS - like an SSL VPN.  We can dispense with the xxxxxxxx corporate
decision to not support public IP addresses just to accommodate the RAS
product's shortcomings and the routing problems.

7) It allows the keys to be password protected and allows the user to
change the password mitigating the exposure in the event of a stolen or
improperly discarded computer.

8) It has a very user friendly GUI that eliminates all the complaints of
the IT department about the application closing when one closes the
application!

9) The product is still free, open source and does not lock xxxxxxx into
any one vendor's solution.

10) It involves no complicated importing of keys and certs.  In fact,
one does not even have to extract the keys and certs from the PKCS#12
file (the bundle of encrypted keys and certs).  One simply copies the
PKCS#12 file into the proper directory and names it keys.p12.

11) Maintenance costs are dramatically less.

12) It does not require the Windows patch and registry change to permit
Windows authentication to work through the VPN.

13) It does not require that we walk the user through manually changing
their DNS.

14) It does not require that we walk the user through manually changing
their WINS settings.

The only disadvantage is that it will not have the speed of a kernel
level solution but that is fine for remote access.  The bottleneck is
the wire.

Hope this helps - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan at opensourcedevel.com

Financially sustainable open source development
http://www.opensourcedevel.com