Tuesday, October 16, 2007

Coping with IP Conflicts

I'm on holiday in Jolly O'l England, but wanted to get a bit of work done this morning. Specifically, I wanted to ssh to some boxes back at the office. This is easy - just connect to the free WiFi, start up the VPN and ssh over.

All went well, except for the ssh part. My ssh attempts all failed with a timeout.

After a bit of diagnosis, I realized that the free WiFi of the hotel was putting me on the 192.168.x.* network, and my work network was also 192.168.x.*. The result, when I tried to ssh to my servers back home, the packets were routed to the local network.

D'oh.

Solution #1

My first attempt to resolve this issue was to setup a ssh tunnel (howto found here) back to the office. The tunnel works by allowing me to ssh to a box that's not on the 192.168.x.* network, yet have all packets end up on the 192.168.x.* machine.

To start off a tunnel, you kick off a command on your local machine like:

    ssh -L 7777:destination.host.net:22  gateway.host.net  cat -

This ssh's to a gateway box and sets up a tunnel on port 7777 to the destination box.

It's a really cool technique and allow for easy defeat of a firewall (providing you have all the right credentials).

Unfortunately, various firewalls were getting in the way, and my attempt to open up ports on the gateway box failed. Besides, I didn't have the guts to tell my sysadmin that I had defeated the firewall, even if it was for wholesome purposes, like working on my vacation.

Solution #2

After a bit more thought, I realized that my problem was actually a packet routing problem. That is, I couldn't reach the right 192.168.x.* host because the routing was taking me to the wrong destination.

Windows (and Linux, but I'm on Windows here) has a route command you can use to view the routing table for packets. Turns out, this same command can be used to change the route.

I kicked off cmd.exe and entered the following command:

   # Assume VPN is started
   ipconfig
   # I noted the Default Gateway associated the PPP adapter
   route add 192.168.x.y <IP address of PPP's gateway>

The result is that I'm explicitly routing ssh requests to the box 192.68.x.y to my VPN connection, instead of letting the default routing mechanism figure it out.

The result is that my packets are routed to the right destination and my ssh command now succeeds. For better or worse, I'm good to go and can start working.

Update: Here's a cygwin shell script I wrote up which automagically sets up the proper routes according to IP addresses I have in /etc/hosts. After connecting to the VPN, I run this shell script and I'm good to go.

#!/bin/bash

##
## $Id: post-vpn-script.sh,v 1.1 2007/10/18 08:21:32 bsimon Exp $
##
## Setup the routing around the VPN
##

USAGE="`basename $0` "

VPN_IP=<IP address of your VPN goes here>

for ip in `grep 192.168 /etc/hosts | awk '{print $1}'`
do
    echo "Setting up: $ip -> $VPN_IP"
    route add $ip $VPN_IP
done

No comments:

Post a Comment