Messages

Thanks for the notes and links.

I just spent hours searching around for a fix to this problem. Suddenly when updating to 26.1 today all of our reverse proxy sites were getting HTTP 421 Misdirected Request from upstream Apache instances. (Adding my comment as no search results were coming up specifically for HTTP 421.)

Found this: https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#https

Using value "{hostport}" for the Host header in all our handlers resolved this for us. (One of our sites doesn't use port 443 making "{hostport}" instead of "{host}" necessary.)

Always great when an important unannounced change occurs. (Thanks Caddy..!)

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.

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.

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)

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.