Date: Thu, 28 Jul 2005 21:12:52 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: freebsd-questions@freebsd.org Cc: "Gary W. Swearingen" <garys@opusnet.com> Subject: Can someone clarify ipfw's in/out/recv/xmit/via concepts? Message-ID: <Pine.BSF.3.96.1050728185847.3571A-100000@gaia.nimnet.asn.au> In-Reply-To: <20050727043611.1FC6416A44E@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
(Re: freebsd-questions Digest, Vol 105, Issue 7)
Gary writes:
> I see in another msg that I'm not the only one scratching my head over
> the ipfw manpage's explanation of in/out/recv/xmit/via concepts. I've
> spent many hours reading that manpage and working on my rc.firewall
> (and it seems to work OK, based on the logging), but I can't figure
> out what it's trying to tell me, even with that nice ASCII art.
Took me a while, measured in years, and there's lots I still don't know
about features I haven't used yet (NAT, dummynet, layer 2 filtering
except 'bridged' ..) but I'll have a go.
> (I hope your replies will help me get some clarifications into the
> manpage.)
I think you really need to USE ipfw a fair bit to really 'get it', and
maybe even peek at some of the code. rc.firewall only exemplifies bits
of its capability. I'm unsure how really thoroughly you've read ipfw(8)
though, going by some of your questions ..
> ^ to upper layers v
> | |
> +----------->-----------+
> ^ v
> [ip_input] [ip_output] net.inet.ip.fw.enable=1
> | |
> ^ v
> [ether_demux] [ether_output_frame] net.link.ether.ipfw=1
> | |
> +-->--[bdg_forward]-->--+ net.link.ether.bridge_ipfw=1
> ^ v
> | to devices |
> + +
>
> FROM BOTH TO BOTH
> NICS? NICS?
>From and to whichever NICs (if any, as Chuck Swiger pointed out) may be
involved with the processing of THIS particular packet.
> Here's a pic of my firewall:
>
> +------------------------------+
> | +-------------------------+ |
> | | KERNEL | |
> | +-------------------------+ |
> | | | | | |
> | v ^ v ^ |
> | | | | | |
> | +-----+ +-----+ |
> | | NIC | FW | NIC | |
> | +-----+ +-----+ |
> | | | | | |
> +------------------------------+
> | | | |
> v ^ v ^
> | | | |
>
> WAN LAN
FW should here be visualised _between_ the NICs and kernel/stack, for
incoming and (unless bridging or dummynet one-pass) outgoing packets.
And of course between kernel/stack functions for localhost packets.
> The manpage says we have incoming and outgoing packets.
> In and out of what? NIC or kernel or ipfw or computer?
Good question :) Think of both passes (except bridging) through the
IPFW ruleset for each packet, coming in and then (maybe) going out.
> The manpage describes:
> recv | xmit | via {ifX | if* | ipno | any}
>
> Is my "de0" an "ifX" or an "if*"?
> ("exact name" or "device name")
>
> What would be an example of the other?
tun* would refer to all your tun interfaces, say.
> Does "ipno" mean an numerical Internet address?
> (It's not mentioned elsewhere in the manpage.)
Yes - I won't say 'obviously', however searching ipfw(8) does indeed
define this quite clearly: see under section 'src and dst'
> Does each of my NICs have both of the manpage's xmit and recv
> interfaces, or is one an xmit and one a recv for any one packet rule?
Refer Chuck's response, and the manual section 'interface-spec'. Read
that section about 10 times till it sinks right in (took me a while!)
> If an incoming packet can be associated with an xmit interface, why
> can't an outgoing packet be associated with a recv interface?
No, you have this one backwards. This IS clearly if tersely explained
in ipfw(8). Only outgoing packets can be tested for both recv and xmit
interfaces. IPFW doesn't know where an incoming packet (recv ifX) is
going yet, subject to routing and until the outbound second pass, if
it's to be forwarded.
> It seems that some people do their blocking of packets
> going from LAN to WAN "on" (so to speak) the LAN interface, some on
> the WAN interface, and some on both. It doesn't seem to make much
> difference on a pure firewall, except for rule-writing convenience.
> Right?
Not exactly. Anything can (and will) happen on the WAN; you have a more
precise idea of what you expect to be happening 'inside'; even so you
should assume at least every type of ignorance, if not malice, 'inside'.
Hence the importance of (eg) the anti-spoofing rules, inside and out.
> I suppose it would be best to put blocks everywhere possible
> or at least "where" the packets enter the computer. Right?
Spend some more time with the manual; taken as a whole it's pretty good,
and along with some further reading, practical playing will clue you in,
even if peeking at some of the code doesn't. Try adding a few dozen
'count' rules for all sort of test situations then spend some time with
'ipfw -t show | less'
Cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1050728185847.3571A-100000>