VPN to a Remote Server without Abandoning Your Local Network

This article is specifically about creating a VPN from an Ubuntu client (with openvpn) to a Windows Server 2003 network.  You ought be able to make adjustments from what I present to make this useful in a number of related situations.

I did this work between an Ubuntu 8.10 machine and a client network where SBS 2003 was the only server present (behind a firewall).  I leave it up to you to set up the machines/firewalls as appropriate.  What I will show here is how to ensure that you are able to connect to the remote server using RDP while still being able to attach to local network resources and the Internet.

I work as an IT professional and need to be able to do this for professional reasons, for instance I need to be able to ensure a solid instant messaging connection while I sign into and out of client VPN’s and client servers.  This does represent a security risk to both your local network and to your client networks (as each network becomes reliant upon the assumption that the other network firewall and viral protection will succeed—and we all know what it means to assume).

In short, don’t come crying to me when you hose a network because I offered you these instructions.  Unless you believe I will see the comedic value present therein.

You’ll have to install openvpn on your Ubuntu machine.  This you will find natively in Synaptic.  I’ll hold…

Ok, now create your VPN connection:

  • Open Network Configuration (System —> Preferences —> Network Configuration).
  • Click the Add button and choose Point-to-Point Tunneling Protocol (PPTP) from the drop down menu on the dialog which follows (and then click the Create button)
  • Put your remote server address in the Gateway: field (such as vpn.remoteserver.com); enter your User name: for that remote network; and include the NT Domain: (you needn’t include the .whatever)
  • Click the Advanced button and ensure the Use Point-to-Point encryption (MPPE) is checked—the other defaults should be fine
  • On the IPv4 Settings tab click the Routes… button—you will create your routes using this dialog so remember how to return to it

You will add two routes—one for the local network and one for the remote network.  This is the tricky bit.

  • Close openvpn and connect to the remote network
  • Open a terminal and enter ifconfig
  • You will want your local Netmask (presumably listed with eth0 and called mask)
  • Click the Add button and create your first Route formatted as local.dns.server — Netmask.from.ifconfig — local.gateway.perhaps.router as numerical values (so maybe 192.168.1.2255.255.255.0192.168.1.1)

Again from the ifconfig information, find your VPN IP address, presumably under ppp0 (we’ll call our remote network 192.168.2.x) and the Netmask associated therewith.  Go back into Network Configuration and return to Edit this VPN so we may add the second Route.

  • Click the Add button and create your second Route as remote.server.vpn.address — vpn.netmask.from.ifconfig — local.machine.ppp0.address (so maybe 192.168.2.2255.255.255.255192.168.2.112
  • Close out of Network Configuration and go ahead and close and reconnect to the VPN in question

You ought to be able to RDP into the remote server, RDP into your local server, run Skype, run Pidgin, surf the Internet locally, run Transmission, all without breaking your VPN connection.

I’ll admit this is a rather quick and dirty solution so I’m all for reviewing your alternatives.

Best of luck, you crazy aardvarks.

Share

One thought on “VPN to a Remote Server without Abandoning Your Local Network

  1. I was working to connect to a desktop machine beyond a server into which I was vpn’d and ran into some troubles. First, it appears I would have to create a route for that particular desktop (I couldn’t see a way to create a range)–so 192.168.2.XXX (the desktop’s IP address) with a gateway of the server’s IP. I still wasn’t able to RDP into or ping the desktop (from my local machine), but that may have been due to missing routes on the server.

    I abandoned the pursuit as I was in a hurry to assist the client (and just RDP’d from the server to the desktop). In short, this may work but some additional testing would be required.

Leave a Reply

Your email address will not be published. Required fields are marked *