Private WLAN

Marthin

Hi guys,

The call for testing of the 2.8.1 beta stated I must report problems here, but the issue is wider than 2.8.1 so feel free, moderators, to move this post somewhere else.

I've run into some tricky territory to navigate while installing into a qemu vm under Proxmox, I've followed the instructions carefully but some of the installation attempts would either hang or report failed installations afterward. on the odd occasion that I got in installing, I really battled to get access to the gui or remote shell.

For clarity, I'm not a network engineer but systems architect forced through my own choices in life to sort out my own networking, so take my feedback in that context.

The issue I figured in the end caused all my issues that could in my mind also be why the installer was struggling, was caused by the fact that these two installations were done behind my normal pfSense firewall which resulted in using private (IANA) ip addresses on the WAN interface. As you know, pfSense installs with a setting to implicitly lock private networks on WAN interfaces. I'm not disputing that it's the correct way to do that, but I do want to suggest that the installer be adapted to take into account that in some scenarios that default option can cause a lot of difficulty.

My suggestion, should you wish to give it some thought, is that:

a) If the WAN interface is assigned a static IP in one of the IANA private address ranges, the users should be asked to confirm awareness of that fact and that though the address is used on the firewall's WAN side it is in fact in a private network rather than facing the public. If the installer has confirmation that the user accepts the consequences, it should then intall pfSense with block IANA addresses on WAN interfaces turned off.
If the WAN adress is provisioned to get an address from DHCP things might get a little trickier, because there might no longer be a UI invlved when the IP is obtained and proves to be in an IANA private range. Ideally the same reasoning as suggested above should apply, resulting in the implicit blocking default be removed.
Perhaps the better approach would be to make the IANA private range detection part of the IP Address settings dialog in both the install fase, console and through the GUI, basically confirming with the user that the configured (statically or obtained from DHCP or PPPoE results in an address on a WAN interface that isn't legal for direct connections to the internet.
If all of the above is too much to address at once in the beta testing fase, perhaps a temporary workaround might be to publish something about deplying with privste WAN addresses and offer a console shell command that would turn that flag in the Reserved Networks section of the WAN interface off and/or offer a more permanent way to turn the firwall off than during initial setup than pfctl -p which has to be redone after each configuration step.

Kind regards
Marthin

johnpoz

@Marthin not sure what issue your trying to overcome - you want to access the wan interface from rfc1918 for the web gui to complete a setup?

Turning off the block rfc1918 on the wan during setup is not going to allow access to the gui - because there are no other rules to allow access on the wan no matter what your source IP is.

If you are unable to setup pfsense where you would be able to access the lan IP. The only setup 1 interface, this would be the wan and you would be able to access it - because when pfsense only has 1 interface it puts in the antilock rule on that interface and would allow access to the gui.

You can then setup the rules you want on the wan to allow access before you enable a lan interface.

Marthin

@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.