Who ordered the scrambled brains?

If you’re anything like me, you’re an idiot who lost your jailbreak today when you tried to upgrade from iOS 6.0 to iOS 6.1.2 (which supports an untethered jailbreak) but were forced to upgrade to iOS 6.1.3 since Apple’s servers already closed the signing window for iOS 6.1.2 installs. [Shakes fist in direction of Cupertino.] And that means you lost the ability to use GuizmoVPN to access your startup’s access-restricted development server.

In the past, I’d tried using OpenVPN Connect, the Apple-sanctioned OpenVPN client app, but it required the use of a so-called “tun” adapter. Tun operates at OSI level 2, as opposed to Level 1 which GuizmoVPN supports via the tap adapter. Of course the beauty of tap is that it can be bridged to your VPN servers LAN interface, meaning no mucking around with subnets and routes.

Anyway… today I was forced to get tun working. You could say I was in for a “tun” of fun! Digression. I needed to progress through a series of puzzles, riddles and enigmas, each more beguiling than the last, carefully designed to test a different skill and/or bit of administrivia, before I gained the power of tun.

Stage 1: The Wall of Fire

First, I had to open/forward a port on my private networks WAN gateway, and also on the local firewall of the VPN server itself (God bless ufw!), since I wanted to retain the operation of the existing tap-based OpenVPN server. Kids stuff.

Stage 2: The Tunnels

Next came OpenVPN configuration. The routing wasn’t as bad as I thought, but the general notion of having a separate subnet for the tunnel just felt wrong next to the simplicity of bridging. OK, say the private network uses 192.168.1.0/24, and I chose 192.168.2.0/24 as the tunnel subnet. Also, the OpenVPN server itself has a local IP of 192.168.1.2, and the private WAN gateway is at 192.168.1.1. This was my server OpenVPN conf.

port 13337
dev tun
mode server
tls-server
server 192.168.2.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
push "redirect-gateway"
# TLS encryption stuff.
# Other (non-germane) stuff.

I could’ve placed the `push` settings on the client configuration but I prefer to manage it centrally. This works for both OpenVPN Connect on iOS as well as the Windows OpenVPN client. Flipping/flicking the switch in OpenVPN Connect resulted in a rewarding green checkmark. I’ll take it!

Mini-game 1: Pong

With that up and running, I tried a little `ping`. I could ping across the tunnel from the client to the VPN server, but not out to hosts on the private network. I thought all it would require was a simple:

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -A FORWARD -i tun+ -j ACCEPT

However, I thought wrong, and pinging into the private network still failed. Oi! A couple head-smash-upon-keyboards later, I read that they need a route back to the pinging clients, since they live on separate subnets. Of course, it’s like playing tennis across parallel universes. Just like that. Luckily, all hosts on the private network are configured, by DHCP, to use the WAN gateway by default, so all I needed to do was add a static route on the gateway to 192.168.2.0/24 over 192.168.1.2. (Shout out to Tomato firmware, “Awww yeah!”) With that, pings were routed back to the originating client successfully. Game. Set. Match.

(You want to configure the IP forwarding to survive reboots. On Ubuntu, this is done in /etc/sysctl.conf.)

Mini-game 2: Dig-Dug

I’ve got dnsmasq running on the private network as well, which is a crucial piece of infrastructure when it comes to hostname-based web hosting. So once I confirmed pinging to hosts on the private subnet, I tried a quick `dig development-site`, but to no avail. Even worse `dig @192.168.1.1 development-site` was silent as well. So I set about getting DNS queries to go to the remote network. First piece of the puzzle was to inform the clients of the private DNS server. Adding

push "dhcp-option DNS 192.168.1.1"

to the OpenVPN config should’ve done the trick. But it didn’t. Fortunately, I had just recently been futzing around with my dnsmasq configuration, and I recalled that it could be configured to respond only to requests coming from certain interfaces. Peeking into the configuration revealed that it was indeed constrained to respond only to the LAN interface. A quick configuration change to loosen that up, and I was digging up my tunnel like nobody’s business!

Boss Stage: The Spider’s Nest

Finally I it was time to try `wget development-site`, but (altogether now) to no avail! “WAAHHH! But, but, but… I did the thing with the routes and the tunnels, blasting the hole in the firewall, the digging and the ping-ponging across parallel universes… alas, must I turn back, again?” I couldn’t let it go this time. But my dev site had alwaysbeen accessible in the past with tap OpenVPN, what gives?!

Suddenly, Alec Guiness’ voice boomed in my ear, “USE THE LOGS, LUKE! I MEAN, USE THE FORCE, MIKE. ER, USE THE MIKE, LOGS? UH, HEHE, YOU GET IT, RIGHT?” Looking at the logs, it turned out the requests were rejected because they were coming from IPs on the VPN subnet, not the private subnet! Of course. Even though tap gave VPN clients IP addresses on the private subnet, tun gave them addresses on the special tunnel subnet. Since Apache was configured with `Access 192.168.1`, requests from the tunnel subnet were rejected. A quick one-two punch to the Apache configuration (by the way, Access arguments are space-delimited, not comma-delimited), and BAM! Apache was mine!

Crossing my fingers, toes, and eyes, I flicked OpenVPN Connect to the On position, and Mobile-Safari’d my way to http://development-site… And, like a divine light emanating from the face of God himself, my development website graced my eyeballs. [Cue end theme.]

I hope this helped you out, dear reader/person that is “anything like me.” Also, if you’re anything like me, you’d probably like to know that neither of the Starbucks in Union Square have power outlets, but Think Coffee on 4th Av. does. Now you can access your private dev site while having fresh coffee and/or beer. You’re welcome.

Follow me on Twitter for the latest updates, and make sure to check out my community opinion social networking project, Blocvox.