Blocking of legitimate traffic
-
I'm running version 2.2.6. I have a rule that has been working for several months, and today it stopped working. The traffic matching this rule is blocked by the default block rule. I found several articles referencing this but none of the fixes were relevant. There is no async routing, no rule order problem, etc. I have tried several things, including reordering rules, removing and building a new rule, and having the pfsense auto-create a rule from the logging screen. Has anyone experienced this? I'm planning on rebooting the firewall this weekend to see if that helps.
-
What flags are logged? What does your ruleset look like (screenshot?) Any packages installed? Traffic between two lan networks or client to internet? mail/http/https/ftp or other traffic? Rules are loading properly? pfctl -f /tmp/rules.debug Is it a firewallrule only or is some portforward rule involved as well? Anything else you can tell whats specific to your situation?
-
The Syn flag is logged. This is a rule that allows anyone on the internal lan out to smtp.gmail.com over tcp/465 (smtps). It is just a firewall rule, no port forwarding. Like I said, this rule has been in place and working for months, and this afternoon stopped working. Installed packages include snort, ftp client proxy, dansguardian (not enabled), pfblocker-ng, mailreport, shellcmd, sudo. The rules are loading properly as far as I can tell. The other rules are still working fine.
-
Snort is always a suspect when traffic doesn't pass properly. But your case where its logged that default-rule blocked the traffic i dont think thats the case.. Also pfBlocker can sometimes block things one you might not expect. But again seems irrelevant. The 'Syn' packet is pretty much the first packet to come in, and should be passed.
Do you have limiters configured?
Tried changing offloading settings for the nics?
Running on bare metal hardware?Im pretty much out of ideas here.. sry..
-
Guessing your LAN clients are probably resolving smtp.gmail.com differently than what the firewall itself got when populating the alias with that hostname. Check Diag>Tables for that alias to check its contents vs. what the clients are connecting to.
Hostnames that may resolve to a different IP every time you do a lookup aren't appropriate for hostnames in aliases, since your clients may get a reply that doesn't match what the alias was populated with. If all your clients and the firewall itself are all using the same DNS server, then it should be fine since the same cache will apply to everything.
-
Thanks, that was it, the DNS problem. Apparently google changed the addresses for that host recently. Both the clients and the firewall are using the same DNS server, but the firewall is not refreshing the alias for some reason. It should be refreshing every 5 minutes but it has not done it in days. I saw an old bug about this, but it was fixed in 2.2. Did this bug re-appear in 2.2.6?
-
Ok, I finally was able to get the pfsense to start looking up its aliases again. I have 8 or so aliases that are configured with FQDNs, and they were all failing. No indication as to why, but there was no lookup traffic leaving the firewall. The way I fixed it was changing the alias lookup interval to something from the default, saving it, then removing the entry (putting it back to default). That was enough to get whatever internal process the kick in the pants it needed to start looking up the FQDNs again. And of course, the smtp traffic in question is allowed out per that rule again.
Thanks to all for your suggestions.