[Openswan Users] overlapping networks with nat-t

[Peter Farrow]

 >>>NetBIOS packets with embedded IP information in the
 >>>NetBIOS header).

You might want to take a look at this:
http://www.unix.org.ua/orelly/networking_2ndEd/fire/ch14_03.htm

NETBT is what you are describing here, personally I would not want 
network neighbourhood browser traffic going over WAN links from each 
client on the LAN, you would use WINS servers with replication partners 
to facilitate this, clogging up WAN tunnels with this traffic would 
impact performance severely on networks with a large number of clients.  
Using WINS servers elminates this....

P.



Jacco de Leeuw wrote:

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