Openvpn – IPv6 routing over OpenVPN

ipv6openvpnrouting

Trying to learn how IPv6 works with OpenVPN, so I wanted to setup following scheme.

I have a VPS server (Ubuntu), which have been allocated a /48 subnet.

ISP ipv6 gateway is XXXX:XXXX:XXXX::1
Server ipv6 address is XXXX:XXXX:XXXX:39::1

The idea is that any clients connecting to server gets an ip address on the XXXX:XXXX:XXXX:39:2::/64 subnet.

Server configuration file is based on the sample configuration from OpenVPN with the following additions:

dev tun
tun-ipv6
server-ipv6 XXXX:XXXX:XXXX:39:2::/64
push "route-ipv6 XXXX:XXXX:XXXX:39::/48"

Restarting OpenVPN server gave no problems.

Server is assigned following ip addresses:

eth0: XXXX:XXXX:XXXX:39::1/48
tun0: XXXX:XXXX:XXXX:39::2/64

Client is assigned:

OpenVPN tap: XXXX:XXXX:XXXX:39:2:0:1:0, and I can ping XXXX:XXXX:XXXX:39::1 just fine. However pinging ISP gateway from client makes connection time out.

I can ping ISP ipv6 gateway from server.

I have allowed traffic from XXXX:XXXX:XXXX:39:2::/64 in Ubuntu Firewall.

What am I missing?

I should mention server is running OpenVPN version 2.2.1 – is that the reason for the complaining?

Best Answer

Turns out it is was not quite so easy to use my hosted server as an IPv6 gateway. It is doable though it is a multi step process.

I ended up asking bit in here, so the following is a summary of what I have learned during the process.

To get a routable subnet I went to Hurricane Electric and got myself a routed /48 subnet from Hurricane Electric. Visit https://tunnelbroker.net for more information about how to obtain your own subnet.

They will provide a IPv6 routed over IPv4 tunnel and also tell you what you should add to you /etc/interfaces.

My IPv6 addresses on the tunnel link is on the form: 2001:470:xxxx:xxx::/64. Therefore the following lines should be added to /etc/interfaces:

auto he-ipv6
iface he-ipv6 inet6 v4tunnel
    address 2001:470:xxxx:xxx::2
    netmask 64
    endpoint <ipv4 address Tunnelbroker side> 
    local <public ipv4 address your side>
    ttl 255
    gateway 2001:470:xxxx:xxx::1

But due to my server already have a public IPv6 address, it will cause some issues that we will have to mitigate before I can ping anything from the Tunnelbroker subnet.

#Enter policy based routing.

The idea is that the server decides which outbound link it should for IPv6 traffic depending on source IPv6 address.

The rules are pretty simple.

If traffic originates from the server itself then use the default gateway.
If traffic originates from my /48 subnet then use the IPv6 over IPv4 link.

This means you need two routing tables. The default routing table (called: main) and your own table (I called mine mynet6).

First add an entry for custom routing table:

echo 100     mynet6 > /etc/iproute2/rt_tables

For agument sake lets say I am assigned the subnet 2001:db8:cafe::/48.

I made a script that is called by OpenVPN when VPN link is up, since my /48 subnet resides only on my VPN link. The script goes a bit like this:

# Reset IPv6 routing table.
ip -6 rule flush

# Add default IPv6 rules again - since they gets deleted by the initial rule 
# flush command.
ip -6 rule add priority 32766 from all table main

# Reset Tunnelbroker routing table (table name: "mynet6").
ip -6 route flush table mynet6

# All traffic from my /48 subnet should be added to Tunnelbroker routing table
ip -6 rule add priority 32000 from 2001:DB8:CAFE::/48 table mynet6

# Add routeable VPN subnets to Tunnelbroker routing table
ip -6 rule add from 2001:DB8:CAFE::/48 table he-ipv6

# Remember to add a rule that if no machine does not respond to a 
# packet address in my /48, then we should return unreachable. 
# Else the package will be forwarded by default out through the 
# Hurricane Electric connection.

#(From the Internet)
ip -6 route add unreachable 2001:DB8:CAFE::/48

