The routing project

Tags: networking, computers, Windows.
By lucb1e on 2013-07-01 01:55:34 +0100

I've worked at this project for a couple months, every few weeks spending a couple hours testing some new idea. It was at internship and I only finished it by coincidence a few days before I also finished internship (and I graduated, yay!).

The challenge was to setup internet on my laptop. Sounds simple enough, right? Let's see how complicated we can make this :)

I had one company-issued Windows computer with no administrator privileges. I could look at the IP configuration, but that was about it. I had a rooted Android phone and a USB connector to the computer. My laptop was my own and ran Linux. There is one network cable leading to an IP phone, which acts as a repeater (better known as a hub, whose fancy name is a multiport repeater) and in turn provides network access.

Internet connectivity was actually in another location to which we had a fiber connection. Let's say the other location was Amsterdam (not the actual location). Each physical office had its own network connecting there to a proxy providing moderated internet access.

Here's a diagram:


Hooking just my laptop up to the IP phone was easy enough, and after setting some proxy settings I could use most things on the web (except some programs incompatible with authenticated proxies). But what about my computer? I got a virtual desktop on a server in Amsterdam with my development environment; I couldn't get any work done without network connectivity on my computer. It would also be nice if the computer could exchange files with my laptop since I had no Microsoft Visio on the computer (could have requested it, but it's such a pain when you have the program right here on your laptop).

I solved the latter problem by using my phone. Connect the USB cable, enable USB tethering in the settings, enable the mobile WiFi hotspot, connect your laptop, and off you go!

Yeah, offline you go damnit. The computer changed the default route to my phone, which was incorrect. My phone didn't provide internet, the IP phone does! Dropping the new configuration was not allowed, but I could disconnect my phone, kill dhcpd, reconnect it, and it used an APIPA address with no other routes! That meant a 169.254.x.x on my computer... but my phone was still assuming a 192.168.42.129 IP address. Neither had any clue the other existed.

This was solved easy enough by entering these commands on my phone:
export usbconnector=rndis0
ip addr add 169.254.1.1 dev $usbconnector
ip route add 169.254.0.0/16 dev $usbconnector

There you go! Connectivity between my phone and computer, that's a small step for man. Now onto my laptop... that didn't really work out. The computer only had a route to the APIPA IP range while my laptop was in another subnet. I'm not sure why I didn't try, but acting like there is nothing in between two physically separated networks doesn't seem like a good idea.

