Re-tunneling via OpenVPN: Part success, part problem

[nholland]

Dear folks,

I fear I have a small problem with my IPv6 tunnel setup and I hope that some knowledgable soul in here might be able to point me in the right direction. As there are solely Windows machines involved, I might also have posted this in the "Windows" section. On the other hand, I believe that the problem described above is absolutely not OS-specific, but rather an error on my part. So pardon me for posting in this section if you believe that to be inappropriate. 

First, let me describe my situation:

I have a HE.net tunnel with the following details:

HE.net IPv4 endpoint: 216.66.80.26
HE.net IPv6 endpoint: 2001:470:1f08:646::1
My IPv6 endpoint: 2001:470:1f08:646::2
My routed /64: 2001:470:1f09:646::

I have set up this tunnel on a virtual private Windows 2008 server system I operate at a host in London (IPv4 and IPv6 forwarding are turned on in the "Routing & RAS" configuration). That was kind of simple and worked like this:

netsh interface ipv6 add v6v4tunnel IP6Tunnel <my_vps_public_IPv4_address> 216.66.80.26
netsh interface ipv6 add address IP6Tunnel 2001:470:1f08:646::2
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:470:1f08:646::1

Works just fine: On my VPS, I now have IPv6 connectivity, that is various "What is my IPv6 address" website properly report back my IPv6 address of 2001:470:1f08:646::2, I can see the dancing turtle, I can do IPv6 traceroutes, etc. So far, so good.

Now, another idea struck me: I wanted to put my routed /64 to good use. So I had the following idea: I have OpenVPN (in tun mode) running on the above mentioned VPS, which I use for VPN connections from my home machines. My idea was to set up another v6v4tunnel over the OpenVPN connection, so that my home clients could get IPv6 addresses and connectivity from my routed /64 whenever I'm connected to my VPS via OpenVPN. That way, I wouldn't have to set up a direct HE.net tunnel to my home, which might be a problem because of my NAT router.

Sounds easy, so I tried it first with my main home machine running Windows 7. The situation is that OpenVPN's virtual tun interface on the server has the IPv4 10.8.0.1, and my home machine gets assigned the IPv4 10.8.0.6 every time it connects to the server via OpenVPN.

So here's what I did on the server:

netsh interface ipv6 add v6v4tunnel IP6TunnelC1 10.8.0.1 10.8.0.6
netsh interface ipv6 add address IP6TunnelC1 2001:470:1f09:646::1

And here's what I did on the client:

netsh interface ipv6 add v6v4tunnel IP6Tunnel 10.8.0.6 10.8.0.1
netsh interface ipv6 add address IP6Tunnel 2001:470:1f09:646::2
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:470:1f09:646::1

That works perfectly fine, actually! Whenever my home machine is connected to my VPS via OpenVPN, it gets IPv6 connectivity. The "What's my IPv6 address" sites properly state that my home machine's IPv6 is 2001:470:1f09:646::2, I can also see the dancing turtle as well as do IPv6 traceroutes.

Now, I thought, this should be repeatable for setting up another home machine, namely my girlfriend's machine, also running Windows 7. My girlfriend's machine gets assigned the IPv4 of 10.8.0.10 whenever it connects to my VPS via OpenVPN, so I did this:

On the server:

So here's what I did on the server:

netsh interface ipv6 add v6v4tunnel IP6TunnelC2 10.8.0.1 10.8.0.10
netsh interface ipv6 add address IP6TunnelC2 2001:470:1f09:646::3

And here's what I did on the client:

netsh interface ipv6 add v6v4tunnel IP6Tunnel 10.8.0.10 10.8.0.1
netsh interface ipv6 add address IP6Tunnel 2001:470:1f09:646::4
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:470:1f09:646::3

And, well, it doesn't work. I don't get any IPv6 connectivity at all on that machine. Of course, that suggests that I've done something wrong.

I actually suspect that my error can be found by the way the tunnels for my home machines are defined. Let's have another look at the server parts of both of these:

Server part for client 1:

netsh interface ipv6 add v6v4tunnel IP6TunnelC1 10.8.0.1 10.8.0.6
netsh interface ipv6 add address IP6TunnelC1 2001:470:1f09:646::1

Server part for client 2:

