IPv6, VPN and DNS entries

Posted on 2021-10-13 by Nico Schottelius

TL; DR

With IPv6, DNS management of protected networks can be simplified. IPv6 VPNs can use simplified DNS configurations to simplify the network configurations by just using public, restricted DNS entries.

VPN and DNS in the IPv4 world

VPNs in the IPv4 world are often used to create site-to-site tunnels, allowing different networks to talk to each other. A typical case is that organisation A needs to access protected resources of organisation B and maybe even vice-versa. So a typical VPN looks like this:

Organisation A
-------------

Protected Host A ---------- Router/VPN gateway
(10.0.0.42/24)                      |
                                    |
                                    |
Organisation B                  (Internet)
--------------                      |
                                    |
                                    |
Protected Host B ---------- Router/VPN gateway
(10.20.0.42/24)
Host name: lakeside.int.org-b.example.com

Now if the Protected Host A and Protected Host B want to communicate with each other on IP basis, this is no problem (I am not elaborating on the problems of IP collisions in this article, a follow up article will follow soon).

However if Protected Host A wants to reach the Protected Host B via its internal DNS name lakeside.int.org-b.example.com, this is usually a problem, for multiple reasons:

  • Protected Host A might not know the right internal DNS server to query for int.org-b.example.com.
  • Protected Host A might know the right internal DNS server to query for int.org-b.example.com, but might not have access to it via the VPN
  • The DNS records for int.org-b.example.com often are intentionally not published to public DNS for multiple reasons: privacy related or because administrators don't like to publish RFC1918 records into public DNS records

VPN and DNS in the IPv6 world

There are multiple ways of how VPNs can be built in the IPv6 world, including usage of the private IPv4 addresses equivalent named Unique Local Address (ULA). However instead of using ULA, I will today show an approach that is more "IPv6 native", using Global Unique Addresses (GUA), or what is simply known as "public IPv6 address".

While you might have heard it, I will repeat nonetheless: there are enough IPv6 addresses for every practical use case that we imagine at the moment. This is important, because we can use globally unique IPv6 addresses inside the VPN.

Isn't that a problem? Publicly reachable IPv6 addresses inside a VPN? It would, if the addresses were globally reachable. In the IPv6 world nothing speaks against having globally unique, but non-routed IPv6 addresses. This is actually a perfect match and much better than we can do in the IPv4 world:

  • Both organisations A and B can acquire globally unique addresses. Let's say they organisation A acquires 2001:db8:0::/48 and organisation B acquires 2001:db8:1::/48.
  • Both organisations have two options: they can announce their IPv6 range to the Internet and block access to their internal network or
  • both they can even consider not to announce their network at all (there is not route in the Internet for it)

In either case, both organisations will usually select a sub network of size /64 for the resources they want to expose via the VPN. Let's say organisation A chooses 2001:db8:0:cafe::/64 and organisation B chooses 2001:db8:1:7ea::/64. Putting this in context, their VPN now looks like this:

Organisation A
-------------

Protected Host A ---------- Router/VPN gateway
(2001:db8:0:cafe::42/64)            |
                                    |
                                    |
Organisation B                  (Internet)
--------------                      |
                                    |
                                    |
Protected Host B ---------- Router/VPN gateway
(2001:db8:1:7ea::42/64)            |
Host name: lakeside.int.org-b.example.com

Now, how does this change the DNS server situation? Because we are using IPv6, we have many more options:

  • a) We can publish the DNS records of the domain int.org-b.example.com globally. While access to the network 2001:db8:1:7ea::/64 is only possible via VPN, nothing speaks against having the records in a public DNS server. However, some administrators advocate to not publish them publicly for privacy reasons. That is the same logic as publishing or not publish the RFC1918 (10.x.y.z) addresses in the IPv4 world.
  • b) We can publicly/globally delegate the domain int.org-b.example.com to a nameserver that is only reachable via the VPN.
  • c) We can proceed the same as in the IPv4 world and have a disconnect, internal DNS server that is responsible for int.org-b.example.com.

Option (a) is often seen as a security risk and it can be debated whether someone who can already guess the correct hostname and retrieve it's IP address is really a significant higher security thread than anybody just guessing IP addresses.

Option (c) is the typical case for IPv4 based VPNs and is causing above illustrated issues.

Option (b) is the one that makes IPv6 VPNs much more interesting than IPv4 based VPNs:

  • The world can know that there is an internal domain int.org-b.example.com and find out which DNS servers are responsible for it.
  • However an attacker easily guesses that internal networks exist anyway.

Let's have a look at sample nameserver entries in detail:

int.org-b.example.com. NS ns-int1.org-b.example.com.
int.org-b.example.com. NS ns-int2.org-b.example.com.

What does that mean? Anyone in the world can retrieve the information that int.org-b.example.com has two DNS servers. However the DNS servers responsible for org-b.example.com can hide the IP addresses of ns-int1.org-b.example.com and ns-int2.org-b.example.com for everyone, but hosts coming from organisation A. Or even if the IP addressses of ns-int1.org-b.example.com and ns-int2.org-b.example.com are world known, access to them can easily be prevented.

The measures for this can for instance be DNS views or firewall entries. In practice this means for VPNs in the IPv6 world:

Organisation A
-------------

Protected Host A: what is the IP address of lakeside.int.org-b.example.com?
DNS Server of Organisation B: 2001:db8:1:7ea::42


Outside party
------------
Outside Hosts: what is the IP address of lakeside.int.org-b.example.com?

a) DNS Server of Organisation B: there is no domain
   int.org-b.example.com (DNS view restriction)
b) DNS Server of Organisation B: these are the nameserver for
   int.org-b.example.com, but you cannot reach them (firewall protection)

Summary

For IPv6 based VPNs you can get away without reconfiguring your source networks for DNS servers of the destination party. The target party always needs to ensure proper access control to internal resources, so there is no additional overhead.

DNS, correctly used in the IPv6 VPN world, is a really smooth operation. This is why we recommend to use IPv6 as a basis for VPNs.