Rod Whitworth wrote:
...
quoted text
> 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!

quoted text
> 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.