netsh interface ipv6 add v6v4tunnel IP6TunnelC2 10.8.0.1 10.8.0.10
netsh interface ipv6 add address IP6TunnelC2 2001:470:1f09:646::3

You see, in both cases I'm using the IPv4 address of 10.8.0.1 for the tunnel, yet I use a *different* IPv6 for both cases (2001:470:1f09:646::1 and 2001:470:1f09:646::3, respectively). Can this be right? Probably a IPv4 address can be used only once as an address for a tunnel endpoint, so that for the second instance I'd have to assign a new IPv4 address to my OpenVPN tun adapter, like 10.8.0.<whatever> and then do

netsh interface ipv6 add v6v4tunnel IP6TunnelC2 10.8.0.<whatever> 10.8.0.10
netsh interface ipv6 add address IP6TunnelC2 2001:470:1f09:646::3

instead of re-using the 10.8.0.1? Or is it actually wrong that I'm using two new IPv6 addresses as the endpoints for my second tunnel?

I'd be glad and thankful if someone had some advice to offer, thus making my impending troubleshooting session a little less "trial & error".

Thank you all in advance and kind greetings,
Nils

[nholland]

Hi folks,

replying to myself here, I can report that I tried for hours last night to get things working, but somehow they wouldn't. I still don't totally get get it: When I create my tunnel between my "server" and my second client, assigning tunnel inferace on the server an IPv6 address of 2001:470:1f09:646::3 and the second client an IPv6 address of 2001:470:1f09:646::4, I cannot even seem to ping 2001:470:1f09:646::3. Hmm.

In the meantime, I've found someone who has done something similiar, except that he doesn't get his "initial" IPv6 connectivity by means of a HE.net tunnel, but instead directly from his hosting provider. His nice write up on how to do things with OpenVPN can be found here. What he actually does is that he has a /48 and assigns a /64 to each of his clients connecting via OpenVPN. I could also request a /48 from HE.net, but what I'm actually trying to do and what I think should be possible is to assign one address out of my routed /64 to each of my OpenVPN clients.

Unless somebody happens to have a helpful suggestion, I fear it might be come more trial & error for me tonight. There is, for example, supposed to be a way to enable the virtual OpenVPN tun adapter to carry IPv6 traffic, thus making it unnecessary to add additional "v4v6tunnels" for each client. That might be another thing worth trying, even though if that worked, I would still be clueless as for why my original intended way of doing things doesn't seem to work properly for more than one client.

[jimb]

What you're trying to do is put the same IPv6 /64 on two different interfaces.  Also, as you said, you're putting the same IPv4 on two different interfaces.  I've seen VPN concentrators do this sort of thing, but it's likely a special case implementation detail in the device's OS which handles cases like that.

You should make sure that your IPv4 IPSEC connections work simultaneously first.  Once you verify that, then you can set up your 6in4 tunnels using the IPSEC virtual NIC (TUN) IPv4 addresses as the local and remote endpoints for the 6in4 tunnel.  Then you must set IPv6 addresses on your 6in4 tunnel interfaces which are on different subnets, otherwise there will be routing confusion.  To do this, you need to either get a routed /48 and use separate /64s for each, or break your routed /64 down into smaller subnets such as /126s (this latter is generally frowned upon though).  If you do something like this, I don't see why it wouldn't work.  

Another option you might want to check into is if OpenVPN supports any sort of IPv6 over IPv4 IPSEC natively.  Maybe it has IPv4 GRE in IPSEC tunnels, which should be able to carry IPv6.  Or even 6in4 in IPSEC tunnels implemented in OpenVPN.  It might be cleaner/easier than using the MS built in 6in4 tunnels via an OpenVPN IPSEC tunnel.

[nholland]

Hi jimb,

wow, you made my day! After two nights of struggling, you finally pushed me in the right direction and I have gotten my stuff to work now.

I simply requested my rounted /48 and am now assining individual /64s out of that one to my OpenVPN IPv4 clients by means of v6v4tunnels. In other words, I have the following:

OpenVPN server tun interface: 10.8.0.1 (no IPv6 address assigned here)

Clients connecting via OpenVPN get 10.8.0.2, 10.8.0.3, etc.

Tunnel endpoints on the server:

netsh interface ipv6 add v6v4tunnel IP6Tunnel1 10.8.0.1 10.8.0.2
netsh interface ipv6 add address IP6Tunnel1 2001:470:9102::1

