[ER] pfSense box unreachable after config LAGG failover interfaces for LAN/DMZ
-
If I recall correctly, once you create a LAN interface, the anti-lockout on the WAN shifts to the LAN. In which case you will loose configuration access. Try creating manual rules in the WAN to allow 22,80, and 443 to the WAN address before starting to config the LAN and OPT LAGG interfaces.
-
Is there a setting somewhere that blocks the web configuration on the WAN port as soon as there is a LAN port defined?
Yes.
Starting with 2.0 it has been possible to configure pfSense with only one interface, that interface must be WAN. In that scenario pfSense will default to allowing webgui access on the WAN interface.
If you have two or more interfaces webgui access is via LAN only, by default, and WAN is blocked.Steve
-
Hm, then I would say, this is a bug, because as you can see, the so-called LAN interface isn't configured: it has no IP address family assigned to it, nor does it have any IP address. Short, it's essentially a place-holder.
Heck, I'm not even sure the system would give me enough time to properly configuring the LAN interface after I set up the LAGG-failover group and assign it to the LAN interface. For all I know, I might be in the midst of setting up IPv4 and IPv6 properties when I get locked out. These interfaces aren't even marked as active!
So I really think this needs to change. Also, a firewall rule, once established, shouldn't go away without explicit (rather than implicit) user action. If the understanding is that it's a security risk to have admin access on the WAN port, then maybe after creating a LAN interface a message should be displayed that advises the user to remove the lockout rule from the WAN interface, but it shouldn't just happen behind the user's back.
Only the OPT1 interface was activated long enough to rename it to DMZ and then it was immediately deactivated again. The LAN interface was never activated at all.
When I have a rule in there, I rely on it sticking…
-
I see where you are coming from, and manual rules hold to that. The auto-rules like the anti-lockout might need to change a little. This is going to be up to the developers and maintainers of this project.
For the problem at hand. If you create the manual lockout rules on the WAN before starting in on the LAN and DMZ LAGG setups, are you able to get to where you can finish the config or still access the GUI after adding the LAN and DMZ LAGGs?
-
I see where you are coming from, and manual rules hold to that. The auto-rules like the anti-lockout might need to change a little. This is going to be up to the developers and maintainers of this project.
For the problem at hand. If you create the manual lockout rules on the WAN before starting in on the LAN and DMZ LAGG setups, are you able to get to where you can finish the config or still access the GUI after adding the LAN and DMZ LAGGs?
I will have to test that, because for some reason restoring with menu item 15 didn't get me far enough back. So right now I'm back to factory settings, downloading the latest snapshot. Then I can restore the last working settings (which will download a ton of packages, too). Once I'm done with that, I can test again. Hopefully without creating another lock-out, because this gets rather time consuming fast… (each cycle takes hours between downloading packages, etc.)
Would be cool if packages could persist through updates, but that's a different issue, and not likely going to happen in the short term.
-
Packages should persist through an update. When you update everything should be reinstalled automagically. However some don't as you've probably found. ::) Packages have to be kept up to date by their maintainers.
Steve
-
Packages should persist through an update. When you update everything should be reinstalled automagically. However some don't as you've probably found. ::) Packages have to be kept up to date by their maintainers.
When I mean "persist", then I mean "persist" not "automatic reinstall".
If I update Mac OS X, I don't have to reinstall Photoshop or even third party device driver afterwards, either. Yes, things are (pretty much all from what I can tell) reinstalled. But it takes about 3-4h for a few dozen packages to re-download and re-install, particularly if you don't have a blazing fast drive, CPU and connection.
For something like a firewall, that's a damn long time. That's a few hours without backup DNS server, without e-mail filtering, without web server, without phone service, etc. (depending on what packages are installed and used.)
Right now, updates of pfSense are closer to a re-install than to a true update. IMO that is one of the biggest weak spots of pfSense when compared to most commercial boxes: there an update is more or less the time it takes to upload the firmware, plus a reboot, with the only down-time for any service being the reboot.
The good thing is, the stable releases require such an upgrade fairly rarely (still a hassle), but it kind of gets a grind when dealing with snapshot releases… So this is something that should at some point be addressed. Maybe the new package system makes this better, would be awesome. Otherwise, it's maybe something for a 2.5 or 3.0 release of pfSense, but certainly something that should be on the radar in the long term.
-
OK, when I add manually fw rules to let 443 and 22 pass, then I'm seemingly not getting locked out.
I can however confirm, that the anti-lockout rule does get nuked behind the user's back (because it's missing now), and that despite the fact that both the LAN and the DMZ(opt1) interface are disabled, which particularly in combination I consider dubious.If we're concerned, it would be better to never open port 80 on the WAN and force https for the web configurator unless access is through the LAN or another trusted network.
I'd consider passwords going in the clear over the net a bigger problem than keeping encrypted access to the configuration interface open from public networks.
-
Do you not get redirected to https if you try to connect to port 80?
I think I agree with you that switching the webgui access to LAN should only happen once LAN is enabled with a valid IP that seems like an oversight. I have done similar things before but not including a LAGG setup. You can usually get around it by making all the required changes before applying them.
it takes about 3-4h for a few dozen packages to re-download and re-install
3-4h! :o What packages are you running that take that long?
My own box takes, maybe, a few minutes to reinstall the packages. I am only running a few small packages though.Steve
-
Squid and Snort alone can take minutes for each … a slow connection would extend even that.
-
Do you not get redirected to https if you try to connect to port 80?
AFAIK only IFF you have the https as default AND you enable redirection. But if the web configurator is set to use http, then you can happily send all the info in the clear as long as the default lock-out rule allow port 80.
My point however is, that https should ALWAYS be the default, and http on a WAN link should essentially never happen. Someone sniffing the password, and you might as well not have a firewall.
I'd hike the restrictions for allowing http to be enabled:- system must have active LAN link
- no anti-lockout rule on the WAN link that opens up port 80 to the system
Even in a LAN it's naive to assume that you're in a friendly environment, so I don't know why the console keeps asking me if I want to revert the web configurator to http whenver I make a minor change in the interface setup or something like that. Things should default to https, and people should have to jump though hoops if they really want to expose their sensitive passwords etc. to the public.
it takes about 3-4h for a few dozen packages to re-download and re-install
3-4h! :o What packages are you running that take that long?
My own box takes, maybe, a few minutes to reinstall the packages. I am only running a few small packages though.Let's start with snort, squid3, then let's continue with pfBlocker, mailscanner, dansguardian, imspector, anti-virus (havp), vhosts, sipproxy, radius, postfix, pfflowd, arpwatch, mailreport, nmap, and a few more. And I haven't even thought of freeswitch or asterisk yet ;)
Admittedly, I don't have the fastest connection yet (pfSense is supposed to help, because all my WAN traffic needs to get tunneled out to the internet due to a numbskull ISP called Verizon), and a CF Card is not the fastest disk drive, either…
-
I would certainly agree that using http for admin access to a firewall is not a good idea. However, to be fair, those two things are enabled by default so you have to actively choose to use http.
Though I can't imagine ever wanting to do it I wouldn't want to have that choice taken away from me.Clearly your package list dwarfs mine. ::)
Steve
-
An impressive list no doubt. There is something to be said about about having to many services running on the firewall. It increases the risk of a bug in any one of them compromising security. Though having them there does help out those who need to consolidate, like myself.
-
Indeed. It's a problem that stems from the incredibly wide range of deployment scenarios that pfSense can fill. You have people using it in enterprise situations where alternatives would be many $10,000's whilst at the same time people are replacing a $50 home router. Expectations and requirements across that range are going to vary wildly. ;)
The new package system may help. I believe it allows for all dependencies to be included in the package. That may mean larger downloads though. Perhaps it's time to run a local package repo?Steve
-
Packages must be reinstalled after a firmware update because the underlying OS could change in between, and there could be potential incompatibilities introduced in the meantime that new binaries will fix.
Sure, compatibility shims can help this but there is no way to avoid it and guarantee that things will work properly once the firmware update is done.
Also specifically in the case of NanoBSD the packages do not exist on the newly imaged slice so they have to be downloaded and reinstalled because they do not (and cannot) already exist/persist there.
To most end users the package reinstall is something that happens only when upgrading to a major release, which means every 6-9 months or so, give or take. The only people who feel the pain of the package reinstall process taking a while are those tracking snapshots very often. :-)
Also, HTTPS is the default out of the box, with port 80 redirecting to the HTTPS port in a way the browser will cope with neatly. HTTP has not been the default since 1.2.3.
-
Also, HTTPS is the default out of the box, with port 80 redirecting to the HTTPS port in a way the browser will cope with neatly. HTTP has not been the default since 1.2.3.
I know, and appreciate that. However someone should check out the behavior at the console. There are a few operations, like setting an interface's IP address and such which always end up with the system asking me if I want to revert the web configurator to http. Why would I? If I had it set to http, and it would ask me to revert to https, then that would be what's expected, but not the system asking me if I want to revert to a less secure method.
Could be that these are left-overs from the 1.2.3 era? -
If someone fubar's their certificate or similar, there has to be a way to revert to http on the console.
It's a failsafe.
-
If someone fubar's their certificate or similar, there has to be a way to revert to http on the console.
It's a failsafe.
I understand that part. If it would ask me in the context of resetting the web configurator password from the console, I'd understand, because then chances are someone can't get into the system anymore. But it seems setting an interface address or something like that has rather little to do with reverting to http for the web interface.
It's not a big deal, but it's just a minor nuisance, because if one quickly answers various prompts with
y [ret] y [ret], and then before one knows it, one has also reverted to http.Small pebble in the shoe, I can still walk ;)
-
When one is maintaining their firewall you'd think one would carefully examine any prompts to ensure that's what they really wanted to do ;-)
True that could be split off into its own option or moved, it's really there because of tradition - in 1.2.x that's where it was, as that menu option only dealt with resetting LAN functions.
Its scope was expanded for 2.x to cover other interfaces, but the other functions didn't get moved.
Inertia will probably keep it where it is, but I suppose that's up for debate.
-
When one is maintaining their firewall you'd think one would carefully examine any prompts to ensure that's what they really wanted to do ;-)
I agree, but then there's that infamous difference between theory and practice, between "should be" and "is"… ;)
Inertia will probably keep it where it is, but I suppose that's up for debate.
That's why I mention it :)
