Re: FW: Reject on a Bridge

["Gilad Benjamini" <gilad.benjamini@gmail.com>]

>  On 09/03/08 17:41, Gilad Benjamini wrote:
>  > I am using iptables to run a firewall on a bridge. The bridge
>  > consists of eth1 and eth2. Neither interface, nor the bridge itself,
>  > have an IP address. eth0, which is not on the bridge, does have an IP
>  > address.
>  >
>  > Trying to use the REJECT target with --tcp-reset doesn't work. If I
>  > understand the code correctly, the route for the RST packet is
>  > determined through ip_route_me_harder in the send_reset function,
>  > implying in my case that the RST packet will leave through eth0,
>  > which is not the desired behavior. Theoretically, eth0 might be even
>  > physically disconnected from the bridged network.
>  >
>  > Am I missing something, or is this a real problem ?
>
>  I'm not sure where the rejection is going to come from.  At least as I
>  understand it the rejection comes from a system (with an IP) in the path
>  that is refusing to pass the packet.  Thus I don't see how the bridge
>  can reject the packet because there is no source IP to send the
>  rejection from.  Can you add an IP to the bridge interface that is with
>  in the subnet that is being bridged through it so that there is a source
>  IP for the rejection?
>
>
>
>  Grant. . . .

The way I see it, a firewall is allowed to "pretend" to be the end
point, without revealing itself as a separate entity. Network devices
do this in different scenarios; e.g. NAT, proxy-ARP, DHCP-relay.
In this case, the "pretending" part would be to send a RST packet with
reverse addresses. Actually, this is exactly what the send_reset
function does, including IP addresses, but excluding MAC addresses,
which are determined elsewhere (routing code ?)