> 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 ?) -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
