Select Page

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
    #remoteip 192.168.0.234-238,192.168.0.245
    # or
    #localip 192.168.0.234-238,192.168.0.245
    #remoteip 192.168.1.234-238,192.168.1.245
    option /etc/ppp/options.pptpd
    logwtmp
    localip 192.168.2.1
    remoteip 192.168.2.21-25

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 203.0.178.191
    ms-wins 192.168.1.110
    name pptpd
    refuse-pap
    refuse-chap
    refuse-mschap
    require-mschap-v2
    require-mppe-128
    proxyarp
    lock
    nobsdcomp
    novj
    novjccomp
    nologfd

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.