[ER] pfSense box unreachable after config LAGG failover interfaces for LAN/DMZ
-
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 :)
-
Clearly your package list dwarfs mine. ::)
and is well beyond what anyone should be running on a firewall, much less one with CF. 3-4 hours on CF is probably more like 5 minutes on a HD. In the vast majority of usage cases, where people are only upgrading when new official releases come out, package reinstallation is a requirement. It's not ideal when you're running snapshots and upgrading routinely, especially when it's on CF and you're setting the world record for number of services running on a firewall. You can always get into the source and disable that.
-
@cmb:
Clearly your package list dwarfs mine. ::)
and is well beyond what anyone should be running on a firewall, much less one with CF.
Well, at some point in time a real SSD is going in there, but that's still in use elsewhere until some data recovery on some other drive can be done. I'm not putting a drive in there, because this is a fanless device, and I rather keep it cool than add all the heat from a regular drive in that device. It is, however, not one of these dog-slow CF cards, but probably about comparable in speed to a slow 2.5" drive.
Also, it's not clear which of these packages end up surviving the evaluation period, but when it boils down to it, it's essentially all stuff that isn't "out there": mail, virus filtering, IDP, VPN, etc. and looking at the CPU, it clearly feels bored. Note also: this is essentially protecting a net with a half a dozen computers incl. a small web server for internal use behind it. So it's not like there are dozens of users hitting on the system, so it would be ridiculous to have several devices taking over various aspects of network border security.
So it's like a big network shrunk down in size, which is perfect for playing around with stuff.
It will be interesting to see how much faster the update will be next time, because before it went through my old firewall which as it turns out slowed down my net considerably even though it wasn't doing much besides running IPSec…
Anyway, maybe the updater could become smarter in the sense that it differentiates between minor and major version updates, that way if minor bug fixes are pushed out, not everything has to be reinstalled.
I guess one way of doing this could be to use the package system: differentiate between standard packages and optional/3rd-party packages. That way the entire pfSense system could be broken down into packages, which can already be updated individually without disrupting the rest of the system. That way only if there's a major OS upgrade is a new install required, while things like e.g. changes in IPSec would result in an upgrade of a standard package. -
It is, however, not one of these dog-slow CF cards, but probably about comparable in speed to a slow 2.5" drive.
Unfortunately in NanoBSD CF cards are booted with DMA disabled so it will be running at PIO4, quite a lot slower than a 2.5" HD, even if it's a super rapid UDMA card. I believe this is due to a bug in the way FreeBSDF handles IDE mounted CF cards? It's while since I looked into it. You could try try removing:
hw.ata.atapi_dma="0" hw.ata.ata_dma="0"from /boot/loader.conf and see what happens. It may well fail to boot though so have a backup solution in place.
Steve
