IPv6 VPN Routing with Dynamic Prefixes

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.

Note that this post is one of many related to IPv6. Click here for a structured list.

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:

IPv6 VPN Routing with Dyn Prefix

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:

(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.

Featured image “Erst geschmust, dann strubbelig” by Beppe Rijs is licensed under CC BY-NC-ND 2.0.

Leave a Reply

Your email address will not be published. Required fields are marked *