#(From my /48 subnet)
ip -6 route add unreachable 2001:DB8:CAFE::/48 table mynet6

# Any traffic that originates from VPN has to be forwarded via Tunnelbroker 
# routing table using the tunnelbroker link (link name: he-ipv6).
ip -6 route add default via 2001:470:xxxx:xxx::1 dev he-ipv6 table mynet6

#Verification of configuration

You can verify your routing setup with the command:

ip -6 rule show

It should contain something like:

0:      from all lookup local
32000:  from 2001:db8:cafe::/48 lookup mynet6
32766:  from all lookup main

The routing table for Tunnelbroker link can be found with:

ip -6 route show table mynet6

And it should output something like:

unreachable 2001:db8:cafe::/48 dev lo  metric 1024  error -113 pref medium
default via 2001:470:xxxx:xxx::1 dev he-ipv6  metric 1024  pref medium

You default routing table is found here:

ip -6 route show table main

And it should have among others the lines:

unreachable 2001:db8:cafe::/48 dev lo  metric 1024  error -113 pref medium
default via XXXX:XXXX:XXXX::1 dev eth0  metric 1024  pref medium

That should take of what the server have todo when it recieve traffic from the /48 subnet. How you assign the /48 subnet your to own network is an entire different chapter, that I am not going cover here. :-)

Related Solutions

OpenVPN IPV6 Tunnel Radvd

Your question really got me hooked up, since I may use the very same solution in another network I'm managing. I experimented with it and it is indeed possible! (I just love Linux...).

I created a Netkit laboratory that models your situation. You can download the laboratory here (1.8 KiB).

You do not need to install Netkit if you are not interested in testing it in your machine. You can just get the package above and see the .startup files for the various machines. In case you want to test the laboratory, it needs a filesystem with "radvd" installed, which is not included in Netkit's standard filesystem. Check the README of the filesystem package to see how to mount it in your machine and then use apt-get update && apt-get install radvd.

The lab contains 6 machines: v6site (some V6 Internet site you want to access), v6isp (your ISP), r1 (your first router with V4 and V6 connectivity), r2 (your second router that connects to r1 via OpenVPN), pc1 and pc2 (machines connected and served IPv6 by r2).

I used the RFC 3849 documentation prefix 2001:DB8::/32 in the example, instead of the random example addresses you used. Also, I used FEC0::/96 for the OpenVPN endpoints, which is obsolete. In your deployment, it is recommended that you use a small prefix from your Unique Local Address instead.

Clarification: RFC 3849 defines the prefix 2001:DB8::/32 to be used for example and documentation purposes (for global unicast). Instead of choosing any random IPv6 address, people are encouraged to use addresses in the 2001:DB8::/32 prefix as a wildcard in examples that will be changed to something else in the actual deployment. In this question, first 2001:acb:132:acb::/64, then 2001:123:123:11a1::/64. In the answer, I just replaced both with addresses in the documentation prefix. When you apply the answer to your real scenario, just look for every occurrence of 2001:DB8:: addresses and replace them with your actual addresses.

Tunnel endpoints also need addresses. The addresses used in tunnel endpoints do not need to be externally routeable, since they are used only internally. You used addresses starting with FED1:: and FED2::, while I used address starting with FECO::. These addresses were originally defined in RFC 3513. They are the equivalent to IPv4's private-use addresses 10.0.0.0/8, 192.168.0.0/16 and 172.16.0.0/12. Due to problems, they were later deprecated in RFC 3879 in favor of Unique Local Addresses (ULA) in RFC 4193. ULAs have a "random" prefix unique for each end-user. The benefit is that if for any reason you route between these networks, using tunnels for example, they will be able to talk to each other without address translation (while clashes may and do occur when using 192.168.0.0/16, for example). The page linked before this clarification will help you create your own ULA prefix (and possibly register it, but it is not necessary to register).

There is no real problem in using site-local addresses like FECx or FEDx in tunnel endpoints. They are deprecated, but that does not make them wrong. It is just recommended to use ULAs.

The overall configuration of your first router (r1) is bellow. Follow the comments for a better understanding.

