[Openswan Users] overlapping networks with nat-t

[Jacco de Leeuw]

John A. Sullivan III wrote:

> we went with openswan for our LAN-to-LAN connections and OpenVPN for
> our RoadWarriors now
> 
> 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.

I understand that this is in the pipeline for Openswan 2.5.x.

> 4) Even though it uses virtual addresses, there are no problems with NAT
> or any broken functionality such as network browsing.
> 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).

The upcoming Openswan 2.4.5 should fix a lot of these NAT-T problems.

I've never heard about NetBIOS packets with IP addresses in them. Wouldn't
that violate the OSI layer principle? Anyway, with L2TP/IPsec the client
gets an IP address on the internal network so NAT is not needed.

> 5) It does not break the local network.  In other words, [...]
> preserves the safety of not allowing simultaneous Internet access but
> still allows access to local printers, etc.

This works on L2TP/IPsec too but you would have to use IP addresses
instead of hostnames because the DNS and WINS servers (may) change
when the VPN connection goes up.

> 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.

That brings up a fundamental discussion about firewalls. "This pesky firewall
prevents me from connecting so let's disguise everything as HTTP so the
firewall won't notice".

> 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.

Good point. This is a limitation of the Microsoft IPsec client. You cannot
put a password on the private key of a 'machine certificate'. Nor can you
store the private key of a machine certificate on a hardware token. However,
the second stage (PPP) authentication is protected by a password. Of course,
nothing prevents the user from taking advantage of Windows suggesting to
'remember' the password for him. I would not be suprised if OpenVPN sports
this feature as well...

The built-in IPsec client of Mac OS X does protect private keys with a
password through its Keychain application.

> 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.

You still have to roll out the client software and keys to your users.
I don't see how that is any different from distributing and importing
PKCS#12 keys in the (L2TP/)IPsec case. I agree that the MMC route is
dreadful for importing a certificate but it can be automated using
a command line utility or a GUI.

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

See above. Patching the registry is at least as much effort as rolling out
client software.

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

This is automatic with L2TP/IPsec because it is based on PPP (dial-up
networking).

I think you forgot to mention OpenVPN's unique Ethernet bridging support.
It should help solve a lot of connectivity problems, at the expense of
some network efficiency.

Jacco
-- 
Jacco de Leeuw                         mailto:jacco2 at dds.nl
Zaandam, The Netherlands           http://www.jacco2.dds.nl