Bug #14682


DCO OpenVPN server bound to Localhost does not pass traffic as expected

Added by Kris Phillips 11 months ago. Updated 11 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Release Notes:
Affected Plus Version:
Affected Architecture:


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.

Actions #1

Updated by Jim Pingle 11 months ago

  • 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

Actions #2

Updated by Craig Coonrad 11 months ago

I was able to confirm this bug on 2100 w/23.05.1.

Actions #3

Updated by Kristof Provost 11 months ago

  • 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.

Actions #4

Updated by Kristof Provost 11 months ago

  • Status changed from In Progress to Feedback

Committed upstream in, and cherry-picked to our branches. This will be fixed in the next snapshot build.

Actions #5

Updated by Lev Prokofev 11 months ago

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

Actions #6

Updated by Danilo Zrenjanin 11 months ago

  • 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