Bug #13358: Traffic to OpenVPN DCO RA clients above the first available tunnel IP address is incorrectly routed - pfSense Plus - pfSense bugtracker

Custom queries

Plus Release Notes - Target Version (DO NOT EDIT)

Actions

Copy link

Bug #13358

closed

Traffic to OpenVPN DCO RA clients above the first available tunnel IP address is incorrectly routed

Added by Steve Wheeler over 2 years ago. Updated almost 2 years ago.

Status:

Resolved

Priority:

High

Assignee:

Kristof Provost

Category:

OpenVPN

Target version:

23.01

Start date:

Due date:

% Done:

Estimated time:

Release Notes:

Default

Affected Plus Version:

22.05

Affected Architecture:

All

Description

Traffic from hosts in the local subnet, for example a server on LAN, can only reach the first assign RA client when DCO is enabled. This includes reply traffic.

Traffic to subsequent clients is incorrectly routed. For example:

steve@steve-Standard-PC-i440FX-PIIX-1996:~$ ping 10.1.9.2
PING 10.1.9.2 (10.1.9.2) 56(84) bytes of data.
64 bytes from 10.1.9.2: icmp_seq=1 ttl=63 time=0.482 ms
^C
--- 10.1.9.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.482/0.482/0.482/0.000 ms
steve@steve-Standard-PC-i440FX-PIIX-1996:~$ ping 10.1.9.3
PING 10.1.9.3 (10.1.9.3) 56(84) bytes of data.
From 10.1.9.1 icmp_seq=1 Redirect Host(New nexthop: 0.0.0.0)
From 10.1.9.1 icmp_seq=1 Redirect Host(New nexthop: 0.0.0.0)
From 10.1.9.1 icmp_seq=1 Redirect Host(New nexthop: 0.0.0.0)

More details to follow.

History
Notes
Property changes

Actions

Copy link

Updated by Jim Pingle over 2 years ago

Assignee set to Kristof Provost
Priority changed from Normal to High

Actions

Copy link

Updated by Steve Wheeler over 2 years ago

Nothing special is required to recreate this beyond enabling DCO:

Install 22.09 clean. Tested: 22.09.a.20220725.0600

Configure a remote access server using the OpenVPN wizard. Accept the default values. I configured it to pass only the LAN subnet as a route.

Create at least 2 valid clients.

Enable DCO.

The resulting openvpn config looks like:

dev ovpns1
verb 1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local 172.21.16.160
tls-server
server 10.160.9.0 255.255.255.0
client-config-dir /var/etc/openvpn/server1/csc
username-as-common-name
plugin /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so /usr/local/sbin/ovpn_auth_verify_async user TG9jYWwgRGF0YWJhc2U= false server1 1194
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'OpenVPN_Server_5' 1" 
lport 1194
management /var/etc/openvpn/server1/sock unix
push "route 192.168.160.0 255.255.255.0" 
capath /var/etc/openvpn/server1/ca
cert /var/etc/openvpn/server1/cert 
key /var/etc/openvpn/server1/key 
dh /etc/dh-parameters.2048
tls-auth /var/etc/openvpn/server1/tls-auth 0
data-ciphers AES-256-GCM
data-ciphers-fallback AES-256-GCM
allow-compression no
persist-remote-ip
float
topology subnet
explicit-exit-notify 1

Connect two or more clients. Only the client receiving the first tunnel subnet IP (10.160.9.2 here) will be able to reach hosts in the LAN subnet.
Other clients will time out trying to reach, for example, 192.168.160.10 but will be able to reach the pfSense LAN IP at 192.168.160.1.

Coming from a host on the LAN subnet the server IP (10.160.9.1) and first client IP will be reachable but other clients result in the routing error:

steve@steve-Standard-PC-i440FX-PIIX-1996:~$ ping 10.160.9.3
PING 10.160.9.3 (10.160.9.3) 56(84) bytes of data.
From 10.160.9.1 icmp_seq=1 Redirect Host(New nexthop: 0.0.0.0)
From 10.160.9.1 icmp_seq=1 Redirect Host(New nexthop: 0.0.0.0)
From 10.160.9.1 icmp_seq=1 Redirect Host(New nexthop: 0.0.0.0)

