Blocked traffic missing in Log
-
Hi everyone,
let's make this issue short: I have an firewall-issue on my working IPsec connection. For no reason traffic from the remote-network to my pfSense is being blocked - that's a fact. I checked wireshark-dumps on every possible corner and i am pretty sure of this. Traffic from my pfSense to the remote-network is working!
No let's get crazy:
- If i have traffic flowing from the pfSense to the remote-network i can also connect from the remote-network to the pfSense. Even a few seconds after that. This is definitely releated to states - so far explainable for me.
If i reset all states / or restart pfSense and make a new clean connection (meaning close IPsec connection on remote-network as pfSense is responder only) i still can't connect from remote-network to pfSense.
The issue: I can't find any traffic being blocked regarding to my Firewall-System Logs. Why? I set the filter to 9999 entries but still nothing releated to my vpn-connetion.
No things get crazy: The only thing that makes a connection from the remote-network to pfSense possible is setting an allow-all rule on WAN-Interface! Why? This shouldn't be releated to WAN-Interface in any way. This connection should appear on IPsec-Interface.
As i can't see why pfSense is blocking this and why only a allow-all rule on WAN-Firewall Tab helps i need your help.
Thanks!
-
You've done packet captures at the remote end of the tunnel to ensure traffic is making it out of the remote end?
You've done packet captures at the WAN interface on the pfSense box and seen no traffic there?What's in between your pfSense WAN and the remote system (besides "the internet")?
-
Probably blocking the ESP traffic, or UDP 4500 if NAT-T. Usually because you disabled auto-added VPN rules and didn't add any manually, or at times because you're not bound to a specific WAN (like using an IP alias on localhost) where it can't know which WAN is in use and you need to manually add rules.
-
What's in between your pfSense WAN and the remote system (besides "the internet")?
Only the "Internet" - It's strict WAN to WAN nothing between.
@cmb:
Probably blocking the ESP traffic, or UDP 4500 if NAT-T. Usually because you disabled auto-added VPN rules and didn't add any manually, or at times because you're not bound to a specific WAN (like using an IP alias on localhost) where it can't know which WAN is in use and you need to manually add rules.
Thanks, indeed i disabled auto-added VPN rules. Can you explain me what they are doing? I am honestly afraid of them because i have different IPSec-Connections which should not be able to communicate with each other :-)
That's why i disabled them.
Thanks for your feedback.
-
Auto added rules for anything on pfSense are "rules automatically added when you enable different things". If you disable the auto adding, then you need to add equivalent rules manually. It's easier to let the tool (pfSense) do it. I'd reenable the auto added rules for VPN, reboot the pfSense box to ensure you are starting clean and then check to see if you have cross talk on your different IPSec connections (did you try this before disabling the auto add?)
-
@mer:
Auto added rules for anything on pfSense are "rules automatically added when you enable different things". If you disable the auto adding, then you need to add equivalent rules manually. It's easier to let the tool (pfSense) do it. I'd reenable the auto added rules for VPN, reboot the pfSense box to ensure you are starting clean and then check to see if you have cross talk on your different IPSec connections (did you try this before disabling the auto add?)
You are right, everything is now working the ways its supposed to be. Topic finished, thanks!
-
Good to hear that it's working. Sometimes it's better to not overthink things; the guys working on pfSense have pretty good "out of the box" behaviour.
-
The auto-added IPsec rules allow only the outer portion of the VPNs to pass (UDP 500 and 4500 and ESP). The inner traffic is controlled by the firewall rules on the IPsec tab (and having to match the SPD, which is probably another control against talking in between in your case).