Firewall blocking traffic from whitelisted IP
-
@mhank without seeing what rules you created its hard guess what it might be. Are you trying to use an alias for the source IPs? Did you maybe set source port or only tcp?
If using an alias - make sure the IPs are in the table. Diagnostics, tables.
-
-
@mhank what do you have there in your destination IP? That should be your WAN address, and its easier to just use the built in alias for that.
For example here is rule where I allow source IPs.
See the destination is my wan address.
-
@johnpoz
It is a WAN address - we are running a public IPv4 subnet behind the firewall.
We haev apx. 200 rules and they all works perfect (and have done so years) - it is only this specific IP causing issues. -
@mhank ah so your running public IP space behind pfsense..
Or your natting to IPs behind pfsense, and the IP resides on pfsense wan interface?
If you have public IPs behind pfsense, the rule should be to the specific IP behind, not the wan address.
If your natting, you would need a port forward, and then the rule on the wan would be to the IP your natting too.
You have your source port hidden, but the rule your blocking to 5060 show source is 5060, what do you have in the source port for that rule?
-
@johnpoz
That is correct- and that is how it is setup - and woks on the 199 other rules - just not the specific IP. -
@mhank see my edit, if you had the source port different than what is show as the 5060 in your block then no the rule wouldn't trigger and the default deny would hit. You have source hidden in the rule you posted. Even if the IPs match
What is correct, your natting or you have public IPs actually behind pfsense?
-
@johnpoz public IPs behind the firewall
Source ports are any to any
-
@mhank if the rule was matching then it would be allowed. So something is not matching.. Are you using specific IPs in the alias(es) or networks. Maybe the IP is outside the network your allowing either from source or destination.
As you say 199 other similar rules are working.. So there is something we are missing for why your allow rule is not triggering.
-
I fully agree - but what?
even when using the "easy add rule" directly from the firewall - it still wont work -
@mhank when you add a rule, its possible the rule is not placed correctly.. Where some other rule blocks it.. But that rule shouldn't be the default deny..
You don't have your own rule named default deny do you? Doesn't look like it because of the ID there ending in 103 pretty sure is the default deny ID..
Without looking at your full rule set and understanding the details of your specific source IP and what is in the tables its hard to guess what could be causing it.
Just thinking off the top of my head here.. Lets say you had a port forward setup, these are evaluated before rules.. So if you had a forward setup that triggered, but there was no actual rule that matched the port forward. Then it would hit the default deny and fail.
But if your IPs are just routed public, you should have no port forwards setup. Do you have any port forwards setup?
For example if I had a port forward that trigged on destination port 5060, and suppose to send it to say 192.168.1.10.. And you don't have a rule that allows traffic to 192.168.1.10 that would fail and hit your default deny and be logged.
So you could put rules in all day long for specific source IP to be allowed to say 1.2.3.4 behind your firewall. But the port forward would cause it to fail. Because it sees the traffic and says hey suppose to forward to 192.168.1.10..
Just a guess here, but would be curious if you do have any port forwards.
