Re: ipfw: manpage: semantics of "receive" and "xmit" interfaces

From: Andrey V. Elsukov <bu7cher_at_yandex.ru>
Date: Tue, 9 Jan 2018 21:23:54 +0300
On 09.01.2018 12:28, O. Hartmann wrote:
> In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is
> also an example:
> 
> ipfw add deny ip from any to any out recv ed0 xmit ed1
> 
> Can someone explain a bit more what the semantics of these is? I get especially
> confused by the subsequent blocks of text following the line I mentioned above.
> Since not everybody using FreeBSD is capable of studying the kernel sources, I
> have difficulties to put those statements in line with a visualization of the
> packet flow. A local host receiving a packets destined for the local host can
> not have xmit interface? If I imagine, that the recv interface might be the
> interface adjacent directly to the in/out port depicted in section PACKET FLOW
> it doesn't give me any idea why there is no xmit interface. 

When your system has two interfaces ed0 and ed1, and it acts as router,
a forwarded packet can be checked by firewall two times:

1. When a packet is received on ed0 interface, mbuf associated with this
packet gets a property "receiving interface". This packet is checked for
inbound direction and can be matched by "in" and "recv ed0" opcodes.
If it was not dropped by rules, it will go through IP stack and can be
forwarded according to routing table via interface ed1.

2. When the routing decision was made (i.e. outbound interface is
determined) a packet checked by firewall again, now for outbound
direction. And it can be matched by "out" and "xmit ed1" opcodes. The
opcode "recv ed0" still can be matched too, but "in" opcode will not
matched.

A packet destined for local host is consumed by local IP stack and will
not forwarded. It is checked by firewall only one time (usually). Thus
it can not have xmit interface.

-- 
WBR, Andrey V. Elsukov


Received on Tue Jan 09 2018 - 17:26:19 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:14 UTC