Open VPN Notes

5/30/2009

I just set up a VPN using OpenVPN. What an amazing piece of software OpenVPN is. Here are a few tips and tricks for non standard setups that I hope will save someone else some time.

Why a VPN?

I often travel to countries that block not just many normal websites, but many ports. This is common in many parts of The Middle East, but also in many hotels and even many Western European ISP's port block extensively as well. While staying in France for 2 months I found one of the major ISPs blocks nearly all ports and just opens what they feel is common. This is exceptionally stupid, because they left open port 25 to allow complete spamming, but closed of the secure mail ports 466 and 995 which cannot be used for spamming. They also block nearlly all UDP ports.

Most VPNs used PPTP which uses GRE, or use IPSec. Both are very easy to block and in fact many ISPs block these or have poorly configured routers that interfere. Some hotels even charge for VPN access, assuming that corporate users will pay up. That is, $20 for internet, $30 if you want to use a VPN.

OpenVPN

This is one of the many major advantages to OpenVPN. Open VPN only uses standard IP and does not require GRE nor IPSec. It can be configured to use UDP or TCP, and can even connect over other proxies such as tunnels, SOCKS, or even HTTP proxies. Because of this I have set up an OpenVPN server using TCP on port 80. This ensures I should be able to connect to my VPN and then the Internet with unrestricted access from just about anywhere in the world.

Did I mention OpenVPN is also free, and is open source? It is also quite well documented and supported.

Things I encountered

I have a few non standard requirements. Here are a few issues I encountered and solutions in hopes that others who encounter these can find answers here.

When you change a config...

During the process I changed subnets, gateways, and other options in the server config. However  between changes I did not reboot the client. OpenVPN pushes  many of these routing changes down to the client. They are not persistent and will not survive a reboot, but will survive a reconnect. Becuase of this I often had old routing information that was invalid now. On several occassions this caused a valid OpenVPN configuration not to work.

If you make major configuration changes to the server and reconnect, you should check the client routing table. On Windows you can use:

route print -4

Then

route delete x.x.x.x

to delete the invalid routes. If you are not familiar with routing, reboot the client between major server configuration changes to reset the routing table.

Subst and Network Drives

.ovpn files cannot be run on subst drives, and possibly not from network drives as well. OpenVPN runs in a layer below user space and thus cannot see such user level mappings.

UDP or TCP?

It is better ot use UDP for OpenVPN. This is because with TCP, when the network gets bad you can get "retries over retries". That is the TCP connection running inside the VPN sends retries, and so does the TCP connection carrying the VPN traffic. This causes a cascading effect.

However UDP does not travel well through many NAT setups, and is often blocked by many firewalls. TCP is much more reliable with regards to being able to "get through".

If you are in the situation I am, use TCP. Generally it works pretty well, especially if your connection is pretty good.

tun or tap?

tun tells OpenVPN to just carry IP traffic (TCP, UDP, etc). tap carries all traffic, even non TCP/IP such as IPX and NetBIOS. Most users just need TCP/IP.

tun is more efficient as it has to carry less data. Generally users should use tun, however tap is better in some cases.

tap requires the whole ethernet frame to be transmnitted. tap also requires bridging on the server side. (If you are bridging and including a VMWare NIC on the host see here) With TCP traffic, this adds about 40 bytes to every packet. Most TCP packets go out rather full, so assuming a size of around 1500 bytes, the extra overhead is about 2.5%. tap configurations however also provide automatic bridging on the server, and allow you to share the same subnet on the server as server side computers. This elimintes a lot of routing configurations. In my case I cannot turn on IP forwarding becuase of MAC filtering server side, so with tap I was able to run a NAT setup, as well as access all server side intrnal back side machines. tap not only solved one problem regarding MAC filtering, but also removed the need to setup routing between subnets.

In addition, to offer OpenVPN on multiple ports or protocols you have to run multiple instances. This means separate subnets for each instance. For example, I want to run UDP for speed when UDP is available, but TCP when I'm in a really restricted environment. To do this I would need three subnets, one for server side, one for the UDP instance, and one for TCP instance. I alos need communication between my OpenVPN clients, so the routing becomes quite complex. With tap, all instances can share the same subnet by allocating small blocks of the subnet to each instance.

Specifying Gateway with tap

I kept following the howto about trying to push a gateway down to the client. In my case, my gateway is not the same machine as OpenVPN is installed on, so I had to  specify it manually. I kept using the push options, but kept getting the IP of the OpenVPN machine pushed down instead.

The first parameter in the server-bridge directive is the gateway, not the OpenVPN machine as one might assume. So simply change it from the default to the gateway you need, and then also add the directive:

push "redirect-gateway def1"

Be sure to use the def1. With def1, when OpenVPN is connected its gateway will override your other gateway, but when OpenVPN disconnects your old gateway will be intact. If you leave out def1, OpenVPN will wipe out your other gatway and you will have to renew your IP (if using DHCP) to restore your original gateway after disconnecting OpenVPN.

WARNING: Bad encapsulated packet length from peer

This one drove me crazy for a while. The full message actually was:

WARNING: Bad encapsulated packet length from peer (18516), which must be 
 > 0 and <= 1576 -- please ensure that --tun-mtu or --link-mtu is equal 
on both peers -- this condition could also indicate a possible active 
attack on the TCP link -- [Attemping restart...]

Taking its advise, I tried messing with tun-mtu and link-mtu options to no avail. The error message is actually wrong. This message is kind of a fallback for OpenVPN in many cases. In my case I had misconfigured my DNS to use the wrong IP, and so my OpenVPN client was actually trying to connect to a webserver on one of my other servers rather than the OpenVPN server. During debugging I also accidentally connected to an FTP server with the same results.

So if you are using TCP and getting this message, verify that what you have specified in the client statement is correct as OpenVPN displays a misleading warning in such cases.

<< Previous Entry    Next Entry >>

Use my contact form to contact me directly.