Tor offers a SOCKS5 port, usually 127.0.0.1:9050 if you're running Tor locally, or port 9100 on a nearby machine if you're splitting gateway and workstation duties. I've found SOCKS5 support in Firefox to be sketchy, so I often configure the Polipo HTTP proxy at port 8123, and have it use SOCKS5 as an upstream proxy. Many applications offer the capability to use a proxy in their configuration and command line tools can be wrapped with torsocks to achieve the same goal.
I2P maps individual local ports to services at remote locations, so it is similar in spirit to Tor. Both of these anonymizing networks offer application level proxies, which means that the system providing them is not required to NAT traffic from local subnets. These systems fail closed because they are incapable of forwarding traffic.
Creating a fail closed configuration with a VPN requires mucking around with firewall and/or route table configurations. There are several ways you can create a fail closed VPN solution, but these are the methods I am using for the moment.
When your workstation boots it probably gets it's IP address, DNS servers, and a default route from a local router via DHCP, the dynamic host configuration protocol. This configuration presumes you want to reach the whole world. Here is what this looks like in a VirtualBox VM, preceded by the command used to inspect the routing table. The 10.0.2.0/24 network is the default for VirtualBox network type NAT, the 0.0.0.0/0 entry is the default route.
netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.0.2.2 0.0.0.0 UG 0 0 0 eth0
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
When you activate an OpenVPN tunnel the system enters a host route to the VPN server you are using, and then adds 0.0.0.0/1 and 128.0.0.0/1 to the route table. This divides the 32 bit global Ipv4 address space into two 31 bit blocks, which disables the default route. Ipv4 packets are sent using the most specific route for their destination.
Netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.55.0.1 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 10.0.2.2 0.0.0.0 UG 0 0 0 eth0
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.55.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0
128.0.0.0 10.55.0.1 128.0.0.0 UG 0 0 0 tun0
212.129.10.40 10.0.2.2 255.255.255.255 UGH 0 0 0 eth0
The 212.129.10.40/32 route is the VPN concentrator in use, in this case the Cryptofree service. The 10.0.2.0/24 route is the default NAT network for VirtualBox, the 10.55.0.0/16 network is the link from this machine to Cryptostorm, then the 0.0.0.0/1 & 128.0.0.0/1 routes via 10.55.0.1 ensure nothing uses the default route via 10.0.2.2 – easy enough, right?
If you want the system to fail closed you would need to delete the default route and add a static host route to the VPN concentrator. The routing table prior to the VPN launch would look like this:
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
212.129.10.40 10.0.2.2 255.255.255.255 UGH 0 0 0 eth0
And once the VPN is started it would look like this
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.55.0.1 128.0.0.0 UG 0 0 0 tun0
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.55.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0
128.0.0.0 10.55.0.1 128.0.0.0 UG 0 0 0 tun0
212.129.10.40 10.0.2.2 255.255.255.255 UGH 0 0 0 eth0
If the VPN connection stumbles the two /1 routes it offers would be withdrawn, and the system would be disconnected. This part is easy enough to understand, but there are two pitfalls you must avoid.
The static route to 212.129.10.40 is great, but the Cryptostorm config files use the symbolic name linux-cryptofree.cryptostorm.net. Your system probably has an /etc/resolv.conf file with the IP addresses of a couple of DNS servers in there. You could add a pair of static host routes to your DNS servers, but since we're in lockdown mode it's probably safer to add this to /etc/hosts
212.129.10.40 linux-cryptofree.cryptostorm.net
212.129.10.40 linux-cryptofree.cryptostorm.org
212.129.10.40 linux-cryptofree.cryptokens.ca
212.129.10.40 linux-cryptofree.cstorm.pw
212.129.10.40 linux-cryptofree.cryptostorm.nu
The other issue you have to deal with is DHCP lease renewal. If your system is configured with DHCP, then you add the statements to create your fail closed config to /etc/rc.local, the minute your DHCP lease is up the system will renew, your default route is back, and you are exposed. As above with the DNS versus /etc/hosts config, it is safer to make your IP configuration static.
It has long been said that “Eternal vigilance is the price of liberty”, and this has never been more true than when we face a surveillance dragnet recording our every move.
