200 lines
7.2 KiB
Markdown
200 lines
7.2 KiB
Markdown
title: IPv6, VPN and DNS entries
|
|
---
|
|
pub_date: 2021-10-13
|
|
---
|
|
author: Nico Schottelius
|
|
---
|
|
twitter_handle: NicoSchottelius
|
|
---
|
|
_hidden: no
|
|
---
|
|
_discoverable: yes
|
|
---
|
|
abstract:
|
|
Looking at how the patterns of VPN and DNS names changes with IPv6
|
|
---
|
|
body:
|
|
|
|
## 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](https://ipv6vpn.ch).
|