I had previously set up a site to site vpn with two pfsense boxes with my in-laws. This connection remained stable for months. I had followed this tutorial… https://www.youtube.com/watch?v=8f13lfnEKY8
I just recently needed to set up a second site to site between my home and a site b location ( i have since removed the in-laws connection / config from my primary site) I was having issues passing traffic from site b to site a so I reviewed Tom’s tutorial and noticed an additional step showing assigning the openvpn to an interface. This was not necessary in the tutorial I linked above. I was curious if anyone knew if something changed in pfsense for this to be a necessary step.
Lastly… I have hit a wall. I have spent time on and off for 3 weeks trying to fix this site to site vpn and I cannot figure out the cause of my failure… but basically at site b i am able to access all of my site a resources… devices on site a lan etc… i can ping boxes on site a from boxes on site b. … However I am unable to ping devices at site b from site a. I am unable to access the web gui of a device at site b from site a.
Strangely enough I am able to vnc into a box on site b from site a… this and the site b pfsense box is only traffic that is able to make it from site a to site b. I have no idea why port 5900 is able to connect from a to b but nothing else…
Hmm sounds like you have a rule issue if you can not get back and forth across the VPN with all protocols but can with some such as VNC, confirm that the rule you created for the VPN allows more than just TCP.
You can see the states pic which is the site b rule states… you can see in there the vnc connection as well as a failed ping test that showing sent packets but not received.
I’m late to the party. I think you created an asymmetric route scenario.
This by reading your description of what is happening and by looking at he syn and fin notices in the logs.
I think you need to analyze your network in detail to understand what is happening.
Because you are using policy based routing. (This is the reason you need to assign the VPN interface, so you can send traffic to it from a rule) I doesn’t show on the routing table as normal routes do.
TCP packets should be able to find their way back but somehow are bypassing one of the firewalls. Because the firewall is keeping track of the TCP packets in the state table and never sees the response, it Kills the state when it times out . Then the original machine sends another packet , but because it arrives outside a state, it looks like a man in the middle attack and gets dropped. That’s the fin and syn Logs you are seeing.
Ping icmp are not TCP nor UDP and doesn’t create a state the same way TCP.
Search for asymmetric routes in the pfsense book.
Use the pftop utility on both firewalls to see where it is being dropped.
Do you have same subnetwork addresses or overlapping ranges on both sides.
Check you network masks on both sides. Check if you have inconsistent Network masks for the same subnetwork. Or In IP assignation on any interface
Is the network inside the VPN conflicting or overlapping with one of you lan subnetwork?
Sorry, I’m falling asleep. I hope I’m making enough sense.
