Re: ebtables processing...
- From: Pascal Hambourg <boite-a-spam@xxxxxxxxxxxxxxx>
- Date: Wed, 17 Sep 2008 14:16:40 +0200
shokwave a écrit :
Because when I try to set up ebtables on my router to just use a
default DROP policy, I can no longer ping the router.
May I ask why on earth do you want to set a default DROP policy in the broute/BROUTING chain ? What is your goal ?
That's what I initially started off with, thinking the following would
happen
1) packet comes in
2) -t broute BROUTING table says "send this up to the routing code"
3) since the router, at 192.168.1.1 is the one being pinged, the
loopback should catch this, and the ping should reply
Are you talking about the loopback interface lo ? If so, what does it have to do here ? It only concerns traffic from a host to itself.
btw: eth0 (my client PC connected to router) and atm0 are in br0
bridge)
If you try to ping the router's address from the client, packets arrive on eth0, not atm0.
Also, I'm afraid your plan forgot about the ARP protocol, as mentionned by David. Here is what probably happens.
The client wants to send an IP packet with an ICMP echo request (ping) to 192.168.1.1. Before it must learn the associated MAC address using the ARP protocol, which is distinct from IP. It broadcasts an ARP query for 192.168.1.1 on the link. The ARP query arrives at the interface eth0, which is part of the bridge br0, so the packet goes through ebtables and reaches the BROUTING chain in the broute table. As the packet does not match the only rule in that chain, the default policy DROP is applied. As you know, DROP in that chain means that the packet must be "routed" instead of bridged. So instead of being handed to the bridge, it is treated as a regular packet received on eth0. If eth0 is bound to the IPv4 stack [1], it is handed to the ARP layer of the network stack.
You can check which interfaces are bound to IPv4 with :
$ ls /proc/sys/net/ipv4/conf/
Note that an ethernet interface is not bound to IPv4 stack by default, until an IPv4 address is assigned to it. You can bind an interface without assigning it an address with :
$ ifconfig <interface> 0.0.0.0
Let's assume eth0 is bound to the IPv4 stack. So the ARP request is handed to the ARP layer. By default the ARP layer sends a reply for 192.168.1.1 through eth0 with the MAC address of eth0 to the client.
Now the client can send the IP packet containing the ping request to 192.168.1.1 using the MAC address of eth0 advertised in the ARP reply. The paquet arrives at eth0 and reaches the BROUTING chain in the broute table. As the packet matches the only rule in that chain, the target ACCEPT is applied, meaning that the packet is handed to the bridge. The destination MAC address is known by the bridge as "local", because it belongs to one of the bridged interfaces. So the packet is delivered to the local IPv4 stack as received on br0.
Now the router wants to reply to the ping. Its IPv4 routing table tells it that the destination is reachable via br0, so the information from the previous ARP request received on eth0 is ignored. It broadcasts an ARP query on br0, and expects a reply received on br0. But the ARP reply won't match the ebtables rule, so it will be "routed" and received on eth0 instead of br0. The router does not receive an ARP reply on br0 and cannot send the ping reply.
.
- References:
- ebtables processing...
- From: shokwave
- Re: ebtables processing...
- From: Pascal Hambourg
- Re: ebtables processing...
- From: shokwave
- ebtables processing...
- Prev by Date: Re: Max IPSEC tunnels
- Next by Date: Re: tcpdump and http
- Previous by thread: Re: ebtables processing...
- Next by thread: Re: Max IPSEC tunnels
- Index(es):
Relevant Pages
|
