Solved! Thanks to eibgrad at the DD-WRT forums. Here is his answer:
(Source: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=277001 )
It's just a clever hack/trick.
There’s actually TWO important extra routes the VPN adds:
128.0.0.0/128.0.0.0 (covers 0.0.0.0 thru 127.255.255.255)
0.0.0.0/128.0.0.0 (covers 128.0.0.0 thru 255.255.255.255)
The reason this works is because when it comes to routing, a more specific route is always preferred over a more general route. And 0.0.0.0/0.0.0.0 (the default gateway) is as general as it gets. But if we insert the above two routes, the fact they are more specific means one of them will always be chosen before 0.0.0.0/0.0.0.0 since those two routes still cover the entire IP spectrum (0.0.0.0 thru 255.255.255.255).
VPNs do this to avoid messing w/ existing routes. They don’t need to delete anything that was already there, or even examine the routing table. They just add their own routes when the VPN comes up, and remove them when the VPN is shutdown. Simple.
Nice, and difficult, question.
First, a general principle: in routing tables, if you have several rules which apply to the same destination, the most specific one is used. For instance, looking at your second RT, suppose you want to ping Google DNS 8.8.8.8. Both the first line and the second line apply, but the first line is slightly more specific because it has a more restrictive netmask than the second one: the first line applies to all IP addresses in the range
0.0.0.0 -> 127.255.255.255
while the second rule applies to all IP addresses full stop, i.e. those in the range
0.0.0.0 -> 255.255.255.255
Hence the first rule, which is narrower/more restrictive/more specific, is used: pinging 8.8.8.8 will have to go thru dev tun0 and thru IP address 10.172.1.5.
Second point: your 2nd RT contains two unicast routes: they are those indicated by an H in the fourth column. The presence of unicast routes is clearer if you use, instead of the obsolete command route/netstat, the new command:
$ ip route show
(which you should always do) because here unicast routes are indicated by the expression scope link.
This is the key to understanding (Open)VPN routing. The manual states:
scope SCOPE_VAL
the scope of the destinations covered by the route prefix. SCOPE_VAL may be a number or a string from the file /etc/iproute2/rt_scopes. If this parameter is omitted, ip assumes scope global for all gatewayed unicast routes, scope link for direct unicast and broadcast routes and scope host for local routes.
What is a unicast route?
A static unicast route is a manually configured mapping of an IP address to a next-hop destination, hence called a destination specific route...
Add static routes when you want to route traffic destined for specific network/host via a different next hop instead of the default route.
In other words: if this rule did not exist, then, since pinging 8.8.8.8 goes thru 10.172.1.5 (in your case) but there is no default gateway on tun0, the packet would be transferred to the eth0 interfce, where there is a default gateway, and would go out of this. But this is what happens normally, and you would not have an (Open)VPN. Instead, there is a unicast rule, and it is as restrictive as it can be: it forces you, no matter whom the packet is addressed to, to contact 10.172.1.1 as the next hop.
Fine, what now: how do we contact 10.172.1.1? dev tun0 has no such rule, hence the packet is transferred to eth0, in the hope of better luck. Now, which of the remaining rules can we apply to forward our ping packet? The fact is, eth0 also has a unicast route,
168.1.6.15 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
which forces it to send the packet, as its next hop, to 168.1.6.15. And, from then on, it is not our responsibility any longer.
We can summarize this logical process as follows:
Packet to 8.8.8.8 ---> dev tun0 ---> 10.172.1.5 ---> 168.1.6.15
(Rule #1)
(Rule #3)
(Rule #6)
Loose ends:
One of the remaining rules, Rule #5
128.0.0.0 10.172.1.5 128.0.0.0 UG 0 0 0 tun0
complements Rule #1
0.0.0.0 10.172.1.5 128.0.0.0 UG 0 0 0 tun0
The two together provide default rules to all IP addresses in the world, but since each of them is slightly more restrictive than Rule #2
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
they take precedence over it, and are used to route all of your internet traffic thru the OpenVPN. In fact, the rule above is redundant, and it wad deleted in older version of OpenVPN. But it is now left in place because it is basically never invoked, and it makes re-instating the RT#1 easier, when the OpenVPN is torn down.
Rule #7 is the usual local LAN rule. You are missing a rule like
10.172.1.0/24 dev tun0 proto kernel scope link src 10.172.1.5
which is what would be necessary for you to contact pcs in the remote LAN. Most likely, this is due to the fact that you are using as an OpenVPN server a per-pay service, which has no intention of allowing you access to the other local machines. If instead this OpenVPN were the one thru which you connect to your home LAN whe on the road (for instance), then you would definitely wish to have the ability to contact the other pcs on your LAN, and you would have one such rule.
Lastly, the Rule #4
10.172.1.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
is completely mysterious to me: I do not have it on any of my (numerous) OpenVPNs, and, as far as I understand it, it seems to me totally redundant.
Best Answer
Yes, the first step is to identify the IP addresses you want to route - the actual routing is fairly straightforward.
When you are connected to the VPN and do
It will show a default route, something like:
The IP address of the gateway and interface will be provided by your VPN provider at connection time.
The 0.0.0.0 destination and 0.0.0.0 netmask means "match all traffic to this route, and send it to the gateway"
You want to delete this, and replace it with a default route that is out of your internet connection. Like this (assuming 10.1.1.1 was your own router):
Now all traffic will go out of your router, and none through the VPN.
Then you figure out the hulu network range - lets say it is
200.200.200.0/24, and add a route for it:So what this is saying is, any traffic destined for any address in the range 200.200.200.0-255 should be sent to the VPN gateway.
Determining the hulu range might be difficult to deduce, but you could do some googling as you won't be the first to try and figure out what ranges they use. Failing that, you could install wireshark and observe what traffic flows through the VPN when accessing hulu (you'll want to make sure you don't run anything else at the same time).