That is the case for all other IPs in the tunnel subnet whether of not a client exists there.

Actions

Copy link

Updated by Steve Wheeler over 2 years ago

[22.09-DEVELOPMENT][admin@hadev-pri.stevew.lan]/root: netstat -rn4
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            172.21.16.1        UGS      vtnet0
10.160.9.0/24      10.160.9.2         UGS      ovpns1
10.160.9.1         link#8             UHS         lo0
10.160.9.2         link#8             UH       ovpns1
127.0.0.1          link#5             UH          lo0
172.21.16.0/24     link#1             U        vtnet0
172.21.16.1        3e:81:34:ce:48:36  UHS      vtnet0
172.21.16.160      link#1             UHS         lo0
192.168.160.0/24   link#2             U        vtnet1
192.168.160.1      link#2             UHS         lo0

Actions

Copy link

Updated by Steve Wheeler over 2 years ago

Status changed from New to Confirmed

Actions

Copy link

Updated by Kristof Provost over 2 years ago

Status changed from Confirmed to Pull Request Review

https://gitlab.netgate.com/pfSense/FreeBSD-src/-/merge_requests/102

The issue here is that one of the assumptions in the if_ovpn code, namely that we always get an 'ro' argument to ovpn_output() unless called from pf's route-to, was incorrect.
This is the case in main, but not on stable/12. As a result we assumed that the packet was being route-to'd, and we had to send it to the first peer. That peer immediately sent the packet back to the server (according to its routing table), which wound up looping until the TTL expired.

This only affected the fast forwarding code, so I'd expect this problem to not manifest if IPSec is in use (because then we don't use ip_fastfwd()).

Actions

Copy link

Updated by Kristof Provost over 2 years ago

Status changed from Pull Request Review to Ready To Test

Actions

Copy link

Updated by Steve Wheeler about 2 years ago

Status changed from Ready To Test to Resolved

This is fixed in current snapshots.

LAN     icmp     192.168.167.50:7 -> 10.1.9.3:7     0:0     445 / 445     37 KiB / 37 KiB     
OPENVPN0     icmp     192.168.167.50:7 -> 10.1.9.3:7     0:0     445 / 445     37 KiB / 37 KiB     
OPENVPN0     icmp     10.1.9.4:58246 -> 192.168.167.50:58246     0:0     37 / 37     3 KiB / 3 KiB     
LAN     icmp     10.1.9.4:58246 -> 192.168.167.50:58246     0:0     37 / 37     3 KiB / 3 KiB     
OPENVPN0     icmp     10.1.9.3:55881 -> 192.168.167.50:55881     0:0     34 / 34     3 KiB / 3 KiB     
LAN     icmp     10.1.9.3:55881 -> 192.168.167.50:55881     0:0     34 / 34     3 KiB / 3 KiB     
OPENVPN0     icmp     10.1.9.2:26957 -> 192.168.167.50:26957     0:0     22 / 22     2 KiB / 2 KiB     
LAN     icmp     10.1.9.2:26957 -> 192.168.167.50:26957     0:0     22 / 22     2 KiB / 2 KiB

Tested:

22.11-DEVELOPMENT (amd64)
built on Fri Oct 07 15:14:37 UTC 2022
FreeBSD 14.0-CURRENT

Actions

Copy link

Updated by Jim Pingle almost 2 years ago

Subject changed from OpenVPN DCO: Traffic to RA clients above the first available tunnel IP is incorrectly routed to Traffic to OpenVPN DCO RA clients above the first available tunnel IP address is incorrectly routed

Updating subject for release notes.

Actions

Copy link

Also available in: Atom PDF

Project

General

Profile

pfSense » pfSense Plus

Custom queries

Bug #13358

Traffic to OpenVPN DCO RA clients above the first available tunnel IP address is incorrectly routed

Updated by Jim Pingle over 2 years ago

Updated by Steve Wheeler over 2 years ago

Updated by Steve Wheeler over 2 years ago

Updated by Steve Wheeler over 2 years ago

Updated by Kristof Provost over 2 years ago

Updated by Kristof Provost over 2 years ago

Updated by Steve Wheeler about 2 years ago

Updated by Jim Pingle almost 2 years ago