How to route traffic inside an IPv6 site-to-site VPN tunnel if one side offers only dynamic IPv6 prefixes? With IPv4, the private network segments were statically routed through the tunnel. But with a dynamic prefix, a static route is not possible. That is, a dynamic routing protocol must be used. Here is an example of how I used OSPFv3 for IPv6 between my VPN endpoints.
In detail, I have a home office with a dual stack ISP connection. However, this connection has a dynamic IPv6 prefix: After every reboot or lost connection of the firewall, I get a new IPv6 prefix. This is really bad for building a site-to-site VPN to the headquarter. Since I don’t want to use any kind of NAT/NPTv6 with unique local addresses, I am talking OSPFv3 over the VPN tunnel in order to route the dynamic prefix range (global unicast) via the tunnel.
Pre Notes
My ISP (Deutsche Telekom) offers a dual stack connection, ref [de]: connection establishment. I am currently using a Juniper ScreenOS SSG firewall for the PPPoE connection, ref: DHCPv6 prefix delegation. Furthermore, I want to implement the IPv6 site-to-site VPN recommendations. I am using OSPFv3 for IPv6 similar to my test lab. The site-to-site VPN tunnel is established over IPv4, but tunnels both protocols, ref: IPv6 through IPv4 VPN tunnel.
OSPFv3 and Policies
Well, the solution is quite simple: Activate OSPFv3 on the tunnel interfaces and on all trust networks. After a new IPv6 prefix is received and the site-to-site tunnel is established, the remote office prefix will be reachable from the headquarter through the VPN tunnel. However, in order to prevent unencrypted traffic flows through the mere Internet, some additional security policies on the remote office must be in place. This is needed to not only rely on the dynamic routing protocol OSPFv3 for security issues. Security (i.e., blocking false connections) must be done at the security stage, not on the routing layer. The following policies must be used on the remote site:
- trust -> untrust: deny to headquarter! (<- with this rule, traffic to the headquarter won’t go directly to the Internet in case of a VPN failure)
- trust -> VPN: allow to headquarter (<- only this direction should be used)
On the headquarter, there is no way to implement any specific policy rules, e.g., from untrust -> trust, because you simply do not know the dynamic prefix of the remote office. The same set of policies as always can be used:
- untrust -> trust: deny any
- untrust -> DMZ: public services allowed, remaining deny
- trust -> untrust: (mostly) allow
- trust -> VPN: (mostly) allow
- VPN -> trust/DMZ: (mostly) allow
Example with Juniper SSGs
This is an overview of the network settings:
The implementation looks as follows: (Refer to the descriptions beneath the screenshots)
That is, the IPv6 prefix of the remote site is inserted in the routing table on the headquarter:
Or listed via the CLI:
fd-wv-fw01-> get vrouter trust-vr route v6 protocol ospfv3
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP/RIPng P: Permanent D: Auto-Discovered
N: NHRP
iB: IBGP eB: EBGP O: OSPF/OSPFv3 E1: OSPF external type 1
E2: OSPF/OSPFv3 external type 2 trailing B: backup route
Total 21/max entries
ID IP-Prefix Interface
Gateway P Pref Mtr Vsys
--------------------------------------------------------------------------------------
56 2003:51:6012:101::/64 eth0/6
:: O 60 100 Root
* 78 2003:51:6012:102::/64 eth0/6
fe80::21a:6cff:fea1:2b98 O 60 200 Root
54 2003:51:6012:110::/64 eth0/5.10
:: O 60 100 Root
* 82 2003:51:6012:121::/64 eth0/6
fe80::b60c:25ff:fe05:8e10 O 60 110 Root
* 83 2003:51:6012:120::/64 eth0/6
fe80::b60c:25ff:fe05:8e10 O 60 110 Root
* 87 2003:51:6012:123::/64 eth0/6
fe80::b60c:25ff:fe05:8e10 O 60 110 Root
* 85 2003:51:6012:125::/64 eth0/6
fe80::b60c:25ff:fe05:8e10 O 60 110 Root
* 86 2003:51:6012:124::/64 eth0/6
fe80::b60c:25ff:fe05:8e10 O 60 110 Root
* 79 2003:51:6012:130::/64 eth0/6
fe80::2a94:fff:fea8:772d O 60 200 Root
* 80 2003:51:6012:160::/64 eth0/6
fe80::a5b:eff:fe3c:115d O 60 200 Root
* 81 2003:51:6012:180::/64 eth0/6
fe80::20c:29ff:fe63:2159 O 60 110 Root
* 75 2003:50:aa0c:1300::/64 tun.2
fe80::fce5:40ff:fe14:1 O 60 10100 Root
* 76 2003:50:aa0c:1342:b2c6:9aff:fefd:ca97/128 tun.2
fe80::fce5:40ff:fe14:1 O 60 10000 Root
Total number of ospfv3 routes: 13(Note: There is something wrong with the OSPFv3 route to the “wireless0/2” subnet on the remote site. It is only listed as a /128 route to the IPv6 address of the interface and not as a /64 route the whole subnet. I do not know why, but suppose an issue with the OSPFv3 handling on the wireless0/2 interface on the Juniper. Maybe someone has an idea?)
Conclusion
Of course, it is not optimal to have dynamic prefixes at a remote site. It is always preferable to have static addresses. However, as with IPv4, many home offices etc. have only dynamic addresses, or dynamic prefixes within IPv6. With this “OSPFv3 over VPN tunnel” approach, it is possible to use the allocated IPv6 range (global unicast addresses, GUA) at remote sites while still routing traffic to the headquarter through a site-to-site VPN tunnel. It avoids using unique local addresses (ULA) for remote sites in conjunction with NPTv6.