IPv6 Site-to-Site VPN Recommendations

With global IPv6 routing, every single host has its own global unicast IPv6 address (GUA). No NAT anymore. No dirty tricks between hosts and routers. Great. Security is made merely by firewalls and policies. Site-to-site VPNs between partners can be build without address conflicts. Great again!

However, one problem to consider is the proper IPv6 routing via site-to-site VPNs since both sides now can reach each other even without a VPN. This was (mostly) not true with IPv4 in which both partners heavily relied on private RFC 1918 addresses that were not routable in the Internet. If specific IPv6 traffic should flow through a VPN but does actually traverse the Internet, it would be easy for a hacker to eavesdrop this traffic, leading to a security issue!

The following principles should be realized properly to assure that IPv6 traffic is never routed through the mere Internet when a site-to-site VPN tunnel is in place. Even in a failure of that tunnel. The principles can be applied to any IPv6 tunnels between partners, remote sites, home offices, etc., as long as the other site has its own global unicast IPv6 address space. (For VPNs in which a sub-prefix from the headquarters prefix is routed to a remote site, the situation behaves different. This article focuses on the routing between different IPv6 adress spaces.)

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

IPv6 Site-to-Site VPN Principles

On both sites of the VPN tunnel, the following steps must be accomplished:

  1. Static and permanent (!) route to the other site through VPN: For route-based VPNs, the static route through the tunnel should be “permanent”, i.e., should remain in the routing table even if the VPN is not established. Otherwise, in case of a VPN error, new connections could take the default route directly to the Internet. This principle might be problematic with policy-based VPNs. In such cases (if the policy-vpn has precedence over the routing table), a static route to the remote site subnet into the Null0 interface can be set.
  2. Unicast Reverse Path Forwarding (uRPF): If the static and permanent route is set and the remote site sends packets through the Internet, these IPv6 packets come from the untrust interface and will be discarded because they should only come in from the VPN tunnel interface.
  3. Explicit policy from “trust -> untrust” that denies traffic to the remote site: If someone accidentally deletes the static route, traffic would be routed directly through the Internet. With this deny policy, it would be blocked at the firewall before it leaves it. (Another option would be to “reject” the traffic, i.e., send an ICMP unreachable back to the sender. This would help troubleshooting the issue.) Note that a policy from “trust -> vpn” must be set to allow traffic through the VPN at all.
  4. Explicit policy from “untrust -> trust” that denies traffic from the remote site: If not an explicit “deny any any” is already set, this rule helps to block incoming traffic if the remote site has not implemented the preceding steps correctly.

All four points at-a-glance:

IPv6 Site-to-Site VPN Recommendations

Some notes:

  • Of course, a policy from “trust -> vpn” that allows certain traffic must be in place, too. But this should be the case anyway, because otherwise the VPN would not work. Similarly, a policy from “vpn -> trust”, if needed.
  • With static IPv6 addresses/prefixes at the remote site, certain allow policy from “untrust -> trust” with limitations of the source IPv6 addresses of the remote site would be ok, if ony secured protocols (such as https, ssh, ftps, …) are used. However, if it was decided to use a site-to-site VPN tunnel, this should not be the case anymore.
  • It is necessary to have the deny policies in place to not only rely on proper routing. Security must be made at a security stage (policy) and not at the network layer (routing)! [Similar to: Why NAT has nothing to do with Security!]

Example

The following paragraphs show an example of these principles with two Juniper ScreenOS firewalls. I used a site-to-site VPN that is established over IPv4 but routes IPv6 traffic. This is the lab:

IPv6 Site-to-Site Recommendations Lab

Before VPN

Before the site-to-site VPN tunnel was configured, the remote office could reach the headquarter directly via the Internet. The following traceroute output is made from a Windows PC in the remote office, pinging into the headquarter. Note that this IPv6 connection traverses directly through the Internet:

A route lookup to the destination IPv6 address on the router/firewall looks like that: It uses the default route (in my case through interface eth0/0):

 

With VPN

Now, a site-to-site VPN between the two firewalls is established. The following screenshots document the static routes and policies on both Juniper SSG firewalls:

Now, the same traceroute command reveals the route through the encrypted VPN tunnel. (The second hop is not answering, because I am only using link-local IPv6 addresses on the tunnel interfaces):

The routing table lookup on the firewall on the remote site now shows the usage of the tunnel interface:

 