# Enable forwarding for IPv6 (between eth0 <-> tun0)
sysctl -w net.ipv6.conf.all.forwarding=1

## ISP V6 Internal network
# Since there is no host specific address, we pick an address in the /64
# prefix. Note that this address is the same in two different prefixes:
# ..11a1::/64 and ..11a0::/59. This requires a proxing hack in R2.
# Optimally, you would have an address in the /59 prefix to use here,
# outside the delegated /64 prefix.
ip link set eth0 up
ip addr add 2001:db8:1:11a1::1/59 dev eth0
ip route add default via 2001:db8:1:11a0::1 dev eth0

## V4 Internet
ip link set eth1 up
ip addr add 192.168.1.1/24 dev eth1

## OpenVPN tunnel via IPv4 Internet to R2
# This is the most basic configuration of OpenVPN. No encryption, no security,
# no nothing. DO NOT USE THIS OUTSIDE THIS LABORATORY.
openvpn --dev tun --tun-ipv6 --daemon

while ! ip link show tun0 2>/dev/null
do
    echo "Waiting for OpenVPN to connect..."
    sleep 1
done

# Configure OpenVPN endpoints. Choose a distinct small prefix for the endpoints
# and use it to route the the /64 prefix to R2.
ip link set tun0 up
ip addr add fec0::1/96 dev tun0
ip route add 2001:db8:1:11a1::/64 via fec0::2 dev tun0

The overall configuration for the second router (r2):

# Enable forwarding for IPv6 (between eth0 <-> tun0)
sysctl -w net.ipv6.conf.all.forwarding=1

## Internal Company IPv6 Network
# The router address is arbitrary.
ip link set eth0 up
ip addr add 2001:db8:1:11a1::ffff/64 dev eth0

## V4 Internet
ip link set eth1 up
ip addr add 192.168.1.2/24 dev eth1

## OpenVPN tunnel via IPv4 Internet to R1
# This is the most basic configuration of OpenVPN. No encryption, no security,
# no nothing. DO NOT USE THIS OUTSIDE THIS LABORATORY.
openvpn --remote 192.168.1.1 --dev tun --tun-ipv6 --daemon

# Wait for OpenVPN...
while ! ip link show tun0 2>/dev/null
do
    echo "Waiting for OpenVPN to connect..."
    sleep 1
done

# Configure OpenVPN endpoints. See comments for R1 above.
# Note that we route ALL IPv6 traffic through the tunnel.
ip link set tun0 up
ip addr add fec0::2/96 dev tun0
ip route add default via fec0::1 dev tun0

# R1 address is in our private network (eth0, see above), but on the other
# side of the tunnel. We need a more specific route specifically for it.
# Also, make this router (R2) act as a neighbor proxy so that other
# machines on the private network can see R1 through the tunnel.
# This is a hack that would be avoided if we had a bigger prefix than
# /64, or if R1 had a host-specific address outside of the /64.
ip route add 2001:db8:1:11a1::1/128 via fec0::1 dev tun0
ip neigh add proxy 2001:db8:1:11a1::1 dev eth0

## Routing advertisement daemon
# NOTE: The standard Netkit filesystem does not have radvd, it has to be
# installed manually with `apt-get update && apt-get install radvd` in
# the model fs.
chmod 644 /etc/radvd.conf
radvd

The configuration for the PCs connected to r1 (eth0) is extremely simple, thanks to radvd:

sysctl -w net.ipv6.conf.all.autoconf=1
ip link set eth0 up

This is the most important configuration. The other details (including a copy of r2's /etc/radvd.conf) are in the laboratory package above.

OpenVPN routing problem

You need to map "incoming" trafic to be properly routed to the client. I.e. you need to set a NAT translation on the server for the IP (the VPN one) of the client.

What you see is that the server does not know how to forward the replies.

Here are instructions how to do this: http://openvpn.net/index.php/open-source/documentation/howto.html#redirect - look at the iptables configuration on the server.

Best Answer

Related Solutions

OpenVPN IPV6 Tunnel Radvd

OpenVPN routing problem

Related Topic