OpenVPN site-to-site communication issue

Michal944

Hello There,

I never thought I'll need help, but I've been trying to find out what is going on with my site-to-site VPN connection. The problem drives me crazy...

Pfsense_1 -> server
Pfsense_2 -> client

Explanation:
I'm trying to connect site-to-site two offices (please take a look at the screen below):

The Problem:
I'm not able to ping:

From Pfsense_1 to PC2
From PC1 to Pfsense_2
From PC2 to Pfsense_1
From Pfsene_2 to PC1

What I'm able to do:

Ping:

From Pfsense_1 to Pfsense_2 and vice versa

config server file (pfsense_1):

dev ovpns4
verb 1
dev-type tun
dev-node /dev/tun4
writepid /var/run/openvpn_server4.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
local xx.xx.xx.58
tls-server
server 10.0.12.0 255.255.255.0
client-config-dir /var/etc/openvpn/server4/csc
ifconfig 10.0.12.1 10.0.12.2
lport 1196
management /var/etc/openvpn/server4/sock unix
max-clients 10
push "route 172.16.0.0 255.255.0.0"
push "route 192.168.90.0 255.255.255.0"
push "route 10.0.10.0 255.255.255.0"
push "route 10.0.9.0 255.255.255.0"
route 10.0.100.0 255.255.255.0
capath /var/etc/openvpn/server4/ca
cert /var/etc/openvpn/server4/cert 
key /var/etc/openvpn/server4/key 
dh /etc/dh-parameters.1024
tls-auth /var/etc/openvpn/server4/tls-auth 0
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
data-ciphers-fallback AES-256-CBC
allow-compression no
persist-remote-ip
float
topology subnet
explicit-exit-notify 1
inactive 300
client-config-dir /etc/openvpn/ccd

client config (pfsense_2):

dev ovpnc1
verb 1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_client1.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
local 172.168.0.48
tls-client
lport 0
management /var/etc/openvpn/client1/sock unix
remote xx.xx.xx.58 1196 udp4
ifconfig 10.0.12.2 255.255.255.0
pull
route 172.16.0.0 255.255.0.0
route 192.168.90.0 255.255.255.0
route 10.0.10.0 255.255.255.0
route 10.0.9.0 255.255.255.0
capath /var/etc/openvpn/client1/ca
cert /var/etc/openvpn/client1/cert 
key /var/etc/openvpn/client1/key 
tls-auth /var/etc/openvpn/client1/tls-auth 1
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
data-ciphers-fallback AES-256-CBC
allow-compression no
resolv-retry infinite
topology subnet
explicit-exit-notify 1

server routing table (pfsense_1):

default	xx.xx.xx.57	UGS	30	1500	bge0	
10.0.9.0/24	10.0.9.2	UGS	21	1500	ovpns1	
10.0.9.1	link#7	UHS	20	16384	lo0	
10.0.9.2	link#16	UH	19	1500	ovpns1	
10.0.10.0/24	10.0.10.2	UGS	24	1500	ovpns2	
10.0.10.1	link#7	UHS	23	16384	lo0	
10.0.10.2	link#17	UH	22	1500	ovpns2	
10.0.11.0/29	link#18	U	25	1500	ovpns3	
10.0.11.1	link#7	UHS	26	16384	lo0	
10.0.12.0/24	link#19	U	27	1500	ovpns4	
10.0.12.1	link#7	UHS	28	16384	lo0	
10.0.100.0/24	10.0.12.2	UGS	29	1500	ovpns4	<-------
xx.xxx.xxx.xx/30	link#1	U	14	1500	bge0	
xx.xx.xx.xx	link#7	UHS	15	16384	lo0	
127.0.0.1	link#7	UH	2	16384	lo0	
172.16.10.0/24	link#10	U	18	1500	bge1.10	
172.16.10.1	link#7	UHS	3	16384	lo0	
172.16.20.0/24	link#11	U	1	1500	bge1.20	
172.16.20.1	link#7	UHS	5	16384	lo0	
172.16.30.0/24	link#12	U	4	1500	bge1.30	
172.16.30.1	link#7	UHS	7	16384	lo0	
172.16.40.0/24	link#13	U	6	1500	bge2.40	
172.16.40.1	link#7	UHS	9	16384	lo0	
172.16.50.0/24	link#15	U	11	1500	bge1.50	
172.16.50.1	link#7	UHS	13	16384	lo0	
192.168.90.0/24	link#14	U	8	1500	bge2.3	
192.168.90.1	link#7	UHS	10	16384	lo0	
192.168.99.0/24	link#5	U	16	1500	bge4	
192.168.99.1	link#7	UHS	17	16384	lo0	
192.168.255.100	link#7	UH	12	16384	lo0

It's hard to understand what is wrong with this:

