VPN/OpenVPN/Servers/Peer to Peer (SSL/TLS) [site to site] wrong route?

Summer

Pfesense 23.05.1 as OPENVPN server:
ipv4 TUNNEL NETWORK: 10.0.0.0/24
Ipv4 Remote NETWORKS: 10.1.1.0/24 (site B)
IPV4 LOCAL NETWORK: 10.2.2.0/24 (site A)

Opvn client ROS 7.11 get connected and can ping local pfsense lan 10.2.2.1.
But pfsense cannot ping remote 10.1.1.1.

Pfsense route is :
Destination Gateway Flags uSES
10.1.1.0/24 10.0.0.2 ugs 15

The gateway IP is the ovpn client which is 10.0.0.2.
Ping 10.0.0.2 from pfsense box is OK.
Ping the 10.1.1.1 from pfsense box fail.

What could be missing?

Summer

Let's start with a check of the route on pfsense:

/root: route -n get 10.1.1.1
route to: 10.1.1.1
destination: 10.1.1.0
mask: 255.255.255.0
gateway: 10.0.0.2
fib: 0
interface: ovpns5
flags: <UP,GATEWAY,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 1500 1 0

This would mean another problem is present if ping fail?

Summer

Then looking at routes:

netstat -rWn

Destination        Gateway            Flags   Nhop#    Mtu      Netif Expire
10.0.0.0/24       link#18            U          10   1500     ovpns5
10.0.0.1          link#18            UHS        12  16384        lo0
10.1.1.0/24      10.0.0.2          UGS        15   1500     ovpns5

But ping 10.1.1.1 keep running without any reply, it doesn't say if Host is down or not it just run without output.

Summer

From pfsnse:

traceroute 10.1.1.1
traceroute to 10.1.1.1 (10.1.1.1), 64 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
etc

from ovpn client

/tool/traceroute 10.2.2.1
Columns: ADDRESS, LOSS, SENT, LAST, AVG, BEST, WORST, STD-DEV
#  ADDRESS       LOSS  SENT  LAST    AVG   BEST  WORST  STD-DEV
1  10.0.0.1     0%       5  12.5ms  12.7  12.5  12.9   0.2    
2  10.2.2.1  0%       5  12.3ms  12.5  12.3  12.6   0.1

viragomann

@Summer said in VPN/OpenVPN/Servers/Peer to Peer (SSL/TLS) [site to site] wrong route?:

Ping the 10.1.1.1 from pfsense box fail.

Which device is this? Is it the router?

Is the client router the default gateway on devices at site B?

/root: route -n get 10.1.1.1
route to: 10.1.1.1
destination: 10.1.1.0
mask: 255.255.255.0
gateway: 10.0.0.2
fib: 0
interface: ovpns5
flags: <UP,GATEWAY,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 1500 1 0

This would mean another problem is present if ping fail?

This is just, what pfSense sees, but for proper routing within OpenVPN, you need to configure a client specific override for the remote client. Did you do that?

Summer

@viragomann thanks for the reply:

@viragomann said in VPN/OpenVPN/Servers/Peer to Peer (SSL/TLS) [site to site] wrong route?:

Ping the 10.1.1.1 from pfsense box fail.

Which device is this? Is it the router?

This is an host that is currently up and running in SITE B.

@viragomann said in VPN/OpenVPN/Servers/Peer to Peer (SSL/TLS) [site to site] wrong route?:

Is the client router the default gateway on devices at site B?

Yes it is as connection from 10.1.1.1 to SITE A are successfull

@viragomann said in VPN/OpenVPN/Servers/Peer to Peer (SSL/TLS) [site to site] wrong route?:

This is just, what pfSense sees, but for proper routing within OpenVPN, you need to configure a client specific override for the remote client. Did you do that?

Can you please advice me on what exactly should be the override, pfsense got a route for traffic to SITE B LAN over ovpn client TUNNEL IP and it seems already active.

I've read here: https://docs.netgate.com/pfsense/en/latest/troubleshooting/openvpn-iroute.html
now on client two routes to site A are present. With DEFAULT on client specific override it works!
Thank you!

viragomann

@Summer said in VPN/OpenVPN/Servers/Peer to Peer (SSL/TLS) [site to site] wrong route?:

I've tried with: server conf: advanced:

push "route b.b.b.0 255.255.255.0";

and client override:

iroute b.b.b.b.0 255.255.255.0;

Just forget push and iroute commands on pfSense. pfSense offers special field in the GUI for this to achieve.

In the server settings enter the client sites local subnet into the "Remote networks" box.
And once again enter it in the CSO at "Remote networks".

Ensure that the CSO name is equal to the client certificates common name and that the CSO is applied properly.

Summer

@viragomann it's working without advanced options.
thank you!