[OpenVPN] High packet loss, only when connecting to the server via IPv6

[AdamReece.WebBox]

Hello,

We've recently migrated to OpnSense and use OpenVPN for our staff to connect to our office when working remotely. Feature wise this is all well, however I've noticed that when starting a tunnel connecting to the server over IPv6 there is approximately 11% of packet loss for traffic within the tunnel. (This is quite high for stable service.)

I used WinMTR to consistently check loss to the OpnSense router directly being routed un-tunnelled, and another instance to check loss to a host within the closed network tunnelled. To the un-tunnelled loss was sub 1%, though tunnelled loss was anywhere from 9%-13%.

Importantly I noticed that if I switch my OpenVPN client to only use an IPv4 server the loss goes away completely. Changing from UDP to TCP did not have any impact.

In my test scenario both sides (my home and our office) are on fully native IPv4 + IPv6, and are in fact using the same ISP (Zen Internet). The connectivity, non-tunnelled, between us is rather ideal with minimal to go wrong.

One thing that might be important: For the IPv6 server to be readily available we're using a static floating IP address attached to the WAN interface, because although Zen Internet allocate us a 48-bit IPv6 prefix they (along with Openreach) also require use of DHCPv6 to establish IPv6 over PPPoE. Therefore the floating IP address is how we can have a static IPv6 address from within our 48-bit prefix for our office's router. (This isn't a problem for IPv4 as we have a single static address for that.)

Installation is on bare metal, version 24.1.2_1-amd64.

[Saarbremer]

You may have a problem with MTU along the path which causes IPv6 packets being dropped. Make sure IPV6-ICMP is handled correctly on WAN.

See RFC 4890 for recommendations and/or search for IPV6-ICMP in this forum.

[AdamReece.WebBox]

Would that only apply to OpenVPN encapsulated packets? Using un-tunnelled IPv6 from home to a particular host within the office there is no loss at all.
I'm also seeing 5 automatic firewall rules for RFC4890. (Attached)

[Saarbremer]

That would apply to any IPv6 traffic. While MTU is dependent on the connection target and the routes between.

Assuming the error remains with OpenVPN did you run a packet check on WAN and check for any unusual traffic to UDP 1194?

Same for the inner OpenVPN connection? Do you run IPv6 within the tunnel?

I currently run OpenVPN on 24.1.2_1 and cannot confirm packet loss an IPv6 based connections. Neither IPv6 nor IPv4 have issues within the tunnel.

[AdamReece.WebBox]

Assuming the error remains with OpenVPN did you run a packet check on WAN and check for any unusual traffic to UDP 1194?

No, I'm not sure what would be considered unusual.

Do you run IPv6 within the tunnel?

Yes. The OpenVPN server exposes routes to the office's IPv4 and IPv6 prefixes.

[Saarbremer]

Regarding IPv6 in the tunnel, do you propagate global addresses or do you go with unique local adresses?

However, I am not an export on that topic.

Regarding unusual traffic: Do you see a lot of blocked stuff that shouldn't be blocked on UDP1194? Do you always see the public IP of your remote networks/roadwarriors or is it something unknown?

The thing is, there is bunch of possible problems on many levels and you should odd every single one out.

[AdamReece.WebBox]

Regarding IPv6 in the tunnel, do you propagate global addresses or do you go with unique local adresses?

Global. A single route is exposed for our whole 48-bit prefix. Clients are assigned an IPv6 address within a specific VLAN for VPN clients.

Regarding unusual traffic: Do you see a lot of blocked stuff that shouldn't be blocked on UDP1194? Do you always see the public IP of your remote networks/roadwarriors or is it something unknown?

Ah I see what you mean. No not really, UDPv6 port 1194 is rather quiet. :)

--

The issue might be elsewhere. Today I've noticed another colleague using OpenVPN via IPv6. Pinging their virtually assigned IPv6 address from within the office doesn't seem to have any loss at all.

Thanks for your responses. :) I'll need to inspect port 1194 traffic again while someone is connected whom experiences a lot of loss.

[Saarbremer]

You're welcome. Good luck.