Project

General

Profile

Actions
Copy link

Bug #14682

closed

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

Added by Kris Phillips over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Kristof Provost
Category:
OpenVPN
Target version:
23.09
Start date:
Due date:
% Done:

0%

Estimated time:
Release Notes:
Default
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.

Actions
Copy link
 #1

Updated by Jim Pingle over 1 year 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 127.0.0.1.

Actions
Copy link
 #2

Updated by Craig Coonrad over 1 year ago

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

Actions
Copy link
 #3

Updated by Kristof Provost over 1 year 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
Copy link
 #4

Updated by Kristof Provost over 1 year ago

  • Status changed from In Progress to Feedback

Committed upstream in https://cgit.freebsd.org/src/commit/?id=949491f2a6397f2514f8fcde1c7dc61bd82f201a, and cherry-picked to our branches. This will be fixed in the next snapshot build.

Actions
Copy link
 #5

Updated by Lev Prokofev over 1 year 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
Copy link
 #6

Updated by Danilo Zrenjanin over 1 year 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.

Actions
Copy link

Also available in: Atom PDF