From afd8fa769eac2d5669c686b7002e7541279588c4 Mon Sep 17 00:00:00 2001 From: Nico Schottelius <nico@nico-notebook.schottelius.org> Date: Wed, 13 Oct 2021 12:34:47 +0900 Subject: [PATCH] blog: +ipv6 vpn dns --- .../contents.lr | 198 ++++++++++++++++++ 1 file changed, 198 insertions(+) create mode 100644 content/u/blog/ipv6-success-story-vpn-dns-names/contents.lr diff --git a/content/u/blog/ipv6-success-story-vpn-dns-names/contents.lr b/content/u/blog/ipv6-success-story-vpn-dns-names/contents.lr new file mode 100644 index 0000000..1fced1f --- /dev/null +++ b/content/u/blog/ipv6-success-story-vpn-dns-names/contents.lr @@ -0,0 +1,198 @@ +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 designed in the IPv6 VPN world, just works.