My first point of contact to any new clients is usually via a computer or network problem which they need repaired and over time as you do more work for these clients more interesting and complicated tasks arise.
This came up quickly with one client who was using a very simple Linux (Debian flavour) server whose motherboard had failed. The first task at hand was to recover the data off the hard drive and , as I have a couple of Linux boxes for web development purposes, this was a not a problem as the data was intact and the client could continue working from a portable hard drive.
The debian server was being used as a file server internally at their office and for remote access via VPN when he was offsite. I made a quick attempt to find a replacement board but this not practical given the age of the board and the linux build.
The client used a small number of mainly Windows XP computers at their office to access the file server and therefore did not use the Linux server as a Print Server but rather printed directly to the TCP port under Windows. No problem at all I have built plenty of these servers for myself and other clients. I am not going to explain now to do a Linux build as there are plenty of HowTos on the web other than to say I used CentOS release 6.2 (Final) with Linux build 2.6.32-220.4.2.el6.i686 i686.
The build of the hardware and linux installation went smoothly and the installation was completed within a week and the clients could access their data and remote VPN into the box however a problem arose. This is not surprising as there will always be something you miss given the urgency of the situation
I had setup the Servers VPN settings with the following pptpd.conf file setting
- .#localip 192.168.0.1
and this worked fine until I found out the client had been able to take his laptop from work to his home and print to his work printer without using the Linux computer as a print server but printing directly on port 192.168.1.49 from XP.
I initially tried to setup to print via CUPS on the VPN but this proved slow and problematic so the question arose how do you expose the remote network devices directly to the local network.
The answer to this is to use PROXYARP in the options.pptpd.options
- ms-dns 18.104.22.168
and remove the localip and remoteip settings from the pptpd.conf.
Proxyarp is a way of connecting to physically separate networks as they are on the same subnet , it in effect bypasses any firewall.
Now I could VPN and reach the remote IP address of the printer from the local network. You could also do this by adding a rule to the firewall but PROXYARP is definitely the easiest to implement.
So all was good right? Well no unfortunately both home and office networks were managed by Billion ADSL Modem routers and which by by default use the private network 192.168.1.1 and a default gateway of 192.168.1.254 which can give rise to all sorts of problems..
One of them is that it turns out XP does not handle this scenario particularly well , Windows 7 does, and so when the client was at home connecting remotely via his home ADSL modem router he could VPN but not surf the web and this meant setting the use default gateway on remote network so that all the traffic goes via your VPN.
Of course the client wants to VPN using his wireless broadband stick and surf the web making his web traffic ridiculously slow.
The answer to this is change to a different private network on the home address.