Please help me... I've stuck with this for 4 days...

Michal944

@Michal944

CORRECT SCREEN:

viragomann

@Michal944
Are you missing the client specific override??

Michal944

@viragomann I added proper config into Client Specific Overrides.

Common Name: exactly the same as CN client certificate
IPv4 Tunnel Network: 10.0.12.0/24

viragomann

@Michal944
The IPv4 Tunnel Network has to be a usable IP with the mask, e.g. 10.0.12.15/24.
Also you have to specify the client sides LANs at "Remote Networks" in the CSO as well, aside from the server settings.

Michal944

Thank you for you reply @viragomann

I did what you mentioned, but it doesn't resolve the issue:

What I did:
IPv4 Tunnel Network: 10.0.12.2/24 (Pfsense_2 as client)
IPv4 Remote Network/s: 10.0.100.0/24 (Pfsense_2 - office 2)

Restart VPN server
restart client

Screenshot from 2025-01-17 09-04-09.png

The same problem:

jagradang

I was having the same issues a while ago and i just switched to ipsec for my site2site communications. It works so much better for me and I have never had any drop-outs or issues since. Might be worth a consideration.

viragomann

@Michal944 said in OpenVPN site-to-site communication issue:

IPv4 Tunnel Network: 10.0.12.2/24 (Pfsense_2 as client)

I'd rather use a higher IP. 2 is the first in a /24 used for the default routes added by the OpenVPN server. I'm not sure if it's wise to use it for the certain client.

Moreover if more than one client connect to the server you it's necessary to use a high IP in the subnet, since the CSO does not reserve the IP for a client. The server allocates the IP from the lowest one upwards. So at the time of connection, the IP has to be unallocated.

Ensure that in the server is configured for subnet topology. Otherwise you'd have to specify a /30 tunnel network with the network address in the CSO.

To verify if the CSO is applied properly, set the servers log verbosity level to 4 and reconnect the client. Then check the log. Maybe you can post it here.

Michal944

@viragomann.

Ok, I did everything that you mentioned:

client IP changed from 10.0.12.2 to 10.0.12.15 (Pfsense_2)
The routing table changed

from

10.0.100.0/24	10.0.12.2	UGS	29	1500	ovpns4

to

10.0.100.0/24	10.0.12.15	UGS	29	1500	ovpns4

Client Specific Overrides
IPv4 Tunnel Network from 10.0.12.2/24 to 10.0.12.15/24
the log level changed to 6 as well.
log:

Jan 17 10:50:37	openvpn	35043	aws/90.xxx.xx.xx4:15814 UDPv4 READ [108] from [AF_INET]90.xxx.xx.xx4:15814: P_DATA_V2 kid=0 DATA len=107
Jan 17 10:50:37	openvpn	35043	aws/90.xxx.xx.xx4:15814 MULTI: bad source address from client [10.0.100.134], packet dropped
Jan 17 10:50:38	openvpn	35043	aws/90.xxx.xx.xx4:15814 TUN READ [29]
Jan 17 10:50:38	openvpn	35043	aws/90.xxx.xx.xx4:15814 UDPv4 WRITE [53] to [AF_INET]90.xxx.xx.xx4:15814: P_DATA_V2 kid=0 DATA len=52
Jan 17 10:50:38	openvpn	35043	aws/90.xxx.xx.xx4:15814 UDPv4 READ [53] from [AF_INET]90.xxx.xx.xx4:15814: P_DATA_V2 kid=0 DATA len=52
Jan 17 10:50:38	openvpn	35043	aws/90.xxx.xx.xx4:15814 TUN WRITE [29]
Jan 17 10:50:38	openvpn	35043	aws/90.xxx.xx.xx4:15814 TUN READ [29]

The area is the issue: bad source address from the client [10.0.100.134]
I don't know why. Could you help to figure out what is going wrong?

viragomann

@Michal944 said in OpenVPN site-to-site communication issue:

client IP changed from 10.0.12.2 to 10.0.12.15 (Pfsense_2)
The routing table changed

You must not specify an IP in the client settings! I didn't not that you did this before.
The IP is allocated by the server.

Don't matter about the servers routing table. The roue to the client networks point ever to the second IP in the tunnel subnet, 10.0.12.2 in your case. The routing to the real client IP is done inside OpenVPN if the CSO is applied. You can only see this in the log.
You will never see the clients IP in the routing table.

the log level changed to 6 as well.

This gives to much noise. With 4 OpenVPN logs the CSO appliance.

Ensure that you have 10.0.100.0/24 in the server settings and the CSO at "remote networks".

Michal944

@viragomann It works!

I remove the client static IP configuration from the server setup and ping works from both sides.

It was quite difficult but the reason why I didn't read the documentation about s2s OpenVPN connection. Thank you!