Rod Whitworth wrote: ... > Let's look at this a little more analytically: > My firewall is a Soekris 4801 with sis0, sis1 and sis2. > sis0 is the 0utside (ADSL) > sis1 is the 1nside (LAN) > sis2 is the 2erver LAN
heh. I gotta remember that naming/numbering convention, I like it! > If 0 fails the other two "move up" the table. Risk = zero. > If 1 fails the users holler "No service!" and the servers won't be > compromised because they will now be connected to sis2 promoted to be > sis1 and their default route won't be available and incoming traffic > can't get to them either. > > Now, what was the problem again? With all the interfaces below the > failure moving up the table there will be address mismatches = no > traffic. > > I see no reason to panic. Maybe I'm too tired after being up really > late replacing a faulty modem and I forgot to turn off NAT in the new > one so my sleepy eyes missed the fact that I needed to test more than > browsing from the LAN to make sure my servers were reachable. 8-(( > > 8>< snip rest of story. Yeah, maybe I'm missing something too, but I'm not really thinking of a situation where this would really be a "risk" of anything other than downtime. And if chunks of your firewall aren't working, that's downtime. Usually, if you plug the wrong things into the wrong port, it just doesn't work. Different ports are usually on different subnets. If you really have a situation where this is a real risk and not just a silly panic over nothing, a solution is simple: * your /etc/pf.conf file just contains a block in all, and a "pass out all from just the firewall to the outside networks. * in rc.local, you stick a script which tests things however you want them to be. Maybe you count the NICs, maybe you compare their MAC addresses to what you expect them to be, etc. Whatever makes you happy or is appropriate for your configuration. * IF you are happy, you do a "pfctl -f /etc/prodpf.conf" or similar, and put your production rules in there. Maybe even only activate forwarding if the test passes. IF the system is missing pieces, maybe you load up an "ssh in only" ruleset so someone can get to the box to look at what went wrong, but the firewall stays otherwise inert. Document the heck out of it, including in pf.conf saying, "real production rules are over THERE..." Note that this requires modifying no system files, so your upgrade process remains simple. I think that would be a lot saner for what seems to be a very special case than any of the "let's follow Linux or Solaris's lead" crap. I've used those, I'm completely unimpressed. The primary reason they suck is complexity; the people who claim they understand Linux and Solaris don't seem to be able to explain why they do what they do or fix it when they do it wrong, forget mere mortals. They just work around oddities. OpenBSD's rules for NIC naming are quite simple. There are cases where they will annoy the heck out of you, but it is easy to see WHY they are doing funny things, and easy to fix when they do. When my firewall blows out when I'm on vacation, I want to be able to tell someone over the phone, "unplug the production machine, keeping careful track of what cable comes out of which port, plug them into the same port on the spare machine. Pull the disk out of the old machine, plug it into the spare machine. Turn it on, see you when I get back". Start strapping ports to physical addresses, you create a management nightmare, and something that probably only you will ever be able to maintain. Not good. Nick.
