OpenVPN connection possible although old IPv6 prefix

Got a problem with Viscosity or need help? Ask here!

wpn

Posts: 5
Joined: Thu Jan 28, 2021 11:38 pm

Post by wpn » Thu Jan 28, 2021 11:52 pm
Hello,

I have a technical question although everything is working fine :)

The setup is the following: My Synology with OpenVPN server is behind a FritzBox with IPv6 connection. I can connect via Viscosity, port 1194 is open, everything is running smoothly. As DDNS service I use the Synology one.

Now interesting is, that the Synology OpenVPN server gives a warning when the prefix of the IPv6 address is changed by my provider after a few days. Synology says they know of this circumstance and will make it update automatically. As a result the connection should not be possible.

It is, however. You can see in the log that the DDNS gives the current new address of the Synology and then a few things happen with the old prefix. In the end though, I get a connection.

As this is great, I still would like to know what happens here (and to learn a bit more about IPv6). Could you interpret the part of the log and say me what is going on there? And who is responsible for that? Viscosity itself (thanks for that great piece of software by the way), the router or can the Synology do more than she admits?

Thanks a lot for your input guys,
Stephan


Code: Select all
[xxxxxxxx.synology.me] Peer Connection Initiated with [AF_INET6]2003:xxxx:new:xxxx:1111:1111:1111:1111:1194 (current new correct address)
2021-01-28 12:44:27: Opened utun device utun10
2021-01-28 12:44:27: /sbin/ifconfig utun10 delete
2021-01-28 12:44:27: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2021-01-28 12:44:27: /sbin/ifconfig utun10 10.8.0.6 10.8.0.5 mtu 1500 netmask 255.255.255.255 up
2021-01-28 12:44:27: /sbin/ifconfig utun10 inet6 2003:xxxx:old:xxxx::1000/64 (the outdated prefix the OpenVPN server was configured with)
2021-01-28 12:44:27: add_route_ipv6(2003:xxxx:old:xxxx::/64 -> 2003:xxxx:old:xxxx::1000 metric 0) dev utun10 (old addresses)
2021-01-28 12:44:27: add_route_ipv6(2003:xxxx:new:xxxx:1111:1111:1111:1111/128 -> fe80::2222:2222:2222:2222%en0 metric 1) dev en0 (new address and fe80 of Synology)
2021-01-28 12:44:27: add_route_ipv6(2000::/3 -> 2003:xxxx:old:xxxx::1 metric -1) dev utun10 (old again)

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Sat Jan 30, 2021 10:09 am
Hi Stephan,

It's difficult to answer this accurately without an entire understanding of the remote network configuration and IPv6 configuration. However ultimately two things to consider here: 1) How is the VPN Connection itself able to establish?, and b) How are you able to access internal resources?

So, in regards to 1, it looks like your router is correctly updating to the new prefix, and machines on your internal network are correctly being reassigned IP addresses on the updated prefix. This is how your VPN server is reachable, as it's using the correctly updated IPv6 address. Your dynamic DNS provider will see the update request coming from the new IP address, and update the DNS record accordingly.

In regards to 2, I imagine what is going on is that the Synology server is not updating the IPv6 range it assigns to VPN clients when its own IPv6 range changes. So firstly, even if the IPv6 range it is assigning is now wrong, the server and other VPN clients will still be reachable by this range internally. So if you're simply VPNing into the remote network, and just accessing the Synology server, everything will still appear to work.

Another thing to consider is that IPv6 has the concept of "temporary" addresses (to prevent a device being tracked by its IPv6 address). If the change is in fact a temporary address change, then devices will still be reachable at the old address for some time (usually around a week). You may like to look at the IPv6 addresses the Synology server has assigned to its network interfaces using the command line to see whether it still sees the old range as valid.

For IPv6 devices on the same network, they'll usually route traffic via their link-local IPv6 address. So as long as the Synology is routing traffic upstream correctly to your router's link-local address, it'll still be seen as reachable.

Finally, your VPN network is dual-stack, with an IPv4 range assigned. So other possibility is access to external resources via IPv6 is failing, however your computer is falling back to IPv4.
Code: Select all
/sbin/ifconfig utun10 inet6 2003:xxxx:old:xxxx::1000/64 (the outdated prefix the OpenVPN server was configured with)
This is the range OpenVPN is currently configured to use in the server configuration. The Synology server will need to update the configuration and restart the OpenVPN server process to update this.
Code: Select all
add_route_ipv6(2003:xxxx:old:xxxx::/64 -> 2003:xxxx:old:xxxx::1000 metric 0) dev utun10 (old addresses)
This is an automatic route OpenVPN creates for the remote VPN subnet (related to the above assignment).
Code: Select all
add_route_ipv6(2003:xxxx:new:xxxx:1111:1111:1111:1111/128 -> fe80::2222:2222:2222:2222%en0 metric 1) dev en0 (new address and fe80 of Synology)
This is likely a route created as part of the redirect-gateway command to keep the remote OpenVPN server reachable. It is created client-side (hence the updated IPv6 address).
Code: Select all
add_route_ipv6(2000::/3 -> 2003:xxxx:old:xxxx::1 metric -1) dev utun10 (old again)
This is routing the IPv6 public space into the VPN connection. Likely due to the redirect-gateway command. It uses the gateway as part of the IP assignment above.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

wpn

Posts: 5
Joined: Thu Jan 28, 2021 11:38 pm

Post by wpn » Mon Feb 08, 2021 5:08 am
Hello James,

thank you very much for your extensive answer! Much appreciated.

As the posted configuration is still working after over a week you might be right that it is enough that the Synology (and therefor its OpenVPN server) is reachable with a current IPv6 address. The client (Viscosity) seems to figure out the rest. As the correct updated IPv6 is not needed for using the VPN in this case I am very happy with that.

Thanks again,
Stephan
3 posts Page 1 of 1