Fortunately it turns out Windows keeps any existing connections regardless of route changes. You need to change your ARP table if you want to change physical connections on the fly (this surprisingly won't disrupt SMB file transfers!), but that's another topic which is irrelevant here.

Because of this connection-keeping, the remote desktop connection would be maintained (even though I lost other internet connectivity on my computer) and I could access files on my laptop... Or not. No, as I mentioned before, my phone has two different subnets for the USB tethering and the WiFi hotspot, 192.168.42.0/24 and 192.168.43.0/24. But we can solve that now that the computer uses the correct route towards the 192.168.43.0/24 network!

iptables -A FORWARD -i wlan0 -o rndis0 -j ACCEPT
iptables -A FORWARD -i rndis0 -o wlan0 -j ACCEPT

Lo and behold, it worked!

Only how do I get to internet from here? I can't use Windows' ICS (Internet Connection Sharing) service because I had no administrator permissions on the computer that is attached to the IP phone. This turned out to be a dead end.

In the end, I connected the cable from the IP phone to my laptop anyway. My laptop had internet that way, connected wirelessly to my phone, and finally my phone connected to the computer. Because I can't seem to edit the dhcpd configuration on my phone it still had to act as switch instead of making it one contiguous subnet. The computer set the default route to my phone, so I had to configure my phone to route things further (the ip forwarding itself was already configured with iptables above):

export laptopconnection=wlan0
ip route add 0/0 dev $laptopconnection

And use this on my laptop to move the traffic along:

export $phone=wlan0
export $ipphone=eth0
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -i $phone -o $ipphone -j ACCEPT
iptables -A FORWARD -i $ipphone -o $phone -j ACCEPT

That should do the trick... Except it didn't. What on earth was wrong, every route is setup correctly! The route to my virtual desktop as seen from the computer so far:
- 192.168.42.127 (computer usb)
- 192.168.42.129 (phone usb)
- 192.168.43.1 (phone wifi)
- 192.168.43.228 (laptop wifi)
- 192.168.7.109 (laptop wired connection)
- IP phone acts as repeater and doesn't actually do any IP routing.
- * * *

I hate those three asterisks: timeout; no response; dead end.

A few minutes later it occurred to me that, although I had done everything correctly in my own network, the routers in Amsterdam had no clue who or where the hell 192.168.42.127 could be! The packets were being marked as coming form my computer, but the only route they had was to my laptop (192.168.7.109).

Hmm, so if packets can only be sent back to my laptop but they need to reach the computer, what do we do... Network Address Translation!

iptables -t nat -A POSTROUTING -o $phone -j MASQUERADE
iptables -A FORWARD -i $phone -o $ipphone -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $ipphone -o $phone -j ACCEPT

Then I tried the traceroute to my virtual workspace again:
- 192.168.42.127 (computer usb)
- 192.168.42.129 (phone usb)
- 192.168.43.1 (phone wifi)
- 192.168.43.228 (laptop wifi)
- 192.168.7.109 (laptop wired connection)
- IP phone acts as repeater and doesn't actually do any IP routing.
- 192.168.7.254 (Amsterdam router)
- 192.168.54.1 (another Amsterdam router)
- 192.168.54.194 (my virtual desktop)



The chain is complete!

So basically this is what happened when I sent a ping to my IP phone's IP address from my computer:
- 192.168.42.127 (computer usb, local)
- 192.168.42.129 (phone usb, local)
- 192.168.43.1 (phone wifi, local)
- 192.168.43.228 (laptop wifi, local)
- 192.168.7.109 (laptop wired connection, local)
- IP phone acts as repeater and doesn't actually do any IP routing (local).
- 192.168.7.254 (router in Amsterdam)
- 172.16.7.253 (router in Amsterdam)
- 172.16.7.119 (IP phone, local)
- 172.16.7.253 (router in Amsterdam)
- 192.168.7.254 (router in Amsterdam)
- IP phone acts as repeater and doesn't actually do any IP routing (local).
- 192.168.7.109 (laptop wired connection, local)
- 192.168.43.228 (laptop wifi)
- 192.168.43.1 (phone wifi)
- 192.168.42.129 (phone usb)
- 192.168.42.127 (computer usb)

All of that in a quarter of a tenth of a second. An impressive display of how quick telecommuncation has become and Android's power to serve in this all as a fully functioning router. (As I said before, to call my phone a phone is practically an insult.)

And, if I do say so myself, I was quite proud of the whole chain. After five months I finally got all systems hooked up together, correctly setup routing and NAT (topics that school oddly never covered in their networking classes), and had functioning connections on all devices I wanted.

Then it was time to break it all down again and prepare for departure :P

Fun fact: WiFi would be setup later that year, which would have made my effort wasted. It would actually have been in the air already ifnot for the fact that I cracked it during the beta period. The sysadmin noticed I was online and irritatedly called me, asking what I was doing on a network to which I could not have access. (Unfortunately I can't disclose my methods for obtaining access.) Meanwhile I already mentioned it to the security person in charge and he permitted it so I couldn't be blamed :)

Fun fact 2: Master Yoda (see diagram) in Amsterdam failed once, causing an entire afternoon of outage for everyone in all locations throughout the country. Yeah there was a backup switch but it didn't work... Lesson: best way to protect against outages is to cause them. Just yank out a core switch during office hours and see whether the other one takes over. You better make sure it does!