One of the satellite clinics here in Lilongwe has enough users that it really should be connected to our main site with a site to site VPN. People are wanting to use Outlook for email, we need to be able to push out group policies, people should be able to log on to the Active Directory domain, etc. We had a client-server based VPN (OpenVPN), but it’s not easily possible to login to AD or apply group policies. Things would just be a lot simpler if there was connectivity between the LAN’s at both locations.

This was done in the past through another ISP here. It sort of worked, but they were extremely expensive. Unfortunately, instead of having quality hardware, we have several cheap DLink VPN routers. We probably would have had a lot fewer issues if they simply had Cisco routers or a Linux box at the remote site that we could use OpenVPN with, but unfortunately that’s not the case.

image

We were eventually able get them connected, though there seems to be no way to control what traffic it routes over the tunnel. With a Cisco site-to-site VPN, an access list could be used to control which traffic is tunneled and which traffic is not. The former service provider used a proxy to get around this and send all web traffic through our Internet connection, but man is that a ugly solution. Also, both the dynamic routing (with RIP) and SNMP monitoring “features” of these devices appear to do nothing at all.

Right now we’re having problems with traffic between the sites. ICMP works, but HTTP generally doesn’t. OpenVPN worked fine.

Right now, I think our problems are related to the MTU (maximum transmission unit), the maximum size of packet that a device can handle. Most 100 Mbps Ethernet equipment supports MTU’s of around 1500 bytes. This can frequently be a problem with VPN’s, because the VPN endpoints encapsulate the original packets inside of IPSec/GRE/OpenVPN/etc. packet. For an example, let’s assume that the MTU for path the VPN tunnel is traveling between its endpoints is 1500 bytes, and the overhead from the VPN is 50 bytes. If computer A sends a packet that’s 1480 bytes, and the VPN endpoint X encapsulates it, the resulting packet is over 1500 bytes. This means that the MTU for traffic going through the tunnel is less than the typical MTU because of the overhead caused by the VPN connection.

image

This can cause difficult to troubleshoot problems with a VPN tunnel, because some traffic, like normal pings/ICMP, that is well under the MTU will pass through the tunnel just fine, but larger packets can’t “fit” in the VPN tunnel.

Another interesting note however is that the DLink router works when its at another location, meaning that it could be related to the ISP’s configuration.