Bug? Limiters apply twice when using OpenVPN-C as an interface (with NAT)
-
I can't find a good match for this anywhere, although my search terms might be out. Thought I'd flag this up here before reporting a bug.
TLDR - Packets routed from LAN out of an in interface bound to an OpenVPN that have been NATted instance go through 2 dynamic child queues
I think I've just engineered a situation that's not considered in the UI and I've also put in a tested workaround. I'll use round numbers in the explanation and simplify it a little.
I use an OpenVPN client connection bound as an additional interface. I get assigned an IP by the VPN server. I use this for outbound connection for multiple devices on my LAN. So I have to NAT traffic leaving the OpenVPN interface to the assigned interface IP. Fairly usual stuff.
I have a BW management based on a single limiter (each way) that matches my WAN bandwidth (call it 100mbps) and then weighted child queues underneath. The child queues then create dynamic queues based on a /32 mask.
Firewall rules on the LAN then put traffic into the queues.
However, if I route traffic over the bound VPN interface, I only get half the available Bandwidth (50mbps) which I just spent a good amount of time blaming on OpenVPN (it wasn't such an obvious round number as 100/50).
I then took a look at the limiter info and spotted that it was creating a dynamic queue for both the local IP of the device AND the NAT IP of the OpenVPN client.
So it's passing the packets through the limiter queue twice and counting towards the total BW for that limiter twice from just the one LAN rule. I assume it's carrying the 'tag' on the state through to the point it leaves the OpenVPN bound interface. I'm also going to assume on a 'normal' WAN interface (PPP/DHCP) there's something in the background to prevent this as I don't see this behavior on those.
To work around this, I have created 2 new limiters with 1000mbps each (well above my WAN speed, so effectively unlimited) and created a floating match rule for traffic OUT of the VPN Interface. This rule specifies the new 1000mbps limiters.
I have verified that this still passes through the intended limiter once, but now passes through the new limiter instead of passing through the same one a 2nd time in a different child queue.