Solved: site-to-site up but not routing, can't use a /30 or /24 tunnel?

SpaceBass

Solved upgraded the server from OpenVPN 2.5 to 2.6.3 ‍️ and the rest started working... apparently there is a bug in the Debian releases of 2.5.x where it doesn't successfully add the routes for the tunnel network to the server host.

Also - @SteveITS's suggestion of applying this patch solved the pfSense client error with the tunnel network.

hey folks,
Can't believe I'm asking for help... I usually dont have any issues with OpenVPN configs... but this one is stumping me.

TL;DR
Tunnel is up, can ping either side of tunnel from both the server and pfSense's console, can't route traffic from either server or LAN hosts. Also, pfSense's openVPN client crashes if I use anything in the tunnel network settings besides a /30. Tunnel comes up if I omit any setting there.

Perhaps a separate issue, but in the past I've always used /30 for site-to-site setups... but the latest OpenVPN release, at least on Debian, complains about subnets smaller than /29... and if I use /29 or /28 with pfSense, the client doesnt start. If I use /24 on the server and omit the setting on pfSense, the tunnel comes up (but no routing)

Details:
Server - Debian, OpenVPN 2.5.1, public ip 57.x.x.x /32

Client - pfSense 23.01-RELEASE on a Netgate 6100, public IP 198.x.x.x/32, LAN is 10.15.1.0/24

Tunnel network - 10.152.0.0/24

Server conf:

local 57.x.x.x
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key  
topology subnet
server 10.152.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
client-config-dir ccd
route 10.15.1.0 255.255.255.0
keepalive 10 120
tls-auth ta.key 0 
cipher AES-256-GCM
auth SHA512
user root
group root
persist-key
persist-tun
log         /var/log/openvpn/openvpn.log
verb 5
explicit-exit-notify 1

my ccd/clientname file

iroute 10.15.1.0 255.255.255.0

route

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         57.128.102.254  0.0.0.0         UG    0      0        0 vmbr0
10.152.0.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
57.128.102.0    0.0.0.0         255.255.255.0   U     0      0        0 vmbr0

client

![alt text]( image url)
https://i.imgur.com/O60qwpA.png

Firewall rules
LAN
alt text

OpenVPN
alt text

** Firewall Log**
alt text

Client routes
alt text

Server Logs
2023-04-28 18:20:17 us=645961 198.x.x.x:51204 [washingtontremblantclient] Peer Connection Initiated with [AF_INET]198.x.x.x:51204
2023-04-28 18:20:17 us=646023 MULTI: new connection by client 'washingtontremblantclient' will cause previous active sessions by this client to be dropped. Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
2023-04-28 18:20:17 us=646029 MULTI_sva: pool returned IPv4=10.152.0.4, IPv6=(Not enabled)
2023-04-28 18:20:17 us=646060 OPTIONS IMPORT: reading client specific options from: ccd/washingtontremblantclient
2023-04-28 18:20:17 us=646081 Options error: in --iroute 198.x.x.x 255.255.255.0 : Bad network/subnet specification
2023-04-28 18:20:17 us=646096 MULTI: Learn: 10.152.0.4 -> washingtontremblantclient/198.60.114.2:51204
2023-04-28 18:20:17 us=646099 MULTI: primary virtual IP for washingtontremblantclient/198.60.114.2:51204: 10.152.0.4
2023-04-28 18:20:17 us=646102 MULTI: internal route 10.15.1.0/24 -> washingtontremblantclient/198.x.x.x:51204
2023-04-28 18:20:17 us=646105 MULTI: Learn: 10.15.1.0/24 -> washingtontremblantclient/198.60.114.2:51204
2023-04-28 18:20:17 us=646160 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2023-04-28 18:20:17 us=646165 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2023-04-28 18:20:17 us=646181 SENT CONTROL [washingtontremblantclient]: 'PUSH_REPLY,route 10.15.1.1 255.255.255.0,route-gateway 10.152.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.152.0.4 255.255.255.0,peer-id 1,cipher AES-256-GCM' (status=1)
WRR2023-04-28 18:20:18 us=285494 washingtontremblantclient/198.x.x.x:51204 MULTI: bad source address from client [::], packet dropped
R2023-04-28 18:20:18 us=356547

SteveITS

@spacebass Is that maybe this?
https://redmine.pfsense.org/issues/13350
Fix was added to System Patches package today.

SpaceBass

@steveits said in Site-to-site up but not routing, can't use a /30 or /24 tunnel?:

https://redmine.pfsense.org/issues/13350

my error is different but that's interesting... I'll apply the patch once it shows in my patches (it does not currently ) and see if it fixes anything

marvosa

@spacebass I see a couple things:

Client:

No tunnel network defined, need to add 10.152.0.0/24 in the "IPv4 Tunnel Network" box
In the "IPv4 Remote networks(s)" section, need to add the network(s) you're trying to access behind the firewall/server, not the peer IP of the firewall/server itself.
The LAN firewall rule of any/10.152.0.0/24 is not needed. This is covered by your any/any or LAN net/any.
For the OpenVPN firewall rules, I would change this to an any/any rule until basic IP communication is established and then refine from there if needed. Also, if you do ever want to restrict access over the tunnel, remember the tunnel network is essentially a transit network... so no traffic will ever be sourced from 10.152.0.0/24. You would need to configure your rules based on the networks on the remote end. Based on your future plans with PFsense (e.g. more tunnels, remote access, etc), you may also want to assign this tunnel to an interface for more control and to keep traffic from matching future rules.

Server:

I'm not seeing how the client knows to route the server-side LAN over the tunnel, so you'll need to push that route to your clients from the server (recommended). You could definite it on the client side, but it's cleaner from the server IMO.
This error is interesting "Options error: in --iroute 198.x.x.x 255.255.255.0 : Bad network/subnet specification" considering I do not see that defined anywhere, but it could clear once the client-side settings are remediated. Although, you may want to review all the client-specific settings in the ccd folder.

SpaceBass

@marvosa said in Site-to-site up but not routing, can't use a /30 or /24 tunnel?:

No tunnel network defined, need to add 10.152.0.0/24 in the "IPv4 Tunnel Network" box

I think there's some misunderstandings and misleading info on the tunnel network for a site to site. It shouldn't be needed unless someone is using a /30 topology. It should get the tunnel network from the server.

Regardless, before yesterday's patch, the tunnel network setting wouldn't accept anything less than a /30.