Most likely it’s just my Google skills failing, but as an IPv6 beginner I’m having a hard time finding a good introductory overview of what it looks like to have a VPN connection between IPv6 networks.
Is it effectively just a lower-cost route to the remote network’s globally-routable address, so it gets used instead of the public Internet? If so, how do clients detect when the VPN connection is down, since there’d still be a valid route to the other side (just with a firewall blocking traffic)?
Or do all the hosts on both sides have to have ULAs in addition to their globally-routable addresses? How do you ensure that hosts don’t try to use their ULAs as the source addresses for traffic to the public Internet? And how does that work for point-to-point VPN connections (like running a VPN client on a laptop for remote work) given you can’t count on an arbitrary computer having a consistent ULA?
Is it effectively just a lower-cost route to the remote network’s globally-routable address, so it gets used instead of the public Internet?
If the VPN software adds a route to the global IPv6 prefix used by the remote network, then that route will be preferred since it’s more specific than a default IPv6 route.
How do you ensure that hosts don’t try to use their ULAs as the source addresses for traffic to the public Internet?
The IPv6 source-address selection usually is configured to prefer a global source address when connecting to another global address. (BTW it’s configured with “ip addrlabel” and /etc/gai.conf in Linux.)
You don’t necessarily need ULAs. If your goal is to create a walled virtual intranet without traffic reaching the internet (say, “I want to provide workers-from-home access to our company’s internal printers”), that’s where ULAs are designed for.
So to answer your question:
How do you ensure that hosts don’t try to use their ULAs as the source addresses for traffic to the public Internet?
ULAs are meant to be non-routable towards the public internet, every operating system knows this and will always try global addresses first.
If your goal is to provide internet connectivity through the VPN server (the typical “I want to hide my country of origin”, or “we want to be able to filter/monitor our employees internet traffic”), you use globally routed addresses.
It’s really not that different from IPv4. VPN happens a level higher than TCP/IP so the basics are the same.
Assuming that the VPN server has a globally routed /64 subnet delegated to it (let’s say,2001:xxxx:yyyy:zzzz and itself takes the ::1 address on that subnet), it can either distribute full IPv6 addresses to connected clients in a ‘managed’ way through DHCPv6, or just advertise the /64 to the clients, who then self-assign one or more addresses (SLAAC).
The clients will then have:
a virtual network interface, with a globally routed address. Say, interface vpn0 with address 2001:xxxx:yyyy:zzzz:{device id1}, and the default gateway 2001:xxxx:yyyy:zzzz::1 = the company VPN server
their regular ‘real’ network interface with another globally routed address, but from your ISP’s range. Say, interface en0 with address 2001:xyxy:yzyz:xzxz:{device id2} with default gateway 2001:xyxy:yzyz:xzxz::1 = your home router
How the OS detects/decides which interface to use for what traffic (the virtual one or the physical one), how the fallback goes, etc is the same with v4 and v6, that happens on the lower level in the networking stack.
With IPv6 you potentially have a working route to the target network outside of the VPN, it’s possible for the firewall configuration to provide different levels of access to VPN users vs non VPN users. For instance i have a dual stack hosting network, i can still reach the public services (eg http/https) without vpn, but with vpn connected i can also reach management services (eg ssh) that are not reachable publicly.
You don’t need to use separate addresses for internal/external access, the same address will work and your firewall decides what is or isn’t allowed. This reduces complexity, making things easier to manage.
With ipv4 you still have a default route, so your system can still try to route the traffic, it will just fail and probably get nowhere near the target (it will end up in the isp somewhere, or on your local network if there’s some address space overlap).
Any stray traffic (users/software trying to connect to over-vpn services while not connected to vpn) will hit your firewall with v6 so you will see it, vs going to some unknown destination with v4. The latter is undesirable as you have no control over the internal addresses used by other organisations, all manner of things could happen if the networks your users are connecting from actually have machines on those addresses and you will have no idea what is happening or how often. With v6 the traffic still reaches you, you can see what’s happening and take steps to control it etc.
I don’t bother with ULAs, i just use the global addressing and the firewall/vpn rules differentiate the traffic depending how it arrives.
Longest prefix match (also called Maximum prefix length match) refers to an algorithm used by routers in Internet Protocol (IP) networking to select an entry from a forwarding table. Because each entry in a forwarding table may specify a sub-network, one destination address may match more than one forwarding table entry. The most specific of the matching table entries — the one with the longest subnet mask — is called the longest prefix match. It is called this because it is also the entry where the largest number of leading address bits of the destination address match those in the table entry.
Riding on this, using something like NetBox or another IPAM will help figure out the network segmentation. ULAs start as /48 , so you could segment into maybe /52, /56, and /60 for regions & levels; your end-layer networks need to be /64, but your actual tunnels can be /124 or even /127 (I’ve seen both).