Methods to bring down interface/stop WAN traversal

tinfoilmatt

A maintenance task requires pfBlocker to be temporarily disabled. During this time we don't want any traffic whatsoever to be able pass WAN, in or out. What are some of the ways this could be accomplished? Manually mark interface down? Temporary top-of-ruleset default-deny?

Is there any way to do this while maintaining pfSense system connectivity to WAN but otherwise block all non-pfSense generated traffic from passing?

bmeeks

The pfctl utility used within your own script would be the solution. Here is a link to the official FreeBSD docs on the utility: https://man.freebsd.org/cgi/man.cgi?pfctl.

The utility allows you to manipulate the firewall rules. There is no GUI support nor any type of hand-holding for this, so you would be on your own.

You should also consider the potential impact of blocking all input/output traffic on built-in pfSense tools such as dpinger, the gateway monitoring daemon. That could trigger dpinger to believe the WAN connection is lost and it would initiate its configured alarm actions. A better choice might be a set of rules that allows ICMP traffic (for dpinger) but blocks say TCP and UDP for your maintenance window duration. But this could also disrupt any established states for currently connected clients (blocking all input/output traffic on the WAN). That could lead to issues. Why is it so critical that the WAN be disconnected when pfBlockerNG is not in service?

stephenw10

You could create a floating quick rule to block everything inbound on all interfaces. Put it at the top of the floating rules list.

Traffic from the firewall itself would be allowed out but nothing would be allowed in so no traffic could pass from other interfaces.

Then just disable that rule when you're finished.

Of course you could easily lock yourself out with such a rule.

Steve

tinfoilmatt

@bmeeks @stephenw10 appreciate both your guys' responses very much.

Bill, specific task is to actually rebuild all pfB files. this can be accomplished by unchecking the "Enable" and "Keep Settings" boxes from Firewall / pfB / General, clicking save, re-checking both boxes, and finally 'Force Update | Reload'ing'. But we want to ensure no unbound caching/DNSBL (or any IP filtering to the limited extent applicable in our case) leak.

duly noted as far as Gateway Monitoring alert/action and other points are concerned. thanks for mentioning. pfctl appears to be the sought-after utility.

however, to Steve's suggestion—it'd actually be preferable to maintain pfSense system connectivity so that the pfB 'Update | Reload' can complete before LAN/transit traffic resumes.

tinfoilmatt

@stephenw10 if i put such a rule—deny IPv4/v6, Any protocol, Any source, Any destination— on the WAN interface specifially (not Floating), the system including DNS Resolver/unbound and installed packages including pfB will all still maintain their connectivity?

stephenw10

If that rule was inbound only (just on the WAN firewall tab) it would only block connection coming into the WAN from external sources. So only if you have port forwards in place to in internal hosts.

If the rule was blocking in any direction (floating on WAN only) it would would block almost all traffic including traffic from the firewall itself.

SteveITS

@cyberconsultants
To avoid lockout I'd try to set up rules on each interface, or maybe an interface group if you have a lot. Something like:

allow from my_pc to pfsense:443
allow from my_pc to pfsense:22
reject from LAN Subnets to any
(rest of LAN rules)

Then client devices can't resolve DNS or get past pfSense.