pfctl not disabling the firewall for more than 1 second (2.4.5)

[da_667]

Hey there! Long time support of pfSense, first time caller.

I recently downloaded pfsense 2.4.5, for use in my home lab. I have it running in an ESXi server. I use the pfSense-AMD64 ISO to install pfsense to a VM. This virtual machine is connected to 3 virtual switches, and independent local/RFC1918 networks:

"WAN" network - 10.0.0.0/24, pfSense gets a static DHCP allocation, and is at 10.0.0.206
"LAN" network - 172.16.1.0/24, with pfSense statically assigned 172.16.1.1, with a DHCP scope of 172.16.1.10-172.16.1.254
"OPT1" network - 172.16.2.0/24, with pfSense statically assigned 172.16.2.1, with a DHCP scope of 172.16.2.10-172.16.2.254

I perform the installation and the configure network interfaces song and dance from the ESXi web console. Once IP addresses, subnets and DHCP are all set up, I use the webconfigurator. So the first-time setup is NOT done, and I DO NOT have access to the web interface.

Now, I'm well aware that by default there is a firewall rule that blocks RFC1918 addresses from interacting with the WAN interface. This is a problem, since the WAN network is located in a 10.0.0.0/24 network, and I want my workstation, located at 10.0.0.3) to be able to log in via the WAN interface. I've done this before with previous versions of pfSense multiple times. My go-to method, backed up by some google searching involves two things:

opening up a command shell (option 8) and running

easyrule pass wan tcp 10.0.0.3 10.0.0.206 443

followed by

pfctl -d

This would enable me enough access to do the first-time setup wizard, THEN, once the wizard completes (and I am unable to UNCHECK the Block RFC1918 addresses on the WAN interface option), the pf service re-enables, and the easyrule allows me to keep logging in to the webconfigurator using the "WAN" IP address for pfSense from JUST my workstation's IP address.

According to netgate's own documentation, these ARE considered accepted methodd of gaining access to the webUI.
source: https://docs.netgate.com/pfsense/en/latest/usermanager/locked-out-of-the-webgui.html

The problem I am running into is that running pfctl -d is, effectively doing nothing. I'm not sure why, or how, but something is starting the pf/firewall services IMMEDIATELY. How do I know that? I run pfctl -d, followed IMMEDIATELY by pfctl -e to disable then re-enable the firewall, and I am informed that "pf is already enabled"

I understand that there are automated processes that occasionally re-enable pf, and understand that pfctl -d is temporary, but this is... kinda ridiculous. pf gets re-enabled in a matter of seconds.

I know is not a network problem in my home because running

tcpdump -i vmx0 port 443

( vmx0 is the "WAN" interface) shows that the port 443 traffic is making it to my VM. I can further confirm that using option 10 on the pfsense console to tail the filter.log file confirms that firewall rule 12000 (the RFC1918 block rule) is logging blocks for the HTTPS traffic from 10.0.0.3

I know that I didn't accidentally hit "do you want to using HTTP for the webconfigurator" wasn't accidentally selected because the output of

netstat -anp tcp | grep 443

confirms that the web interface is listening on port 443 on ALL available interfaces.

I need an effective way to temporarily disable pf so that I can access the webconfigurator on the WAN interface, and the official method isn't working. I need to know if this is a weird bug I've stumbled across, and/or if there are alternative ways of disabling the pf service from the command line to give me more time to actually disable RFC1918 blocking on the web interface.

I was brainstorming a work-around to this problem, and wanted to get the opinion of netgate and/or forumgoers in general if this is a viable work-around or long-term solution to my problem:

I noticed that the filter log references the RFC1918 address rule as rule "12000". Is this firewall rule number consistent between ALL pfSense installations?

What I was thinking about doing is running something like:

cat /tmp/rules.debug | egrep -v "12000" >> /tmp/rules.tmp.debug

followed by

pfctl -f /tmp/rules.tmp.debug

to get pf to reload the firewall rules WITHOUT RFC1918 blocking. Is this a viable work-around? Is it temporary? And is it standard and repeatable (e.g. does the rule number of 12000 for the RFC1918 firewall change? Is it the same between installs? Has it remained the same between patch versions?)

If there is any troubleshooting data you require, or any feedback you guys can offer, I would appreciate it.

[jimp]

pfctl -d is very temporary. Any filter reload will end up re-enabling pf. You shouldn't rely on that for anything substantial.

What you probably want is something like pfSsh.php playback enableallowallwan which will do what you need, then you can fix the WAN rules once you are through the wizard.

[NogBadTheBad]

Handy, I've always used pfctl -d when playing about with VMware pfSense VMs

[da_667]

@jimp This resolved my issue! Thank you so much for your response.

I'd like some clarification on something, however.

I had tried using option 12 to use the enableallowallwan play command. This is what I tried doing:

select option 12

enableallowallwan

exec

and then the php shell would throw an error:

Parse Error: syntax error, unexpected end of file in /usr/local/sbin/pfSsh.php(371) : eval()'d code on line 6

I don't know if this is the right syntax for what I was trying to do or what, but calling pfSsh.php directly from the shell (e.g. option 8) seems to work perfectly, and does exactly what I need.

Once again, thanks!

[jimp]

From there you'd use playback enableallowallwan (no need for exec)

[da_667]

@jimp Awesome. Thank you so much for your help. I love pfSense, and the work you guys do.

[Rico]

This is also in the Docs.
https://docs.netgate.com/pfsense/en/latest/book/config/what-to-do-when-locked-out-of-the-webgui.html

-Rico