Broken VPN -> Still Permanent Route

In this example, the VPN could not establish a connection. But due to the permanent route, traffic is not exposed in the Internet since it is still routed to the tunnel interface. Of course, the connections did not work. (Tested from the remote site.)

Broken VPN - Still Permanent Route Allowed Traffic

Deleted Route -> Still Policy

In this example someone misconfigured the routing table and deleted the specific route through the VPN. No traffic traverses the Internet because of principle number three, which still has the “deny” policy from trust -> untrust. (Tested from the remote site.)

Deleted Route - Still Deny Policy Untrust

Deleted Remote Policy -> Still Headquarter Policy

In this example, the route and all policies on the remote site were deleted. Now the connection worked until the headquarter firewall through the Internet, but was blocked there due to principle 2 and 4:

 

Principle 2 (uRPF) on the headquarter worked, because it did not expect traffic from the remote site’s IPv6 subnet from the untrust interface, and therefore blocked it:

Deleted Remote Policy - IP Spoofing on Headquarter

But even after I deleted the route on the headquarter firewall into the remote site (uRPF won’t block connections anymore), the connections were blocked due to principle number 4, which is the untrust -> trust DENY policy:

Deleted Remote Policy - From Untrust Deny on Headquarter

Conclusion

With these four principles/recommendations it is possible to ensure that IPv6 traffic which should only traverse through a secure VPN connection won’t ever traverse through the Internet, even in case of a VPN failure. They furthermore ensure, that security is not made only at the network layer (routing), but at a firewall stage (policy).

Featured image “In die Röhren geschaut” by 5auge is licensed under CC BY-NC-ND 2.0.

7 thoughts on “IPv6 Site-to-Site VPN Recommendations

  1. A very good read. I have one question…..is it possible that you could use IPv6 IPSec to connect site to site over the internet securely without the need for a VPN?

      1. Hey Johannes, sorry for not being very clear…….IPv6 has IPSEC built into the protocol……so potentially you could configure endpoint to endpoint connectivity between offices using IPv6 IPSEC without the need for a VPN tunnel to be created from firewall on site A to firewall on site B. I was just wondering if a secure connection could be established for all communication between endpoints using IPv6 IPSEC as both sites have their own unique global address space.

        1. Hey Very. Ah, ok, I get your point. I have to disappoint you: IPv6 has NOT IPsec built into the protocol. While there might be some IPv6 endpoints that leverage IPsec VPNs, the majority won’t!

          Yes, you will be able to use IPsec VPNs based on IPv6 due to the end-to-end connectivity (global unicast addresses), but it is not supposed that you will see such scenarios that often.

          (Not to mention the problems with the IPv6 extension header for ESP, which is more likely to be dropped than legacy IPv4 ESP packets. :( Ref: https://twitter.com/FernandoGont/status/1398190646146523138 )

  2. Hi Johannes, I came acroos your article for Heise on the topic, and follwed the link. YOu got me with the warning, however I am not fully sure, if this also applies non-site-to-site VPN? e.g. Wireguard on a phoen connecting to your FritzBox at home?

    1. Hey Brucie,

      uh, good point. Thanks for the question.

      The answer is: YES, this also applies to remote access VPNs. That is: If your client has a global unicast IPv6 address (GUA) and the resource she wants to access is in an enterprise network which is also reachable via IPv6, she *can* access this resource without a VPN. This was not the case with legacy IP, where you could not reach internal servers directly since they were addressed with private IPv4 addresses. Hence: different compared to legacy IP!

      That is: You MUST use security policies (ACLs) to control which resources should be reached via the Internet or via RA VPNs only.

      To my mind, the big differences between site-to-site VPNs and remote access VPNs are: For RA VPNs you were used to use ACLs anyway (for example: do NOT allow inbound access), while for S2S VPNs this is probably new. Hence a stumbling block.

      And, of course, it’s dependent on the use case. For site-to-site VPNs it’s probably mail traffic (TCP 25) or DNS traffic (UDP/TCP 53) that is NOT encrypted by default but should be kept secret when traversing the Internet. Here, my blog post kicks in. For client traffic, this is hopefully not the case anyway. That is: client traffic should be encrypted anyway nowadays.

      Anyway: zero trust is coming. ;) You should use authentication and encryption for every single application everywhere anyway. :D

Leave a Reply

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