IPFW IPFW trusted internal interface

[Professor_Fate]

Hi all,

For my question please reference the handbook tutorial of IPFW.

https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html

What exactly does this rule for the LAN interface do?
$cmd 00005 allow all from any to any via xl0

This rule is above all the outbound rules for allowing access out to the internet. My understanding is that once a packet matches "allow" it will allow it and stop processing any other rules for that packet. So a packet originating on the LAN side intended for the internet will hit this rule before any of the rules allowing access to the internet. Also gateway_enable is set to "YES" so the interfaces can forward traffic to each other. The default route is in the routing table. So with that in mind, a packet originating from the LAN should hit this rule, be forwarded to the public interface, and go straight out to the internet. It's already been allowed so it would really never hit any of the outbound rules below. However in the example, they have all sorts of outbound rules below. Can someone explain this rule a little better?

Forgive me as I'm used to chains where everything is either intended for the machine, originating from the machine, or routed through the machine.

 

[PMc]

Ah, this escaped my attention!
There is some vague remembering in my memory that we once had a close look at some ruleset configuration, and found some things that were bogus, and then the argueing was that these things were literally taken from the handbook examples. So I put into my mind that the examples from the handbook are probably more or less bogus.

But then when looking for these mistakes, I didn't find them anymore.

It appears You found one of them.

Doing forensics, we find the mentioned rule first appearing in this document, (c)2005.
It underwent various editorial workovers in the meantime, but it seems never a logical verification.

But You asked for an explanation. So, what happens is: a packet from the LAN comes in on xl0, it fulfils the rule 5and gets allowed into the kernel's routing scheme. From there it may either be locally delivered (end of story), or sent to the outgoing interface aka "pif" (dc0 or rl0 or tun0 depending on the version of the document).
Then in pass two (give net.inet.ip.fw.one_pass=0), the packet will re-enter the ruleset, will again reach rule 5 which still holds true, and will be sent to the outbound interface, WITHOUT keepstate and WITHOUT nat translation.
(Keepstate and NAT translation will only work for traffic generated by the localhost itself.)
Then, when an answer-packet comes back from outbound, that one will reach rule 14 (divert natd), but will then probably not be accepted because the stateful rule was not generated earlier.

The whole thing may actually work if you forget to set net.inet.ip.fw.one_pass=0, because then a divert will immediately accept the packet - but then you wouldn't need any of the rules beyond 14.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

But the point here is something different: this is quite a small ruleset of only 23 rules, nevertheless such bugs did escape the editors for 14 years. Now what about a more complex ruleset with some hundreds of rules?

root:~ # ipfw show | wc
     414    4382   41478

How could that be properly maintained and verified?

It is quite easy to arrive at such a ruleset.
You start by doing away that plastic thing called "internet access router&firewall" (which is just a Linux inside), and let the FreeBSD machine do that job. Then you figure that you can also do away with the SMC quadport hub (which is also just a Linux inside, plus a bunch of bugs) and instead put some four or six way network interface card into the FreeBSD box (the only issue is that these have exchanged connectors and you need Xover plugs). Then you attach 1-2 WLAN and let the neighbors have internet access. Finally you add an VPN server so the services can also be used from remote.
You end up with a dozen of network interfaces, and some 5-8 different security realms, each of them to be separated from each other.

Theoretically ths can be solved. Practically I might suppose, you need to be a very good chess player.

 

[VladiBG]

I hope this will illustrate what you are asking and why there's allow rule for all traffic via the trusted interface. The key word for the other outbound rules is "via"