IPSEC Rules mystery..
-
OK, most of this stuff all makes good sense to me, but this one has me scratching my head, so figured I would post and see if anyone can shed any light.
I have an IPSEC VPN running between two locations, the A side is in an internal IP range of 10.150.0.0/16, and the B side is in 192.168.77.0/24, and overall everything works. As they are both office locations, and I needed no real rules between the locations, I simply created a rule that permits ALL TCP/UDP/ICMP traffic over the IPSEC tunnel.
You would think this would cover everything, or should I say all normal every day traffic, and overall it seems to. The problem came when I needed to RCP on a unix host across the VPN, then I ended up getting this error:
How can this be, I have a permit ALL TCP rule, but sure enough it's rejecting it over the VPN. So I thought OK, click easy add on the rules and see what I get, so did that and ended up with:
Sure enough, after adding that rule it works! My question is why is this needed, as without it rcp fails! The otehr strange one is I show no hits on the rule after performing transfers, but without the rule in place I can not rcp between two AIX servers.
I see no reason at all this rule should be needed, so wanted to see if anyone could share a clue with me, as clearly I am missing something..
Regards...
-
That traffic is blocked because it's out of state. It's TCP ACK packet for which no SYN-ACK has been seen.
That is usually because there was some big delay somewhere and the state timed out. But it could also be that the SYN-ACK packet took some other route to get back to 192.168.77.5.
https://docs.netgate.com/pfsense/en/latest/firewall/troubleshooting-blocked-log-entries-due-to-asymmetric-routing.htmlI don't think that rule you added actually did anything since it show 0 states and 0 bytes. Applying that may have applied something else that was still pending.
Steve
-
Thanks Stephen for the response. I will take a look at the link you sent me, but I am sure it's not an unapplied change, as it's been running for many months like this. I guess the million dollar question is, can I have an asymetric route through the VPN tunnel? I know they two networks are unreachable internal net's, so it couldn't possibly get going native over the internet..
-
Indeed there would have to be two tunnels for example.
More likely the states had just expired:
https://docs.netgate.com/pfsense/en/latest/firewall/troubleshooting-blocked-log-entries-for-legitimate-connection-packets.htmlBut that doesn't usually indicate a problem. I assume the RCP was failing?
Steve
-
OK, actually this is to a Cisco ASA across the pond, which I plan to have them replace with a PFsense appliance, but for years it's been working OK. Yea, just RCP was failing, and then looking for a reason I found like a dozen rejects in the PFsense logs, so decided OK let's just tell it to add an easy rule to see what happens (as you saw in my earlier message), and then it all just worked.
I can pull it out, and have them try again, see what happens, as clearly this had been working, and just stopped for some reason..
-
A packet capture on the IPSec interface when it's failing would confirm it.
I note those blocked ACK packet are just over 1min apart. I wonder if that is timing out due to something incredibly slow. The TCP opening timeout is usually 30s but that can be changed. If you haven't already you could just set the firewall optimisation to consercative in Sys > Adv > Firewall&NAT. That would prevent it timing out.
Steve
-
Sounds like a good plan, and as suggested I have adjusted it to convervatitive as this firewall has lots of resources with dual E5-2640 v3's, and 64G RAM, using up a little more of it should be just fine..
Thanks...
