6. Network and Client Notes

6.1 Bridging and ProxyArp versus Routing

Getting windows networking and more specifically network browsing to work on a routed network can be extremely painful.

The most common problems are:

1. Clients with IPX/SPX and other non IP protocols enabled for NetBios (SMB). Even one of these is sufficient to make sure that the browse lists do not converge.

2. Lack of WINS support in networks with pre-W2K clieknts or DNS not enabled for name resolution in W2K+.

The easiest way to avoid these problems is to proxy-arp the RAS connection onto the local LAN or to bridge two networks across a VPN. This is the default MS RAS setup. It is also the most common setup in many windows networks. It is terribly inefficient and on some narrowband links more then 50% of the network bandwidth will be taken by windows broadcast traffic.

The only way to avoid this is to use IP routing as well as working name resolution. Setting up WINS or using DNS in W2K networks is outside the scope of this document. They are resonably well described in the Samba or Microsoft documentation.

Special Bridging Case - OpenVPN

OpenVPN is to some extent a special case because it does not have any internal mechanisms for negotiating IP addresses or transferring any network setup information to a client. As a result if you want to minimise your RAS management problems you have to bridge the OpenVPN clients and use DHCP to set the relevant network parameters. When used on a large installation, it will decrease the efficiency so it may be a good idea to bridge clients to a different network and route this network back to the main installation. This way clients can get IP parameters using DHCP without drowning in broadcasts. Additionally it may be a good idea to set the netbios node type via DHCP to be 2 (unicast). As a result the clients themselves will not attempt broadcast resolution on their VPN interfaces.

ddns-update-style interim; 
update-optimization true; 
do-forward-updates true; 
subnet 3.4.5.0 netmask 255.255.255.0 {   
   range dynamic-bootp 3.4.5.128 3.4.5.254;   
   option broadcast-address 3.4.5.255;   
   option routers 3.4.5.1;   
   option domain-name-servers 4.5.6.1, 4.5.6.2;
   option ntp-servers   4.5.6.3, 4.5.6.4;
   option netbios-name-servers  4.5.6.5, 4.5.6.6;
   option domain-name "ras.example.com";   
   netbios-node-type 2; 
} 

6.2 Dealing With Unreachable Entries in a WINS environment

Windows machines will register multiple addresses in WINS for every one of its interfaces, so you may run into problems with WINS pollution when clients try to access an IP address which is unreachable. In most cases Windows will try all IP addresses resolved for a system until it succeeds, so it is important that it gets a RST or UDP unreachable for the "wrong" ones. The best way to do so is to configure the external firewall to return ICMP error codes for UDP ports 137-139 and ICMP error codes or RSTs for TCP ports 137-139,445 instead of dropping them.

Alternatively, you may disable Windows Networking on all interfaces except the VPN access ones. Unfortunately, this is not always an option. One of the few cases where this can be used in a company environment are wireless LANs. It is also a good idea to use extensively NetBios node type 2 for all networks that do not have a server present so that they are forced to do all of their name resolution over WINS or DNS.

6.3 Dealing with Certificates under Windows

There is a number of limitations in the way Windows handles certificates and some of them are outright strange. I would prefer not to use the words "deliberately crippled", but it is fairly close. More specifically, with Windows itself in a non-AD environment you cannot: remotely manage certificate stores on client machines, create a certificate request and perform some certificate operations. Some of these suddenly start working once you have AD which at the time of W2K release was a near equivalent of having a windows only environment.

If you do not have AD you will have to perform the certificate management manually on the client machines. Probably the easiest way to do this is to use the MMC tool and load the relevant certificate management and IPSEC controls. If you intend to use the certificates for IPSEC you will have to chose the computer account (not the user account). Note that IPSEC in all cases except the "magic" adhoc policy for L2TP will default to AD/Kerberos and you have to specify Certificates for authentication.

Another limitation of Windows is that it has a very short limit on the length of P12 import passwords. I have not tried to determine the actual limit, but it is definitely shorter then the password prompt field and definitely less then 17 characters.

6.4 IPSEC policies under Windows

These are reasonably straightforward and can be easily configured using the relevant control in MMC. Note that Windows will follow its own policy and if the informational part of IKE phase 2 carries different definitions it will still complete the negotiation (important difference from for example checkpoint). Racoon on FreeBSD behaves identically. As a result you may end up with packets lost after a successful IKE negotiation if they do not match the policy at the other end. This is one of the conditions that are really hard to debug as there are no indications in the logs.