I work remotely and use OpenVPN to access development services such as SVN and our file server, both of which are at our colocation facility.
While at a new location, I first encountered a problem trying to do any SVN operations. Turned out that any significant traffic to any server at the colo would cause my SSH session to freeze. For example, I would SSH into a machine and issue the ‘
ps‘ command and the short list of processes would be returned just fine. When issuing ‘
ps aux‘, however, only the first couple of the processes would be displayed, but then the SSH session would become permanently unresponsive. Other significant activity, including ‘
vi‘, would also cause the session to become unresponsive, and ‘
svn up‘ over
svn+ssh would also fail.
My DSL connection at the new location was PPPoE, which adds a little bit of overhead to each packet. Our OpenVPN server is configured with UDP and a 1,542 byte MTU, which is apparently too large to fit into a UDP-in-PPPoE packet (and UDP can’t adapt like TCP can).
So, when it came time for the colo server to send a large packet to the client (or v.v.), the packets would be discarded and the session would become unusable.
You can force OpenVPN on the client side to use a smaller MTU so that all packets will fit within the PPPoE packets by adding the following line to your ‘
my_connection.ovpn‘ file and then reconnecting:
While unlikely, you may need to use a smaller value (or you could also experiment with larger values up to the 1,542 default).
That sounds like that was a lot of “fun” to figure out. How long before you discovered the cause?
At first I assumed it was some server-side issue and just lived with it =) It was after about a week when server access was more necessary that I asked if anyone else had issues and nobody did.
Then it didn’t take much troubleshooting to realize that any connection through the VPN could be affected, and from there search results revealed the solution pretty quickly.