On Monday 30 June 2003 03:48, sword wrote: > Author think that the rule will stop the connection between two PCs at > the same side of the Bridge Firewall if they want to setup a connection > ,because when they are trying to find eachother's postion in the LAN the > Packet they sent will be sent every port of Bridge,and this PACKET will > match the iptables rule,so the PACKET will DROP,and connection will STOP! I > think the Procedure of address searching of PCs connected to the bridge is > sending FRAME ,Not PACKET ,so iptalbes will not see this FRAME,so this > rule will not make that outcome at all, am I right?
Obviously, the bridge has no control over communications between hosts on the same side of the bridge. I didn't read the article, but if it assumes it has, it's wrong. Address resolution is done with ARP. > So, say A decides to send a packet to B after B's address has timed out. > Even though the packet is not destined to host C, the flooding process > within the bridge firewall's bridging module will queue a copy of the > packet for transmission on C's segment. And this is exactly where the > problem lies. The packet from A to B that is also sent to the bridge > firewall's eth1 interface will match the rule: > > # iptables -A FORWARD -i eth0 -o eth1 -j REJECT --reject-with tcp-reset > and therefore, the firewall will send a RST packet which will abort the > connection between A and B. This is certainly not what you had intended, > and what's worse, this spurious aborting will seem to happen randomly. True. Filtering on a bridge is not as straightforward as on a router. cheers, Bart _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
