WAN Default deny rule IPv4 (1000000103) TCP:S
-
Hello, I have been using pfsense for many years and have never had any particular problems, even in the most complex installations.
On the various firewalls there are the most disparate NAT rules and there are ALIAS tables that contain the IPs or FQDNs authorized to access the various services.
For 3 days on ALL the pfSense firewalls that we manage, both direct and customers, some IP addresses have been blocked for no reason.
NAT rules or ALIAS tables have not been touched, firewalls are configured as usual, no changes and no updates have been made. They are all aligned to the latest release 2.4.5-RELEASE-p1.
In the logs for all these IPs I find:
Default deny rule IPv4 (1000000103) TCP: S
There is no way we can unblock these IPs.
I've read tons of articles for similar problems before, but none of the solutions work.
Did the same thing happen to anyone and found a solution?
Thanks to anyone who wants to help me -
@cloudfacilesrl said in WAN Default deny rule IPv4 (1000000103) TCP:S:
some IP addresses have been blocked for no reason.
There is a reason - most likely they are no longer in your alias if that is what was allowing them..
Look at your alias table under diagnostics. Is the IP that is being blocked listed?
I take it these are not just IPs you manually put in, but something that is fqdn and needs to resolve.. This broke down somewhere would be most likely culprit
-
@johnpoz I found that some addresses entered in ALIAS do not appear in the tables, and it happens both with numeric IPs and with FQDNs, this means that pfSense is not writing correctly in the tables, but for what reason and why suddenly on all the firewalls we manage?
-
Well its prob related to this
https://redmine.pfsense.org/issues/9296
I would not mix fqdn aliases with IPs anyway..
-
@johnpoz I read the post. The problem looks similar to mine, but one question remains: these ALIAS tables have been like this for years and have always worked perfectly. I can partially agree for the FQDNs, but why are some numeric IPs not written as well?
In any case, if it is not correct to mix FQDN and IP why is it not reported?
Finally, why did it happen just 3 days ago and on ALL the firewalls we manage?
Things point to a software bug. -
Agreed there is something buggy going on.. Which if you read that thread.. sometimes it works for ages, and then fails.
You should be able to do fqdn and ips in the same alias - I just personally wouldn't do it that way. But it should work. But if something thinks IP 1.2.3.4 should be resolved that could be problematic. So I would never put stuff that should resolve in with stuff that shouldn't resolve was my point.
I am fairly sure your issue is related to that redmine I linked too.
There is mention of killing the filterdns process can correct the problem, or or setting refresh to 30 or 300 specific vs default also helping.
Your not using any of the fqdn in multiple aliases are you?
I personally have never ran into the issue - so have never looked into myself.
I currently only have 1 alias that has a fqdn in, and that is my son's dyndns fqdn.. It hasn't had any issues.
-
@johnpoz at the moment I have separated the ALIAS FQDN from the numeric ones and I have created specific rules for the FQDN ones and at the moment everything seems to work smoothly, however I hope that the developers correct the problem
