IPv6 Support

Categories:

Let’s address the elephant in the room

At this time, IPv6 support for Synclias is in a beta status.

You can turn on IPv6 support, and with a configured alias, it will fill it up just fine, routing as needed, assuming you have a configured IPv6 VPN and functioning alias/firewall rules

Before I begin, let me start with declaring a posture:

IPv6 is the future, it’s coming/already here.

If you have it and it works, I don’t want people to turn it off, but it does present some unique issues, that I will deal with where I can, but there are places that the user will have to decide on some options.

The goal of Synclias has always been to make no changes to client devices if possible, and minimal changes to network setup where needed. It is possible to change a computer to prefer IPv4 over IPv6, but I’d rather find a better way around this.

The Main Issue

With a dual stack network (IPv4 and IPv6), you essentially have two potential paths to a server. Most Operating Systems will prefer IPv6 if it’s configured and working properly.

Synclias can pretty reliably sort out IPv4 traffic. Sadly, if the OS is preferring IPv6, all of that is irrelevant, an IPv6 packet isn’t covered by IPv4 rules and runs through IPv6, essentially negating all the work Synclias does.

Looking at some of the issues here:

1. VPN Providers

Some VPN providers don’t provide IPv6 connectivity, only IPv4.

This isn’t a problem for them as they route everything over the VPN, so things can’t escape, traffic for IPv6 gets modified in a way that works for the IPv4 connectivity they provide.

However, there’s no real way that if your computer sends an IPv6 packet that I can catch it and route it down a VPN tunnel without doing some extra mapping etc that might break things even more.

Synclias could never be a “professional” product, because “Best Effort” isn’t the binary works or doesn’t work that anyone could reliably guarantee. It works perfectly for my use cases, but I’d never run a business relying on it working 24/7

Best Solution I can Offer for this:

Decreasing order of “good idea”:

  1. Find a provider that will route IPv6 for you
  2. Find a common way to configure DNS responses from your DNS server to be IPv4 where possible. If the DNS server gives back an IPv4 address, your device will use the IPv4 stack, and IPv6 is irrelevant - The option here for you is “Prefer IPv4” (Or unchecking “Prefer IPv6”)
  3. I need to fully investigate 6rd or some other form of making OPNsense reliably route IPv6 over IPv4 VPNs
  4. Ask users to only use sites that have IPv4 addresses. (This isn’t a thing, but I want to see how much I don’t want to suggest option 5)
  5. Disable IPv6 on your router/device

IPv6 Subnets

These actually present a “good problem”.

IPv6 Subnets are the same as IPv4 in many ways, and different in others. With so many IPs being assigned to a company/service, doing DNS lookups for one server is actually rather inefficient. Since most companies at the moment have a /64 at least when it comes to subnets their IPs live it, there’s realistically scenarios where we don’t add the IP address, but rather discover the subnet and or just add a /64,/96/128 etc.

This would make the routing rules more efficient, and less likely for scenarios where a server moves, because it’ll be more likely that it’ll move to another address in that subnet. And i’m less concerned about over-scoping, because the IP subnets are so mind-blowing massive in IPv6 that the chances of accidentally including another company are tiny.

That said, it’s going to require some more research to come up with a reliable way to implement this, the back end support is already in Synclias, I just need to decide on some sensible defaults, most likely the default will be a strict mode of just the discovered IP, but I don’t want miss an opportunity to be prepared when a server changers from “1 to 2” in the last hex value of an IP address.