HE IPv6 tunnel in a RoadWarrior setup

[crichtma]

Ok, so I've gotten tunnels working on my server with a static IP, my DD-WRT box on my cable modem (go web API!)...now I have a slightly harder problem.

I have a small netbook which I take with me when I travel. Using IPv6 has been a great way to keep connected to my boxen all over the place. However, the snag is that setting up a static tunnel with HE can be a PITA, depending on what's in front of me. The PPTP VPN is a great service, but I don't want all my traffic going across the VPN, just my IPv6 traffic...and I haven't figured out how to work around that yet.

Does anyone have any practical experience on how to use a HE tunnel in a RoadWarrior setup where what's in front of you network-wise may not be the most optimal setup?

[jimb]

What you're basically trying to do is "split tunneling".  The problem is that both the PPTP server and the HE 6in4 server have the same IPv4 address.

When you establish the PPTP session, windows puts a route into the routing table pointing the PPTP server through the normal default route.  But somehow, when one sources a 6in4 tunnel from the PPTP IPv4, it magically ignores this route and sends the traffic through the PPTP tunnel.  However, this only works when the "use default gateway on remote network" box is checked (which is the default).  This means that it's a sort of "all or nothing" thing.  If you have the box checked, all internet traffic will go through PPTP.  (Interestingly, this "magic routing" behavior only seems to happen with the tunnel connections ... other things still take the "normal" default route to the HE server and ignore the PPTP connection, even when sourced from the PPTP interface IPv4).

When you establish a PPTP connection with the "use default route" box unchecked, this "magic" routing behavior changes, and traffic to the PPTP/6in4 server tries to take the normal default route, even when sourced from the PPTP IPv4 address (I tried this using "pathping -i <IPv4 of PPTP interface> <HE server>").  In fact, I couldn't get any traffic to go to the internet through the PPTP connection with this box unchecked, even when sourced from the PPTP IP, unless I added a static route for this destination through the PPTP connection (like this: route add <some IPv4> mask 255.255.255.255 <my PPTP IPv4 address>).  Unfortunately, as I mentioned before, there's already a route for the PPTP server added to the routing table by Windows which directs PPTP traffic through the normal internet path.  Adding a route for this and trying to point it through the PPTP NIC breaks the PPTP connection, as one might expect.

If HE would change the IPv4 addresses of the PPTP servers (or add additional ones) so they're not the same as the 6in4 tunnel servers' IPv4, then the "add a static route" method I talk about above could actually work and you could do a split tunnel with normal IPv4 traffic taking the direct route, and only 6in4 traffic taking the PPTP route.  You'd simply uncheck the "use default route" button, establish the PPTP connection, add a static route for the HE TB server through the PPTP, and establish the 6in4 tunnel.

One thing I haven't tried is leaving the box checked, then manually overriding the new default route by changing its metric to one higher than the PPTP default route metric, or simply deleting the PPTP default route.  It might be possible that doing this would allow normal traffic to go through the normal default route, while keeping the "tunnel routing magic" working.  You may want to give this a try.

EDIT:  Another thing which may be possible is by using some sort of policy routing like one has to do under linux to get this to work.  However, I have no idea whether Windows supports policy routing, or how one configures it if it does.  :P

[patrickdk]

Well, instead of playing with default routes, you could get really lazy and just add two new routes, 0.0.0.0/1 and 128.0.0.0/1 to your ipv4 gw

[jimb]

That'd also be something to try if mucking with metrics or default routes didn't work.  It should use those since they'd be longer prefix matches.

But really all those things are dependent on the behavior of windows and could still result in the "magic" routing being deactivated.