OpenVPN site-to-site traffic only in one dirrection

[ppiorunski]

First let me say that I very much like the functionality of pfSense. We use it extensively over 8 routers-firewalls in the company.

Recently i have been struggling with establishing a site-to-site OpenVPN connection, I think that I miss something obvious. I have some other set up's where it functions correctly i don't see anything obvious that is different.

I have been using the pfSense book example to set-up certificate based site-to-site.

I use 11.22.31.0/24 as OpenVPN Tunnel Network. Server side LAN is 10.60.0.0/16 and 192.168.250/24 , client side LAN 10.70.0.0/16

Server routing related config:

Server Client Spcefic Override:

Client routing related config:

I can ping both ways the tunnel IP.

From server - 11.22.31.1

PING 11.22.31.2 (11.22.31.2): 56 data bytes
64 bytes from 11.22.31.2: icmp_seq=0 ttl=64 time=70.176 ms

From client 11.22.31.2

PING 11.22.31.1 (11.22.31.1): 56 data bytes
64 bytes from 11.22.31.1: icmp_seq=1 ttl=64 time=86.374 ms

From Client I can ping LAN IP of Server pfSense:

PING 10.60.255.1 (10.60.255.1): 56 data bytes
64 bytes from 10.60.255.1: icmp_seq=0 ttl=64 time=70.285 ms

From Server reverse is not possible:

PING 10.70.0.210 (10.70.0.210): 56 data bytes

I can see packets on correct interface:

tcpdump -i ovpns3 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpns3, link-type NULL (BSD loopback), capture size 65535 bytes
11:41:33.575865 IP 11.22.31.1 > 10.70.0.210: ICMP echo request, id 65152, seq 51, length 64
11:41:34.595753 IP 11.22.31.1 > 10.70.0.210: ICMP echo request, id 65152, seq 52, length 64
11:41:35.597636 IP 11.22.31.1 > 10.70.0.210: ICMP echo request, id 65152, seq 53, length 64
11:41:36.599099 IP 11.22.31.1 > 10.70.0.210: ICMP echo request, id 65152, seq 54, length 64
11:41:37.600601 IP 11.22.31.1 > 10.70.0.210: ICMP echo request, id 65152, seq 55, length 64
11:41:38.602443 IP 11.22.31.1 > 10.70.0.210: ICMP echo request, id 65152, seq 56, length 64

Nothing on the other side.

Firewall on OpenVPN interface is set to allow all on both:

There is correct entry in the routing table:

10.70.0.0          11.22.31.2         UGS      ovpns3

I must be missing something obvious. But I have been staring at it for days with no luck.

thanks in advance

[Rico]

Adding the Client Side LAN in the Server 'IPv4 Local networks' Box is wrong.
And your tunnel network is not RFC1918 which is also bad. Only use private address space for private networks to avoid strange problems in general.

-Rico

[ppiorunski]

Hi Rico,

Yes I know it's not RFC1918, I plan on changing all of the once I replace previous OpenVPN infrastructure.

I have tried in the past with and without Client Side LAN in the Server 'IPv4 Local Networks', it does seem weid to me but it's what i got from the "pfsense book" example:

IPv4 Local Network:
Enter the LAN networks for all sites including the server: 10.3.0.0/24, 10.5.0.0/24, 10.7.0.0/24)
https://www.netgate.com/docs/pfsense/book/openvpn/site-to-site-example-configuration-ssl-tls.html

Thanks for reading in help.

[Rico]

In your CSO, have you double checked to select the right OpenVPN Instance and use the correct Common Name (Client Cert name 1:1)?
Please post your Server Side routing table.

-Rico

[ppiorunski]

CFO on the server:

From the client config:

Routing tables

Internet:
Destination        Gateway            Flags      Netif Expire
default            removed external   UGS      pppoe0
removed external   link#12            UHS         lo0
removed external   pppoe0             UHS      pppoe0
10.10.0.0          11.22.35.1         UGS      ovpnc1
10.20.0.0          11.22.35.1         UGS      ovpnc1
10.30.0.0          11.22.35.1         UGS      ovpnc1
10.41.0.0          11.22.35.1         UGS      ovpnc1
10.60.0.0          link#10            U      re1_vlan
10.60.255.1        link#10            UHS         lo0
10.70.0.0          11.22.31.2         UGS      ovpns3
10.99.0.0/17       11.22.35.1         UGS      ovpnc1
10.99.128.0/17     11.22.35.1         UGS      ovpnc1
11.22.31.0         11.22.31.2         UGS      ovpns3
11.22.31.1         link#15            UHS         lo0
11.22.31.2         link#15            UH       ovpns3
11.22.35.1         link#13            UH       ovpnc1
11.22.35.2         link#13            UHS         lo0
11.22.36.0         11.22.35.1         UGS      ovpnc1
11.22.37.0         11.22.35.1         UGS      ovpnc1
removed external                      UGS      ovpnc1
removed external                      UGS      ovpnc1
removed external                      UHS         lo0
removed external                               pppoe1
removed external                               pppoe1
removed external   link#12            UH       pppoe1
localhost          link#6             UH          lo0
removed external                      UGHS     pppoe0
removed external                      UGHS     pppoe0
192.168.2.0        link#1             U           re0
192.168.2.2        link#1             UHS         lo0
192.168.80.0       link#9             U      re1_vlan
192.168.80.1       link#9             UHS         lo0
192.168.90.0       11.22.35.1         UGS      ovpnc1
192.168.142.0      link#2             U           re1
Youngs3            link#2             UHS         lo0
192.168.144.0      11.22.35.1         UGS      ovpnc1
192.168.250.0      link#8             U      re1_vlan
192.168.250.1      link#8             UHS         lo0
removed external   link#11            UH       pppoe0

Thanks

[Rico]

Looks okay to me.
Anyway, I would:

• wipe 10.70.0.0/16 from the Server Side Local network Box
• use a proper RFC1918 tunnel network
• wipe the Tunnel Network and Remote network box from the Client side because these settings are pushed by the Server anyway.

-Rico

[ppiorunski]

It's now resolved.
It was none of the above.

Changing tunnel network to be /30 resolved it.
I tested it afterwards:
switching to /24 works in one direction
switching to /30 full routing in both directions

It shouldn't happen. I did try on a fresh installs of pfsense.

Piotr