PfBlockerNG and NAT
-
Apologies if this has already been discussed but I wasn't able to find an instructive thread or any similar configuration.
This Pfsense is installed on an APU1d4 for a simple home-server setting. The PfblockerNG in that case is primarily used to deny access to port 80 and port 25 with ban lists and allow it with Geo-IPs and secondary to prevent LAN connection to malicious destinations.
The PfblockerNG defined aliases are selected in the NAT (Port forwarding) source settings:
Several ban lists (Firehol Level3, Emerging Threads etc.) are configured and preferred to be separated, so for each banlist-host exists one (deny-)alias (in Firewall - pfBlockerNG - IPv4).
I also added two Geo-IP (permit-)alias (in Firewall - pfBlockerNG - Geo-IP).As mentioned for each NAT definition I selected the configured pfblockerNG (IPv4 and Geo) aliases as source.
Since every new NAT definition create automatically a FW rule, which is configurable as block, reject or pass (in that order), this is the configuration:
the rules generated by NAT definition with the deny-alias (banlists) inside the source configuration, are configured to block traffic,
the rules generated by NAT definition with the permit-alias (Geo-IP) inside the source configuration, are configured to pass traffic.Appart from that this is what I'm confused about:
Are the Geo-IPs in PfblockerNG prefiltered with lists as mentioned (Emerging-Threads etc.) so there is no need to create block rules? What I mean is, if a pfblockerNG Geo-IP is classed as compromised and blocked by
a ban-list, this could be helpful to check first.I find out that the permit/deny settings (in Firewall - pfBlockerNG - IPv4), as well as custom port and custom protocol in the advanced inbound settings (in Firewall - pfBlockerNG - IPv4) are useless for NAT configuration.
NAT or rather the corresponding FW rule takes it all (custom port, protocol, block, pass). Thus neither the PfBlockerNG general settings permit/deny etc. nor the PfBlockerNG advance inbound settings (protocol, port-alias) has any impact, as long as they are used in NAT (source) definition.One last question concerns the lack to define multiple pfblockerNG Geo-IP configuration for the same country-range (continent). This is not intended in pfblockerNG but it could be useful to permit/deny different ports from different European countries…
-
You can define your own GeoIP aliastables by going to the IPv4/6 Tab and in the Source field, add the full path of the GeoIP ISO code. Click on the blue infoblock Icons which will provide some more details on how to do that… If you are using the same GeoIP ISO in block/reject rules, then use "Alias Native" so that deduplication will not take effect... For Permit/Match rules, there is no deduplication.
If you have a Permit Alias with some GeoIPs, you can place this rule after the Block rules so that any IPs that are malicious can be filtered before the Permit rule takes effect.
So instead of adding the rules on the NAT rule, create the rules in the Floating Tab or on each individual Interface.
Hope that answers your question?
-
Thank you BBcan177. I clarified my post a bit, although you answered my questions. So I will modify my configuration as suggested by you:
@BBcan177:You can define your own GeoIP aliastables by going to the IPv4/6 Tab and in the Source field, add the full path of the GeoIP ISO code.
I have to find that GeoIP ISO code list because a copy pasted table won't be updated.
@BBcan177:So instead of adding the rules on the NAT rule, create the rules in the Floating Tab or on each individual Interface.
This will hopefully solve this inconsistency:
@ui5-5e:NAT or rather the corresponding FW rule takes it all (custom port, protocol, block, pass). Thus neither the PfBlockerNG general settings permit/deny etc. nor the PfBlockerNG advance inbound settings (protocol, port-alias) has any impact, as long as they are used in NAT (source) definition.
I thankfully use Pfsense and PfBlockerNG since years :)
