Site-to-Site OpenVPN problem on 2.7.0, possibly affected by Outbound NAT

jimp

Since it appears to be making it to the VPN there, now you'd check the states, rules, and routing on the other nodes. Make sure the OpenVPN rules allow it on both the serverA and clientC firewalls, and check the states along each leg.

frater

@jimp

I checked the LAN firewall again and noticed an autocreated rule pfB_PRI1_v4 of pfBlockerNG.
I removed it from pfBlockerNG and it started to work.

It was the ClientC network that was able to ping itself, but couldn't be pinged....

I'm still having this when I ping from pfsense clientB to pfsense clientC
I'm getting the answer from the oVPN ip if I don't give a source address:

/root: ping -c2 -S 192.168.1.1 192.168.18.1
PING 192.168.18.1 (192.168.18.1) from 192.168.1.1: 56 data bytes
64 bytes from 192.168.18.1: icmp_seq=0 ttl=63 time=11.856 ms
64 bytes from 192.168.18.1: icmp_seq=1 ttl=63 time=13.479 ms

--- 192.168.18.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.856/12.668/13.479/0.812 ms
[2.7.0-RELEASE][root@pfSense.filmhallen.lan]/root: ping -c2 192.168.18.1
PING 192.168.18.1 (192.168.18.1): 56 data bytes
92 bytes from 10.0.16.1: Redirect Host(New addr: 10.0.16.2)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 f430   0 0000  3f  01 9acd 10.0.16.2  192.168.18.1

64 bytes from 192.168.18.1: icmp_seq=0 ttl=63 time=14.299 ms
92 bytes from 10.0.16.1: Redirect Host(New addr: 10.0.16.2)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 83fc   0 0000  3f  01 0b02 10.0.16.2  192.168.18.1

64 bytes from 192.168.18.1: icmp_seq=1 ttl=63 time=11.461 ms

--- 192.168.18.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.461/12.880/14.299/1.419 ms

jimp

The redirect is sort of expected due to how OpenVPN handles its routing. It usually stuffs a dummy address in the table as a destination just to make sure the traffic gets handed off to OpenVPN and then OpenVPN deals with it from there, but depending on what is hitting what it may end up getting that kind of response.

As long as the traffic goes through it's not a huge concern.

frater

@jimp

I still have a problem pinging 192.168.19.209 even though I can ping it from the network itself.
It's a Windows machine, so I think that's a problem with that firewall not accepting a connection from other LANs

I moved an AP from 192.168.19.20 to 192.168.19.210 and I was able to ping it....
I will revisit this thread if I find out it has to be something else...

jimp

That sounds like a local network config issue on the target system. There are some cases where Windows will only accept inbound traffic from its own subnet unless it thinks it's on a certain type of network. Like if it's set to public vs private but maybe not exactly that.

If you need to fudge that you could setup a hybrid outbound NAT rule on the LAN to make the source of traffic appear to be the local network, but that can break or complicate certain protocols. It's best to fix the local network config on the client system.