Bug #14682
closed
DCO OpenVPN server bound to Localhost does not pass traffic as expected
Added by Kris Phillips over 1 year ago.
Updated about 1 year ago.
Affected Plus Version:
23.05.1
Affected Architecture:
All
Description
When connected to an OpenVPN server that has DCO enabled and the OpenVPN server is bound to Localhost with Port Forwards (in order to utilize MultiWAN), traffic destined for any of the "Local IPv4 Networks" destinations does not pass.
If you disable DCO, traffic works normally. Traffic is also normal when you bind it to a Failover Group, interface, VIP, or Any.
- Subject changed from Routing Broken when DCO is Enabled on a Remote Access OpenVPN Server bound to Localhost to DCO OpenVPN server bound to Localhost does not pass traffic as expected
- Assignee set to Kristof Provost
- Target version set to 23.09
I can confirm this (even on 23.09 snaps) but it doesn't seem to be a routing issue. I see all the same interface configuration and route table contents.
The client can ping the server LAN and get a response, but I do not see any entries in the state table being created for traffic coming from the client.
TCP connections don't appear to work, however.
I see the packets coming in on the ovpnsX interface but it doesn't seem to be hitting the pf rules somehow.
The only difference in the OpenVPN configuration is that the local entry changes from the WAN address to 127.0.0.1.
I was able to confirm this bug on 2100 w/23.05.1.
- Status changed from New to In Progress
I've also been able to reproduce this.
The problem turns out to be that we pass through pf multiple times (which is expected): once with the OpenVPN packet, and then again when we decapsulate the tunnel payload packet. The OpenVPN packet got flagged as M_SKIP_FIREWALL, which caused us to accept the packet without creating state. This lack of state caused the reply packet to be discarded. This also explains why the ICMP echo did work, because pf doesn't track ICMP state sufficiently to distinguish an echo request from an echo reply.
The fix is straightforward: if_ovpn needs to clear this flag (and others) while handing packets.
- Status changed from In Progress to Feedback
Tested on
23.09-DEVELOPMENT (amd64)
built on Wed Aug 23 06:05:57 UTC 2023
FreeBSD 14.0-ALPHA2
I'm able to reach the "local ipv4" subnets of the Server on the local host with enabled DCO
- Status changed from Feedback to Resolved
Tested against:
23.09-DEVELOPMENT (amd64)
built on Sat Aug 26 04:50:14 UTC 2023
FreeBSD 14.0-ALPHA2
I can confirm it's fixed.
I am marking this case resolved.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by