Date: Mon, 12 Mar 2001 09:47:13 +0200 From: "Patrick O'Reilly" <patrick@mip.co.za> To: <freebsd-ipfw@FreeBSD.ORG> Subject: RE: interface specification extension for ipfw Message-ID: <NDBBIMKICMDGDMNOOCAIGEENCEAA.patrick@mip.co.za> In-Reply-To: <HJEEKLMFLKEOKHOKNPBMIENDCLAA.patrick@netzuno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Patrick,
I have just caught up with my mail this morning - I have read this thread
with interest. My experience with ipfw is purely as a user, but my
understanding is as follows:
When firewalling is enabled, the kernel will pass any packet which is
entering or leaving a network interface to the ipfw ruleset for evaluation.
For gateways (as firewalls usually are) this means that the packet will be
processed twice, inbound and outbound. When the packet is from or to the
local host it will only be evaluated once!
The man page says:
-------------------
Each packet that has been received or is about to be sent goes through
the ipfw rules. In the case of a host acting as a gateway, packets that
are forwarded by the host are processed by ipfw twice (once when
entering, and once when leaving).
...
The in keyword indicates the rule should only match incoming packets.
The out keyword indicates the rule should only match outgoing packets.
...
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 invalid) whenever xmit is used. Specifying via to-
gether with xmit or recv is invalid.
A packet may not have a receive or transmit interface: packets
originat-
ing from the local host have no receive interface. while packets
destined
for the local host have no transmit interface.
-------------------
As I understand all this, it is impossible to set up an 'in' rule to handle
packets originating on the localhost because they never come 'in', they only
go 'out'. Likewise, it is impossible to set up an 'out' rule to handle
packets destined for the localhost, since they only come 'in'.
This would explain the discrepancy between your rules #7 and #11. #7 counts
all packets going 'out', but #11 only counts packets going 'out' which
originally came 'in' from somewhere else. So #7 includes traffic from the
localhost, but #11 does not.
I cannot comment on the ideas you have about using '!any' or 'null' or 'me'
instead of the usual interface names ('cos I am not intimate with the source
code). But whatever changes might be made in the way ipfw evaluates the
interface information in the packets, I suspect that the kernel will still
hand packets to ipfw on the same basis, namely when the packet will be
passing through an interface, and NOT when it is to/from the local machine.
In summary, in one of your messages you said you want to achieve something
like:
------------------
10 skipto 1000 ip from any to any in recv ed0
20 skipto 2000 ip from any to any in recv xl0
30 skipto 3000 ip from any to any in recv local
40 deny ip from any to any
------------------
In this example Rule #30 is impossible because a local packet will never be
evaluated on the way 'in'. Even if you find a way of identifying the
'local' interface ('!any' or whatever), the kernel is not going to process
that packet.
Likewise, Rod Grimes suggested:
------------------
No, but it should be trivial to patch the code to allow your !any, if
you consider that !any is the same as =null:
ipfw count ip from any to any in recv null
Ie, the recv keyword looks at the ifp in the mbuff, the ifp will be null
for packets originated on the local machine.
------------------
Again, I don't believe his rule will work, because ipfw will not get an
opportunity to look at an 'in' packet which is from the local machine. If
you change his rule to "ipfw count ip from any to any out recv null" then
ipfw will handle the packet, but obviously this is on the way 'out' already.
The only thing I think you can do is try to catch the packets on the way
'out' and do whatever needs doing there. In those outbound rules you should
have success with one of your new keywords ('!any' or 'null' or whatever you
choose).
Please forgive me if I am wrong, but that is the way I have understood ipfw.
If you do make these changes to the ipfw processor I certainly hope they
will make it into a future release of -STABLE because it could be very
useful!
Have fun,
Patrick O'Reilly.
-----Original Message-----
From: owner-freebsd-ipfw@FreeBSD.ORG
[mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of Patrick Bihan-Faou
Sent: 10 March 2001 19:30
To: freebsd-ipfw@FreeBSD.ORG
Subject: RE: interface specification extension for ipfw
OK,
I have done a couple of experiments, and now I am confused.
The statement in the manpage (regarding whether or not the interface
information is set) seems to be incorrect.
00001 483 113807 count ip from any to any
00002 245 17088 count ip from any to any in
00003 25 3887 count ip from any to any in recv rl0
00004 218 12895 count ip from any to any in recv rl1
00005 2 306 count ip from any to any in recv lo0
00006 245 17088 count ip from any to any in recv any
00007 238 96719 count ip from any to any out
00008 22 3536 count ip from any to any out recv rl0
00009 23 1166 count ip from any to any out recv rl1
00010 0 0 count ip from any to any out recv lo0
00011 45 4702 count ip from any to any out recv any
00012 25 1309 count ip from any to any out xmit rl0
00013 211 95104 count ip from any to any out xmit rl1
00014 2 306 count ip from any to any out xmit lo0
00015 238 96719 count ip from any to any out xmit any
00016 0 0 count ip from any to any out recv rl0 xmit rl0
00017 22 3536 count ip from any to any out recv rl0 xmit rl1
00018 0 0 count ip from any to any out recv rl0 xmit lo0
00019 22 3536 count ip from any to any out recv rl0 xmit any
00020 23 1166 count ip from any to any out recv rl1 xmit rl0
00021 0 0 count ip from any to any out recv rl1 xmit rl1
00022 0 0 count ip from any to any out recv rl1 xmit lo0
00023 23 1166 count ip from any to any out recv rl1 xmit any
00024 0 0 count ip from any to any out recv lo0 xmit rl0
00025 0 0 count ip from any to any out recv lo0 xmit rl1
00026 0 0 count ip from any to any out recv lo0 xmit lo0
00027 0 0 count ip from any to any out recv lo0 xmit any
00028 23 1166 count ip from any to any out recv any xmit rl0
00029 22 3536 count ip from any to any out recv any xmit rl1
00030 0 0 count ip from any to any out recv any xmit lo0
00031 45 4702 count ip from any to any out recv any xmit any
These traces seem to suggest that no packets are ever passed to the firewall
rules without proper interface information. I certainly cannot confirm that
the following statement is valid in a reliable way:
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.
For rules with the "in" keyword, I cannot find any packet that don't have
the "recv" interface information set (count for rule #2 == #6 == #3 + #4 +
#5).
For rules with the "out" keyword, the xmit interface is also always
indicated (#7 == #15 == #12 + #13 + #14).
However rules with the "out" keyword may loose the "recv" interface
information (#7 != #11). I first thought that maybe the diversion to natd
was causing this (not shown in the above snippet), but the number of packets
that have been diverted is equal to the number of packets that have "recv"
interface information with the "out" keyword (rule #11).
The test traffic included pings from the host, going through the host (this
is my router to the internet), from the host to the host itself.
I am getting increasingly confused with all of this, and any word of wisdom
would be greatly appreciated.
Specifically:
- is it possible to have no "recv" interface with the "in" keyword ?
- what makes the "recv" interface information unavailable for "out" rules ?
Could it be that locally generated packets are never subjected to the "in"
rules ?
Thanks in advance!
Patrick.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?NDBBIMKICMDGDMNOOCAIGEENCEAA.patrick>