Site to site - no access to subnets behind client endpoint

[bert64]

I am trying to setup a site to site openvpn link between a pfsense firewall and a linux host.

I'm using 192.168.73.0/29 for the interlink, the pfsense firewall is acting as server and has 172.16.254.0/24 behind it while the linux host has 172.16.101.0/24 behind it.

From the linux server i can reach hosts within 172.16.254.0/24, and hosts in this subnet can reach the tunnel ip of the linux host (192.168.93.2), but neither the pfsense firewall nor the host behind it can reach anything in 172.16.101.0/24.

A route entry exists on the pfsense firewall, and tcpdump on the openvpn interface shows traffic going out, but a tcpdump running against the tun interface on the linux host shows no traffic reaching it…
The rules on the pfsense are now set to allow everything on the openvpn interface but still to no avail, so i'm stumped... Any suggestions? I'm probably missing something stupidly obvious.

[ahydle]

Have you tried rebooting your firewalls? I was about to post a question here because I assume there is some sort of timer that is messing with my vpn connections. I can usually ping through the tunnel interface but not the LAN at first. If I wait a while (several hours) or reboot things start working. I can see the correct route and the vpn connection is up but if I ping from the LAN interface (or a machine behind LAN) I can see the traffic going into the tunnel but dont see it arriving on the other side. I usually also see a message stating bad source address from client [x.x.x.x], packet dropped

[bert64]

Tried a reboot, but no change…

From the pfsense:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpns5, link-type NULL (BSD loopback), capture size 65535 bytes
22:06:25.727660 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 7, length 64
22:06:26.727671 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 8, length 64
22:06:27.727676 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 9, length 64
22:06:28.727686 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 10, length 64
22:06:32.620809 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 1, length 64
22:06:32.920929 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 1, length 64
22:06:33.621049 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 2, length 64
22:06:33.921304 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 2, length 64

And from the remote end Linux host:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
17:36:32.798639 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 1, length 64
17:36:32.798655 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 1, length 64
17:36:33.799001 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 2, length 64
17:36:33.799024 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 2, length 64

It only sees the traffic to the tunnel ip, not any of the traffic destined for hosts beyond