@johnpoz OK, good to know about the 1 interface setup. I didn't expect the block rfc1918 removal would allow access to the webConfigurator all by itself. I said that the block being applied meant that none of the rules I added from the shell command line had any effect.
Look, I've run the same 2.8.0 setup off the netgate intaller ISO many times now, with the result being a genuine case of "mileage may vary". The latest two one times, one on ewach VM on which I faithfully reproduced exactly that VM setup specified in the netgate documentation about instlalling on Proxmox VM, both ran the installation to completion but when the installed version booted that never completes, it just sits there, as it turns out, waiting for input. I noiced, just before it scrolled off the screen with startup messages, that the question usually asked if you assign interfaces from the console menu (should VLANs be set up at this stage, or something like that) was being asked, so I entered no and it asked my to identify which NICs the WAN and LAN was on. Those are questions the installer asked and used, so why would it be asked again douring bootup. To make matters worse, the answers I provided to the installer were completely ignored and defaulted to the WAN getting an IP from DHCP and the LAN on a static IP of 196.8.1.1/24 with DHCP enabled. I reassigned the IPs once the cosole menu was up, enabled SSHd but could not get ssh access from the LAN port, until I went in through the console and ran pfctl -d, then it connected without a hitch.
Another variance I noticed is that whenever I selected during setup to use a local resolver it never could not connect to the NetGate servers. I recently had trouble going from 2.7.2 to 2.8.0 on my internet facing pfSense which rendered my email servers broken. Eventually I got tipped off that the new default setting to bring in state policy bound to interface was causing the problem. So my primary pfSense has that option back to the floating option (it was an impossible mission to set the option on in the advanced section of each firewall rule that might be impacted since setting that option does not cause the gear icon to appear indicating that advanced options are in effect. But I painstakingly went through every rule twice and ensured the setting is on for all the rules. Still it required the default to be changed back to the floating before it would allow the mail serves to run their own recursive resolvers as they insist on doing. In both the VMs I installed since, I had tremendous difficulty getting rules in place to get the rules I add to work. The only way past it was to keep running pfctl -d while making changes to anything or else the configurator would just time out and even the pings I had running on another screen would stop. These instances being behind the real firewall I was happy to disable the firewall temporarily to get by but didn't want to disable i permanently in the advanced option so I kept trying to set up rules where things kept working when I run pfctl -e. I was disappointed every time, until I went to the state policy global setting and changed that to the floating option, then everything started working as expected. What it basically means, from what I can see, is that the installer cannot even set up 2.8.0 as a recursive resolver and that cursed state policy setting it introduced breaks a lot more things than just multi-WAN setups. So much so that not even the installer knows what it needs to do or 2.8.0 is just broken, period.
pfSense had been a fantastic product for a long time, especially for people that don't identify as netqork engineers needing to get a job done. By comparison to the MicroTIK community who's outright toxic even with their fellow network engineers, the pfSense community and documentation was extremely accommodating to uderinformed people such as myself. It is an absolute shame to see that getting diluted by buggy features, undocumented behaviours and a switch to make the netgate installer the only means to get the community edition when the installer does such a messed up job of it in the first place.
Part of what I'm saying is that the anti-lockout rule, on the LAN interface, wasn't having any effect whatsoever until I changed the state policy to floating, so even with the one-interface intalll option that would have been exactly the same thing regardless of the block rfc1918 setting. I'll try that next time and give you more feedback if you're going to be able to get something done about it. I don't know what your role and capability entail, perhaps you're just another user like me, but I can tell you this. You gave me feedback from a position of authority saying things that in practice does not match what I've experienced and am still experiencing.. It's like there's no regression testing for new releases or the installer to catch out stuff that does not work as assumed in the manual or the release notes or by the developers themselves. It genuinely pains me to see pfSense in such a steep decline, quality wise and I feel sorry for those who pay through their noses for the Plus version which i sure to have the same issues made worse by the paid support people not knowing about the root causes either. I used to be absolutely convinced that once I have the means that I'd upgrade my entire operation to high throughput Netgate devices running pfSense+, but as it stands it will be better for my business to hire a network engineer and buy the Cisco or MicroTIK devices they swear by. I'm sure you can see what bad marketing outcome that is. Poor quality will kill Netgate's feeder market, drive people away to OPNsense and when they need it, Cisco or Juniper or microTik which comes with qualified engineers to get the results they used to do for themselves on pfSense.
