Last Edit: Apr 03, 2006 at 12:37 (4,154.86 days ago)created by Steve Gibson

What you DON'T want to have happen

Here's the nightmare: You are away travelling, checked into a hotel with your laptop. You deliberately left a Windows machine running at home or at work with OpenVPN installed and waiting for incoming connections. Following this guide, you opened a port through your base station router to the OpenVPN machine so that it can receive incoming connections from the Internet. You have also created your own unique set of security credentials so that no one else on Earth can fool your home network into accepting a connection. And all of this has been tested several times from outside your network to see that everything works.

So you settle down in your hotel room to connect to your home or office network. You get on the Internet from the hotel room and initiate a connection back to your base station . . . and nothing happens. After ten or fifteen seconds you cancel the connection attempt and try again. Still nothing. You verify that your laptop is on the Net (the GRC.com web site comes up just fine. :) So you try again to connect to your home base . . . but OpenVPN can't connect.

What's wrong?

Something about the configuration of the local hotel's network is blocking your connection attempts. They might have the default OpenVPN port 1194 blocked by their network firewall (if that's the port you are using). But it appears that whatever port you are using is having no success.

What's the solution?

The entire goal for a remote connectivity solution is a robust and reliable means for connecting no matter where you find yourself. So the more different possible ways you have to connect the greater the chances that you'll be able to find at least one way to reach your home base no matter what network conditions separate you.


There are three approachs to solving this problem:
The standard way, the complex way, and the GRC way . . .

The standard way

Actually, the standard way is to neither recognize nor solve this problem at all. I have never found any resource that talks about running multiple simultaneous instances of the OpenVPN server in order to be able to accept incoming connections on multiple ports and protocols.

So most people fire up only one copy of OpenVPN, choose to have it use either the TCP or UDP protocol, and probably leave its default port set to 1194. They assume, if they ever stop to think about it, that they'll never have any trouble connecting to their machine from wherever they may be in the world.

Perhaps if they are always lucky they'll be right. Or perhaps they run across a remote network that, for whatever local administrative reason, blocks their sole means of access. Then they're out of luck. As we saw above, to have the greatest chance of establishing a connection back to home base it's useful to create more than means of connecting:

The complex way

Untortunately, the current release of OpenVPN (v2.0.5) only allows the user to specify a single protocol (TCP or UDP) and port number for the server to listen for incoming connections. Allowing multiple simultaneous listening ports is trivial from a programming standpoint, but the problem doesn't seem to be on the OpenVPN developer's radar. I would do it myself since OpenVPN is open source. But that would fork the source and cause lots of other problems.





















To learn what the resulting system will and will
not do, please read our Howto guides goals.




We encourage you to read through these pages in sequence (many are short):

1  Intro and background 
8  Create virtual NICs 
15  Dynamic DNS Service 
2  Howto guide goals  
9  Win 2000 bridging 
16  Testing the system 
3  Howto guide overview 
10  Win XP bridging 
17  HotSpot VPN Service 
4  Routing vs bridging 
11  FreeBSD bridging 
18  OpenVPN Alternatives 
5  Plan before you begin 
12  GRC's config files 
19  Howto guide FAQ 
6  Install OpenVPN client 
13  Secure certificates 
7  Install OpenVPN server 
14  Port forwarding 
20  Send us feedback 

Jump to top of page
Gibson Research Corporation is owned and operated by Steve Gibson.  The contents
of this page are Copyright (c) 2016 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy.
Jump to top of page

Last Edit: Apr 03, 2006 at 12:37 (4,154.86 days ago)Viewed 11 times per day