Private WLAN
-
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 -
@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.
-
@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.
-
Hmm, you shouldn't need any rules there once the NICs have been assigned. They do need to be assigned though.
If you're accessing it from the WAN side one option is to assign only one NIC initially. In that setup traffic is allowed one that one interface so you would be able to access the gui and complete the setup.
If you do that you have to remember to add a pass rule on WAN before you enable a LAN interface to continue accessing from the WAN side. -
@stephenw10 The symptoms included that I cound not access the web GUI or (or SSH port after enabling it on the console) via the LAN side where the anti-lockout rules were in effect. I had to turn the firewall off with pfctl -d repeatedly for any change through the gui caused that to reset to enabled. Ultimately, the only way I could reliable run with the firewall enabled for nat and policiy bawsed routing to remain an option) but allowing all traffiic anywhere was to define a floating Allow All rule for both in and out.
Look, my objective was to use the pair of pfsense nodes as a table platform that needs minimal downtime and restarts and failover when they do by using the pfsense as not as firewall but more like a router. But it's been such a hastle I've mothboalled those two VMs and pivoted to Ubutnu server nodes with haproxy and keepalived installed. It'w going to require more manual intervention to keep fully operational (not waying it needs a restart) but my trust in pfsense as a rock-solid table platform has been broken and it's not going to recover by itself.
-
@stephenw10 To be honest, when you tell me what should happen and it didn't and doesn't happen that way, the damage is done. Like when Hagrid says "I probably shouldn't have said that" in the Harry Potter movies. The pfSense software itself, once you can get to it, is predictable and the most of the settings and flags do what they proclaim to do except for this new state policy rule setting which has dire consequences that nobody at Netgate seems to have the foggiest idea about. That one has all the marking of getting shoved in there at the last mnute with the job of properly inorporating the whole concept into every aspect touched by it left less than half done. The stated rule is that if you've set any advanced options on a firwall rule, the rule displays a gear icon in the list. That setting doesn't, which is a dead giveaway that the job is not done. But you can argue it's largely a cosmetic or at best a visual aid, but it goes much deper than that because even when I took the pain to the floating states rule on for every rule I had I still could not get DNS traffic through my main firewall without changing the global back to the old default from before 2.8.0.
You can argue could've, should've and would've all day long but not when I lived through direct evidence that it somehow did't work like you say should have.
-
I have numerous 2.8/2.8.1 VMs installed in Proxmox here and they all behave exactly as expected. So something must be different.
Since you were connecting them behind an existing pfSense install did you set a different subnet? A subnet conflict between WAN and LAN in the VMs could present like that.