netsh interface ipv6 add v6v4tunnel IP6Tunnel2 10.8.0.1 10.8.0.3
netsh interface ipv6 add address IP6Tunnel2 2001:470:9102:1::1
...

Tunnel endpoints on the clients:

netsh interface ipv6 add v6v4tunnel IP6Tunnel 10.8.0.2 10.8.0.1
netsh interface ipv6 add address IP6Tunnel 2001:470:9102::2
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:470:9102::1

netsh interface ipv6 add v6v4tunnel IP6Tunnel 10.8.0.3 10.8.0.1
netsh interface ipv6 add address IP6Tunnel 2001:470:9102:1::2
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:470:9102:1::1
...

And that works exactly as expected! With some inofficial patches (described here) I would probably have been able to get by without the v6v4tunnels between the OpenVPN server and clients (quote: "The patch set below adds support for transporting IPv6 payload in point-to-multipoint (P2MP) TUN server mode. That is, you run a single OpenVPN instance on the VPN server side, and multiple clients connect to it. Every client is assigned a single IPv6 address by the server, coming from a shared transfer network between all clients and the server. Usually this would be a common /64, but theoretically a smaller subnet could also be used (not implemented yet)"), but I'm actually kind of happy with my current setup already.

Thanks again!

Greetings,
Nils

[jimb]

I figure you'd get it working once you got the IPv6 subnetting worked out.  I just wasn't sure about the OpenVPN side.

I've never used OpenVPN before, so wasn't sure how it implemented a remote access client VPN scenario.  Wasn't sure if it supported having the same local IP for multiple VPN clients (as is typical for commercial remote access VPN appliances).  It appears it does.  

I imagine it just sets something like 10.8.0.0/24 or /16 on the TUN interface, then on the OpenVPN side which is hooked into the TUN NIC it implements the IPSEC SAs as /32s (i.e. 10.8.0.1/32 -> 10.8.0.2/32 and the reverse).  So the OS just sees the whole 10.8/x net as being reachable through the TUN NIC, and stuff like 6in4 can be used through it.

That's gotta be some overhead though!  6in4 via an IPv4 IPSEC ESP tunnel, possibly with UDP encapsulation for NAT traversal:  [IPv4:UDP:IPSEC ESP:IPv4 6in4:IPv6:UDP|TCP|ICMP:data]

Quite a chain of headers to unwrap.    What's your PMTU work out to be?  

[nholland]

Hi jimb,

yes, there certainly is quite some overhead involved, but I can say that in pratice, it works absolutely fine!

Concerining PMTU: Any idea how I can determine that (in Windows)? What I've tried is using "ping" to send a huge packet via IPv6 to www.kame.net while watching the situation with Wireshark. And as it turns out, my machine seems to be sending out packets with a payload length of 1240 bytes (which would be 1280 bytes with an IPv6 header, I guess):



I wonder if this tells me anything, though. Does it mean my Path-MTU is 1280, or would this be an invalid conclusion from what I've seen above? With IPv4, I'd just ping some far-away host with the "DF" flag set and play around with the packet size until the packet gets through, but I'm wondering what the proper way of doing things would look like with IPv6. My "-f" flag to "ping" certainly is of no use anymore.

EDIT: I just realized that the screenshot I posted actually doesn't show a packet I send, but instead a reply I receive. Doesn't make any difference from the values involved, though...

Greetings,
Nils

[jimb]

"netsh int ipv6 show destin" shows PMTU in the left column.  Pretty neat actually.

netsh int ipv6 show destinat

Interface 4: Wireless Network Connection

PMTU Destination Address                           Next Hop Address
---- --------------------------------------------- --------------------------
1280 2001:470:0:63::2                              fe80::250:daff:fe53:6564                    
1280 2001:608:0:1007:a00:20ff:fefe:4bd2            fe80::250:daff:fe53:6564                    
1280 2001:200:0:8002:203:47ff:fea5:3085            fe80::250:daff:fe53:6564                    

[nholland]

Looks like this for me (running a German version of Windows here):

Code:

Schnittstelle 21: IP6Tunnel

PMTU Zieladresse                           Adresse des n. Hops
---- --------------------------------------------- -------------------------
1280 2001:470:0:63::2                              2001:470:1f09:646::1

2001:470:0:63::2 is actually tunnelbroker.net, I guess.