Hands on: Troubleshooting remote access

Remote Lan access can be tricky to get right, so I thought I’d share one problem I came across recently which could cause a lot of head scratching, especially if you’re not familiar with networks and addressing schemes.

It involved a company wanting to enable staff to work from home, using a very simple virtual private network (VPN) solution. To this end the company had purchased and installed a Draytek ADSL router with a built-in VPN server.

Like others, the Draytek router supports a variety of tunnelling protocols, but to keep things as simple as possible the company had opted for a basic PPTP (Point to Point Tunnelling Protocol) implementation. Not the most secure, admittedly, but easy to set up and it was working well with several users configured on the router, connecting from home using the client software in Windows XP.

Another benefit was the ease with which new users could be added, with the network administrator simply creating a new account on the router then talking the user through the configuration work required to connect on their home PC or laptop.

One new user, however, couldn’t get it to work, so I was asked to investigate. She confirmed that she had internet access and had configured a VPN connection in Windows XP, using the same parameters as everyone else. On the face of it, all seemed to be working correctly. Windows XP was reporting a successful connection when she selected the icon on her desktop, but she couldn’t see her files on the company server. Neither was she able to work on her email held in an Imap folder on the office mail server.

Naturally, we went through all the settings again, but found everything as it should be. We made sure the VPN server was up and working and that a suitable account had been configured on the router to enable her to connect remotely. Again, everything was in order and, when we checked the active connections, the router reported her as successfully attached using a PPTP tunnel.

I started to suspect it was the way the home network was configured, and that’s when we discovered the true cause of the problem.

Like a lot of small companies, the office network involved was protected using Network Address Translation (Nat) on the router with a single local subnet in the 192.168.0.0 range. VPN users were set up to be assigned an IP address between 192.168.0.50 and 192.168.0.100 using the host DHCP server, also provided by the router. Unfortunately, the router on the home network was also Nat protected and configured to use the same 192.168.0.0 subnet internally.

This didn’t stop the tunnel being successfully established. However, because the subnets were the same at each end, the Windows PC on the home network was unable to distinguish between packets that needed to be sent down the tunnel to the remote Lan and those addressed to other devices on the local network.

There were several ways in which we could have solved this, including switching to a more complex IPSec VPN or tweaking routing tables. However, to minimise the amount of work involved, we felt it better to change either the subnet on the office network or the user’s home router.

Changing the office network would also have involved a fair amount of work because of the servers and several network printers with fixed addresses. So, at the risk of encountering the problem again, we opted to change the user’s home router to use the 192.168.1.0 subnet and assign addresses in that range to her PC and any others she might connect to the Lan.

The only slight hiccup was that she couldn’t remember the router password. It turned out to be the default for the model involved, so it didn’t hold us up for long. And, of course, once we’d made the change and confirmed that she had VPN access I made sure we also changed the administrator password to something less obvious.

Like this story? Spread the news by clicking below:

 del.icio.us     Digg this     reddit!