Setting Destination On WAN Firewall Rules
-
Hi all,
I have a real basic regarding WAN firewall rules: Suppose I create a simple IPv4 firewall rule on the WAN interface where I'm blocking inbound traffic from an IP alias I created to a given port. Does the destination on the rule have to be set to WAN Address or can it remain as Any? When would one need to choose one over the other?
Thanks in advance for the clarification, I really appreciate it.
-
@tman222 said in Setting Destination On WAN Firewall Rules:
Suppose I create a simple IPv4 firewall rule on the WAN interface where I'm blocking inbound traffic from an IP alias I created to a given port.
Such a block rule is only meaningful if it is followed by a pass-rule, which matches the same traffic.
Otherwise pfSense blocks any access on WAN anyway.Basically you can use any as destination in the most block-rules, since you might want to block access to any.
-
Hi @viragomann - thanks for your reply. Yes, that is actually the specific use case that I had in mind, i.e. a block rule for specific set of IPs, followed by a pass rule. Does the following configuration make sense then:
- The WAN interface block rule can have destination Any
- The WAN interface pass rule that follows (after the block rule) would still have destination WAN Address
Thanks again for your help.
-
@tman222 said in Setting Destination On WAN Firewall Rules:
- The WAN interface block rule can have destination Any
Sure
- The WAN interface pass rule that follows (after the block rule) would still have destination WAN Address
Only if the destination is the firewall itself.
-
@tman222 said in Setting Destination On WAN Firewall Rules:
The WAN interface block rule can have destination Any
The WAN interface pass rule that follows (after the block rule) would still have destination WAN AddressThe block rule would block any traffic, as well to the WAN address.
You would have to exclude the WAN IP in the block rule. E.g. by checking "invert match" and select the WAN address.However, if you allow only a specific destination address and port there is no need for a block rule.
-
@viragomann said in Setting Destination On WAN Firewall Rules:
@tman222 said in Setting Destination On WAN Firewall Rules:
The WAN interface block rule can have destination Any
The WAN interface pass rule that follows (after the block rule) would still have destination WAN AddressThe block rule would block any traffic, as well to the WAN address.
You would have to exclude the WAN IP in the block rule. E.g. by checking "invert match" and select the WAN address.However, if you allow only a specific destination address and port there is no need for a block rule.
Thank you both for the help, I really appreciate it. I'm not quite following the last statement:
However, if you allow only a specific destination address and port there is no need for a block rule.
Did you mean source address?
With a bit more detail, the configuration I had in mind was the following (in order):
- Block rule with source being an IP alias and source port any, destination being any and destination port being 123456 (i.e. whatever the exposed port of the service is)
- Pass rule following Block rule with source being any and source port being any, then destination being WAN Address and destination being port 123456
This would block access to the service for certain IPs contained within the IP alias and allow access to the service for the rest. Does that make sense or would there be a simpler way? I suppose if it were possible to narrow down the allowed source IPs in the Pass rule to only a certain set that would then forego the need of creating the block rule (since the firewall blocks the rest by default).
Thanks again for all your help.
-
@tman222
I see. This makes sense then, as you only want to block certain source IPs.You can also achieve this with a single pass rule:
source IP: "invert match" checked and state the alias.So this rule would allow any, but the IPs in the alias.
-
@tman222 Again, sure. That is how pfBlocker is doing it for me.
-
That clears things up - thanks again @Bob-Dig and @viragomann for all your help.