pfsense doesn't block port on wan
-
Hello,
I am using pfsense 2.4.4. We have a problem. Pfsense doesn't block requests from source ip address when "Destination" is selected as "WAN Address in WAN rules".
For example:
Action Block:
Interface: WAN
Address Family: IPv4
Protocol: TCP
Source: XX:XX:XX:XX
Destination: WAN AddressPfsense can only block it when Destination is selected "Any". However I have used pfsense 2.4.3p1 and I have used Destination as WAN Address, and it worked well. But in 2.4.4 version this function doesn't work. I think this is bug and it makes WAN Address in Destination meaningless.
-
Then you are doing something wrong. How are you testing?
-
This post is deleted! -
@emammadov said in pfsense doesn't block port on wan:
For example, I crate a new nat rule, source address (invert match) xx:xx:xx:xx and destination destination "wan address", Redirect target IP (192.168.1.2), Redirect target port - 80 and save. In Rules / Wan, I choose Action "Block".
I then begin to open webpage from different ip address and it opens. However if I change Destination address to "Any", it blocks.Well if you use NAT to rewrite the destination address then it's obviously no longer your WAN address when the rules get evaluated.
-
-
For example, I crate a new nat rule, source address (invert match) xx:xx:xx:xx and destination destination "wan address", Redirect target IP (192.168.1.2), Redirect target port - 80 and save. In Rules / Wan, I choose Action "Block".
I then begin to open webpage from different ip address and it opens. However if I change Destination address to "Any", it blocks. -
have an Alias and it contains some ip addresses. I create a new rule in WAN, and choose my alias as source address and destination "WAN Address": and action block and save. I lift this rule to the top of page and save. It don't block requests from these ip addresses though.
-
-
Post your entire WAN rule set and tell us exactly what you are doing to test it.
I just tested this and your original assertion (that block rules to WAN address do not work) is incorrect. It works fine.
It is highly unlikely that you will discover a "bug" in port forwarding or the implementation of pf. It is almost certainly a misunderstanding or misconfiguration.
-
Firewall / NAT / Port Forward
For example, I created a new NAT rule.
Destination port range: 3389
Redirect target IP: 192.168.2.82
Redirect target port: 3389
SaveFirewal / lRules / WAN
I can access this server from everywhere. Then I create a new WAN rule:
Action Block
Source address: 5.191.18.8
Destination: WAN address
Save
I lift this rule above the automatic created nat rule. Save. Eventually it should block access from this ip addres, but it doesn't block. If I choose "Any" in Destionation, then it blockes requests from this ip addres.
-
Nope. NAT has already happened before the firewall rules are consulted.
Block source 5.191.18.8 to destination 192.168.2.82 port 3389
If you were to, say, ping WAN Address from 5.191.18.8 with that existing configuration you will see that traffic blocked in the firewall logs because that traffic does not match the NAT so NAT is not performed and Destination WAN Address will match.
Destination Any matches 192.168.2.82 as well as WAN Address so the traffic is blocked even though NAT has happened first.
-
I can show you exactly when I give teamviewer id to you. Do you have a teamviewer program in your computer?
-
I just explained it all.
No, I won't teamviewer into your computer.
-
What I mean is: I have an Alias that should be blocked by pfsense.
In WAN rules, Alias is in the top of page, above all the rules. I have chosen to block all requests from this Alias. Destination address is "WAN Address". It doesn't block requests from this Alias. But if I choose "Any" in Destination, then it blocks all requests from this Alias. That's what I mean. Because I have used this rule in 2.4.3p1 and it used to work. Please do the same steps in your pfsense and you will see what I mean.
-
I explained exactly what is going on based on what you have posted.
I cannot explain to you that which is not shown. You are posting rules/screen shots for one thing, getting a complete explanation, then saying something else isn't working.
Does the table in Diagnostics > Tables contain the IP addresses you expect to be blocked?
Please show everything about that alias and the rules in question.
-
Today I will have a screen recorder and will attach the link here for your review.
-
Just post the rule sets, the contents of the alias, and what you think should be happening. Not going to watch movies.
-
Firewall / Rules / WAN Destionation is "any"
Alias
Firewall / NAT / Port Forward
Firewall / Rules / WAN
Port check
Firewall / Rules / WAN Destionation is "WAN Address"
Port check
When Destination in WAN Rules is "any", pfsense blocks, but if Destionation is "WAN Address", pfsense doesn't block.
-
@emammadov said in pfsense doesn't block port on wan:
When Destination in WAN Rules is "any", pfsense blocks, but if Destionation is "WAN Address", pfsense doesn't block.
That is, as already explained above, because the NAT port forward has already changed the destination address.
Btw. opening RDP to the WAN is plain stupid, use a VPN for remote administration.
-
@grimson But it has been worked in 2.4.3p1 version.
-
No it didn't - atleast not the way you think it was..
-
Then, you mean, if I want to block source ip, I have to choose "any" in Destination address and if I allow source ip to my pfsense, then i have to choose "WAN Address" in Destination address, right?
-
Post your rules HOW they are set, and what is not happening.. Lan rules have ZERO to on what happens inbound to the WAN..
Your running pfblocker - and you have rules in floating that block traffic.. If so then they could be blocking access to your port forward..
Unless you are using a VIP address on your wan, port forward will always be to wan address - which is the default. It will auto create the firewall rule for you by default. If you to limit to a specific alias as source that has zero to do with the dest address and can be be used in your port forward rule.
