Re: Can someone clarify ipfw's in/out/recv/xmit/via concepts?
On Thu, 28 Jul 2005, Gary W. Swearingen wrote: > Thanks guys. I think I've "got" most of it now. [..] > When it tests an incoming packet it doesn't try to predict which > interface it will be transmitted on (not sure why, if NAT isn't on), > so "in" rules don't match against an "xmit" interface. IPFW doesn't try to 'predict' anything, it would be pointless anyway; it has no notion of what the kernel and especially the routing may do. It simply keeps trying to match this (incoming or outgoing) packet against every rule in sequence until it's either accepted or dropped. > When it tests an outgoing packet, it knows which interface it was > received on and which interface it will be transmitted on so "out" > rules may match against both "recv" and "xmit" interfaces. Yes. By then, the incoming interface is tagged along with the packet. > Using "via if0" is like using three rules: "in recv if0", > "out xmit if0", and "out recv if0". Except that via, used without in or out, matches on both passes (and counts the packets/bytes twice), assuming it's not dropped on input. > Using "out via if0" is like using two rules: "out xmit if0" > and "out recv if0". > > Using "in via if0" is like using "in recv if0". Hmm, yes, but I don't know that you can really put it much better than: The via keyword causes the interface to always be checked. If recv or xmit is used instead of via, then only the receive or transmit interface (respectively) is checked. By specifying both, it is possible to match packets based on both receive and transmit interface, e.g.: ipfw add 100 deny ip from any to any out recv ed0 xmit ed1 The recv interface can be tested on either incoming or outgoing packets, while the xmit interface can only be tested on outgoing packets. So out is required (and in is invalid) whenever xmit is used. Specifying via together with xmit or recv is invalid. A packet may not have a receive or transmit interface: packets originating from the local host have no receive interface, while packets destined for the local host have no transmit interface. > I'm not claiming that the above is any better than the manpage; I'm > just trying to quickly hang some simple "facts" out there to be shot > down if untrue. (Maybe someday I'll set up a routing firewall to test > more of them than I have yet.) Yep; test first, study results, write up findings if different from man :) Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can someone clarify ipfw's in/out/recv/xmit/via concepts?
Dave McCammon <[EMAIL PROTECTED]> writes: > Here is a link to a thread that help me to understand > the in/out/recv/xmit stuff. Thanks guys. I think I've "got" most of it now. Incoming packets are those entering the OS kernel implementing the ipfw firewall, but not necessarily those entering the ipfw firewall each time the kernel uses it. Outgoing packets are those leaving. Depending upon firewall config, the firewall can test packets one or two times as they enter the kernel, considering them as incoming, and one or two times as they exit the kernel, considering them as outgoing. (See ipfw diagram.) An exception is that when bridging, it tests packets only once, considering them as incoming only. (The latter based on my tests.) When it tests an incoming packet it doesn't try to predict which interface it will be transmitted on (not sure why, if NAT isn't on), so "in" rules don't match against an "xmit" interface. When it tests an outgoing packet, it knows which interface it was received on and which interface it will be transmitted on so "out" rules may match against both "recv" and "xmit" interfaces. Using "via if0" is like using three rules: "in recv if0", "out xmit if0", and "out recv if0". Using "out via if0" is like using two rules: "out xmit if0" and "out recv if0". Using "in via if0" is like using "in recv if0". I'm not claiming that the above is any better than the manpage; I'm just trying to quickly hang some simple "facts" out there to be shot down if untrue. (Maybe someday I'll set up a routing firewall to test more of them than I have yet.) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can someone clarify ipfw's in/out/recv/xmit/via concepts?
in message <[EMAIL PROTECTED]>, wrote Dave McCammon thusly... > > Here is a link to a thread that help me to understand the > in/out/recv/xmit stuff. > > http://groups-beta.google.com/group/comp.unix.bsd.freebsd.misc/tree/browse_frm/thread/240d22a55265689/4bb2dd91a376fa6c?rnum=1&hl=en&_done=%2Fgroup%2Fcomp.unix.bsd.freebsd.misc%2Fbrowse_frm%2Fthread%2F240d22a55265689%2F2c14cdd252d01ff2%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26rnum%3D4%26prev%3D%2Fgroups%3Fq%3Dipfw%2Bout%2Brecv%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D3B5E86C8.8438BEE7%2540amit.cz%26rnum%3D4%26#doc_8d3d7ceea76d1cca > After replacing all %[0-9a-f][0-9a-f] but %40 w/ their respective characters and then deleting (almost) nonessential things, URL shrinks to (works in Opera 8.x) ... http://groups-beta.google.com/group/comp.unix.bsd.freebsd.misc/tree/browse_frm/thread/240d22a55265689/4bb2dd91a376fa6c/groups?selm=3B5E86C8.8438BEE7%40amit.cz&#doc_8d3d7ceea76d1cca > ok kind of long ...do a search in google groups using- > Why is there a "out recv" interface spec in ipfw? That, of course, would have been faster if one is *really* wanted to learn about that. - Parv -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can someone clarify ipfw's in/out/recv/xmit/via concepts?
--- "Gary W. Swearingen" <[EMAIL PROTECTED]> wrote:
> 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.
>
> (I hope your replies will help me get some
> clarifications into the
> manpage.)
>
>^ 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?
>
> Here's a pic of my firewall:
>
> +--+
> | +-+ |
> | |KERNEL | |
> | +-+ |
> || || ||
> |v ^v ^|
> || || ||
> | +-++-+ |
> | | NIC |FW | NIC | |
> | +-++-+ |
> || || ||
> +--+
>| || |
>v ^v ^
>| || |
>
>WANLAN
>
> The manpage says we have incoming and outgoing
> packets.
> In and out of what? NIC or kernel or ipfw or
> computer?
>
> 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?
>
> Does "ipno" mean an numerical Internet address?
> (It's not mentioned elsewhere in the manpage.)
>
> 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?
>
> If an incoming packet can be associated with an xmit
> interface, why
> can't an outgoing packet be associated with a recv
> interface?
>
> P.S.
>
> 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?
>
> I suppose it would be best to put blocks everywhere
> possible
> or at least "where" the packets enter the computer.
> Right?
>
> Help!!
>
>
Here is a link to a thread that help me to understand
the in/out/recv/xmit stuff.
http://groups-beta.google.com/group/comp.unix.bsd.freebsd.misc/tree/browse_frm/thread/240d22a55265689/4bb2dd91a376fa6c?rnum=1&hl=en&_done=%2Fgroup%2Fcomp.unix.bsd.freebsd.misc%2Fbrowse_frm%2Fthread%2F240d22a55265689%2F2c14cdd252d01ff2%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26rnum%3D4%26prev%3D%2Fgroups%3Fq%3Dipfw%2Bout%2Brecv%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D3B5E86C8.8438BEE7%2540amit.cz%26rnum%3D4%26#doc_8d3d7ceea76d1cca
ok kind of long ...do a search in google groups using-
Why is there a "out recv" interface spec in ipfw?
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can someone clarify ipfw's in/out/recv/xmit/via concepts?
>> Is my "de0" an "ifX" or an "if*"?
>> ("exact name" or "device name")
>
> "de0" is an "ifX".
>
>> What would be an example of the other?
>
> "de*"?
I guess that should have been obvious. I'll try to get
the "exact name" and "device name" descriptions improved.
>> Does "ipno" mean an numerical Internet address?
>> (It's not mentioned elsewhere in the manpage.)
>
> I think so.
Yes, the manpage IS referring to it as "IP address".
Three down, several to go.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can someone clarify ipfw's in/out/recv/xmit/via concepts?
Gary W. Swearingen wrote:
[ ... ]
The manpage says we have incoming and outgoing packets.
In and out of what?
Into and out of the system.
NIC or kernel or ipfw or computer?
Yes, all of those.
The manpage describes:
recv | xmit | via {ifX | if* | ipno | any}
Is my "de0" an "ifX" or an "if*"?
("exact name" or "device name")
"de0" is an "ifX".
What would be an example of the other?
"de*"?
Does "ipno" mean an numerical Internet address?
(It's not mentioned elsewhere in the manpage.)
I think so.
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?
Each of your NICs is logically a full-duplex device, which can both xmit and
recv.
If an incoming packet can be associated with an xmit interface, why
can't an outgoing packet be associated with a recv interface?
A packet which was created on the machine does not have an interface which it
was received on. Packets which are being forwarded from other machines would
have a recv interface.
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?
That depends entirely upon the rules, it's not useful to make a generalization
like that without a more specific context.
Normally, people should use the "xmit via ifX" syntax for pipe/queue rules to
avoid counting traffic twice as the packets pass through, but they can also be
used to ensure that, say, traffic to 127.0.0.1 only goes through lo0, and not
through some external connection by someone trying to source-route in as localhost.
I suppose it would be best to put blocks everywhere possible
or at least "where" the packets enter the computer. Right?
If you are creating a firewall, you need to create a network topology which
permits you to control network access, which means restricting traffic which
flows over well-defined choke points (ie, your external internet links).
--
-Chuck
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
