Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have an interesting question regarding ipv6 + openvpn..

My Version is OpenVPN 2.1.1

i have been given 2 native /64 ipv6 networks

( Block1 -> 2a01:abc:123:deac::/64 )

( Block2 -> 2a01:abc:123:dead::/64 )

( Gateway -> 2a01:abc:123:deaf::1/59 ) * i have no control over this *

The plan was/is, route this "Block2" through openvpn and into an office ( for testing purposes )

Soo to explain..

I have a Centos Box as the first linux "router" in a datacenter & a Ubuntu box as the second linux "router" in the office I have created a simple point-to-point tunnel using tun ( based off ipv4 address to start the tunnel )

I have assigned to Centos

ip addr add 2a01:abc:123:dead::1/64 dev eth0
ip addr add fed0::2/128 dev tun0

ip route add 2a01:abc:123:dead::/64 dev tun0  ## ipv6 Block2 down the tunnel
ip route add ::/0 via 2a01:abc:123:deaf::1 dev eth0 ## Default out to Gateway

I have assigned to Ubuntu

ip addr add fed0::3/128 dev tun0
ip addr add 2a01:abc:123:dead::2/64 dev eth0

ip route add ::/0 via 2a01:abc:123:deaf::1 dev tun0 ## Default up the tunnel

I have also included on both servers..

sysctl -w net.inet6.ip6.forwarding=1

Looks Good... right??? Wrong.. :(

I am not able to ping the gateway or 2a01:abc:123:dead::1 from Ubuntu-eth0

I am able to access the internet from any ipv6 interface on the Centos Box but clearly not from the Ubuntu box..

Further, i will eventually run radvd on the Ubuntu box eth0, and autoconf the network with ipv6 address's

Anyone with some advice / tips to help me out.. ???

Cheers

share|improve this question
    
Is your /64 just an example, or you actually have a /64 and not something bigger? Because /64 is the prefix you usually assign at the link-layer, You need something bigger, a /63 at a minimum, so that you can point the inner side of the VPN to a IPv6 address on the other side of the VPN as its gateway. This would be the cleanest way to do it, but there are other ways. –  Juliano Feb 6 '11 at 22:22
    
I only have a 64.. :( i could have 2 x /64 however.. Any suggestions?? –  Arenstar Feb 6 '11 at 22:24
    
I'm trying to formulate a configuration (in my head) that would work with only a single /64. I don't know if radvd works with assignments smaller than /64, so that you have a different address to route outbounds. I'll try some experiments with Netkit later and post the results. –  Juliano Feb 6 '11 at 22:31
    
I know 100% radvd doesnt work with smaller blocks than /64... Its stated in rfc2462 :( Why cant i use the current gateway that was given to me for the block im using??? –  Arenstar Feb 6 '11 at 22:36
    
@Arenstar what is the gateway address (obfuscated, if you want) given to you to use with this /64? Is it in the same network? –  Juliano Feb 6 '11 at 23:12

2 Answers 2

up vote 2 down vote accepted

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.

share|improve this answer
    
Wow.. thanks Julian.. Im trying this as we speak. However i dont understand this.. 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. Where should i be setting my ULA addresses? instead of the RFC 3849 examples? What about my /64 that was assigned to me.. im somewhat confused by this piece –  Arenstar Feb 7 '11 at 11:54
    
@Arenstar I expanded the answer with a clarification, check if it answers you questions. –  Juliano Feb 7 '11 at 14:10
    
I tried this..though it didnt work :( However i did update my question, i now have 2 x /64 blocks any suggestions? ... i think the ip neigh add proxy is not functioning :( ... –  Arenstar Feb 7 '11 at 21:39
    
@Arenstar the configuration is quite complex, and "it didnt work" does not help to determine what could have gone wrong. I can't offer you much more than this, if anything. I suggest you to try the netkit lab I provided and check where in it it differs from your real case. Check IP address lists, route lists, firewall tables, if openvpn is properly forwarding your v6 packets, etc... For each point in the real scenario, check the equivalent machine in the running netkit lab to see what differs. tcpdump is your friend. –  Juliano Feb 8 '11 at 0:53
    
Apologies, i will be more specific after i get back into the office and run some tests.. Could you be more specific about this command??? ip neigh add proxy 2001:db8:1:11a1::1 dev eth0 .. Is should "proxy ARP - ipv4 terms" but i dont think its working :( TCP Dump shows the packets not changing.. –  Arenstar Feb 8 '11 at 1:01

Ask your tunnel broker for a /56 or /48 allocation, at least another /64. You will then be able to generate a /64 in this block for the far end of the link. If you have multiple tunnels you will need a separate /64 for each tunnel.

I would expect the FED1 addresses to always be on the TUN devices only. (Site local addresses are deprecated and should not be used.) You will likely have to specify routing for ::0/0 on the Ubuntu side. Use the 2001: or an FED1:x: address for the Ubuntu eth0 interfaces. RADV should pick up the address automatically, but I program it in.

My configuration uses my /48 allocation for LAN devices, and the /64 for DMZ addresses. This makes firewall configuration easier as they are in non-overlapping ranges.

Your ping results are what I would expect. You will need to specify a link to FED1::1 on Ubuntu. Changing the Centos eth0 address to FED1:1::1 and specifying the addresses as /32s or /64s should help. You only need to know the link addresses on the tunnel ends. The eth0 interfaces should have your 2001: (public addresses).

It the eth0 on Centos is your upstream link it will likely have a Point to Point IPv6 address for the local end of the upstream link. This should be handled by your 6to4 tunnel setup which should also add the default route to the Internet.

EDIT: Suggested configuration

Centos (Server/Network)

ip -6 add fe81::1/64 dev tun0
ip -6 add 2001:acb:132:acb::1/64 dev eth0
ip -6 add route (new /64 allocation) via fe81::2 dev tun0

Ubuntu (Client over tunnel)

Via /etc/network/interfaces

auto tun0
iface tun0 static
    address fe81::2
    netmask 64
    gateway fed1::1

auto eth0 iface eth0 static address (New /64 allocation)::1 netmask 64

Or manually (you may want to handle tun0) in the VPN startup script), but I would configure eth0 with /etc/network/interfaces

ip -6 add fe81::2/64 dev tun0 ip -6 add (new /64)::1/64 dev eth0 ip -6 add route default via fe81::1 dev tun0

Setup radvd on the hosts with default ipv6 routes using eth0 (LAN) interface. The tun0 routing is done manually.

WARNING: Once you get this working all your IPv6 computers will have Internet routeable addresses. Make sure you have a good firewall and understand what traffic you are allowing.

share|improve this answer
    
I dont have the ability to get a bigger allocation, only another /64.. Could you possibly be clearer in your explanation of how to make this work??? Im not really seeing the point to changing the ubuntu eth0 to a different FED or Documentation address.. –  Arenstar Feb 7 '11 at 2:04
    
@Arenstar You only need to manually added addresses on the route end points. eth0 interfaces should be using and providing 2001:x:y:z::/64 network blocks. I've edited the response to use a second /64. I haven't seen any support for bridging ipv6 over openVPN which would be require to use the same /64 with radvd on the two networks. –  BillThor Feb 7 '11 at 4:41
    
I currently now have 2 x /64 blocks.. What should be on the Centos eth0?.. 2001:x:y:z::1/64 ??? –  Arenstar Feb 7 '11 at 20:45
    
Put one of the /64 blocks on the Ubuntu eth0. The other one should preferably be on the LAN interface of your Internet gateway. If this this your Centos server, then it should be on eth0. This assumes eth1 or some other interface connects to the Internet. –  BillThor Feb 8 '11 at 19:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.