VPN scenario 2 and 3 problems

Paul's picture
5
2009

So what are the common problems encountered with scenarios 1 and 2 ?
 

  • I can communicate with one PC at the far end but not the others...
    Judging by the content of forums, this is a very common problem to experience and to resolve it we have to operate methodically, use what we know about DNS and Routing and use our ping test to help us with the diagnosis.
     
    Step 1: Ping the DNS address of the PC which we are trying to access. If we receive a response, rather than a timeout, then we can access the PC, subject to Sharing and security arrangements. If we do not receive a response we move to Step 2...
     
    Step 2: Ping the IP address of the PC which we are trying to access. If we now receive a response and did not in Step 1 the issue is caused by DNS. If there is no DNS Server on the internal network (external DNS Servers are unavailable due to the security of the VPN connection) then we have two options: use IP addresses instead of PC names, or; create a lookup table to correlate IP addresses to PC names. In Microsoft Windows the lookup table we use is called ‘lmhosts' and a sample file (lmhosts.sam) can be found in Windows\system32\drivers\etc. Using lmhosts is very simple and for Windows users is very well documented on the Microsoft web site. Be aware, however, that if you are using DHCP on the internal network (this is the default setting of most Internet Gateways) and your internal IP address changes you will have to manually update the lmhosts file. If we do not receive a response in our ping test we move to Step 3...
     
    Step 3: Establish a route to the PC we wish to access. Steps 1 and 2 have ruled out DNS as the source of the problem and have led us to the conclusion that we cannot access the PC because the network does not know where it is, because it has not been told. Routes can be entered (as explained earlier) as temporary (the default) so they are lost following a restart or perpetual, so they survive a restart. However, you should only use perpetual routes if you only remotely connect to one network and you use fixed IP addresses. Otherwise, its safer to use temporary routes and if they are utilized often they can be entered via a batch file.
     
    If we want to avoid the use of routes we need to set up our network in such a way that it knows where to find the connected computers over a VPN connection. We do this by selecting one PC and making it the Default Gateway and DNS Server for all the other PCs on the network. The PC we have selected uses the Internet Gateway as its Default Gateway and DNS Server. It does not matter that the selected PC or the Internet Gateway are not DNS Servers, since they will simply forward the request on to their own DNS Server in turn until a response is received. This setup resolves the routing problem but the selected PC must be left switched on at all times and should have ‘sleep mode' disabled, otherwise users of the other PC will lose internet connectivity. If you can't guarantee this you're better off sticking to Routing Tables.

 

  • On occasions I cannot access network resources...
    Most VPN connections which are not reliant upon dedicated hardware (such as the solutions provided by FortiGate) are Demand Dial Perpetual VPN connections. Again, that may sound contradictory but what it means is that once a VPN connection is established it will stay connected unless it fails (for example, because the connection to the Internet is disrupted by the ISP). Once Internet connectivity returns the VPN connection will not connect until something demands it to connect (for example, a request to access resources at the far end). 
     
    Since it takes a few seconds for the VPN connection to be established, there is a risk that the request could time out and report an error during the connection process. Normally, if the user merely repeats the request the problem will have cleared itself.
     
    The likelihood of this problem occurring can be reduced if some system task at each end of the VPN connection must be carried out at a regular internal. For example, referring to the Figure for Scenario 3, if the Servers at each end of the VPN connection need to replicate, the replication requests will demand a VPN connection if one is not present.