Strange ethernet interface/iptable problem on Slackware 14.1

Markus Wiesner · 03-29-2016, 02:01 PM

Quote:

Originally Posted by gda

the server (occasionally!!) provides wrong MAC address to the ARP request looking for the MAC associated to the IP xxx.xxx.xxx.216. Basically the Arp reply should contains always the MAC associated to the IP xxx.xxx.xxx.216 (eth0) as long as this association does not change on the server somehow... Any explanation on how this could happen??? I have no idea? Driver problem? All my interfaces use 'e1000' driver.

Probably not a bug but a feature.

Try this:

Code:

sysctl -w net.ipv4.conf.eth{0..3}.arp_ignore=1

From https://www.kernel.org/doc/Documenta.../ip-sysctl.txt

Code:

arp_ignore - INTEGER
	Define different modes for sending replies in response to
	received ARP requests that resolve local target IP addresses:
	0 - (default): reply for any local target IP address, configured
	on any interface
	1 - reply only if the target IP address is local address
	configured on the incoming interface
	2 - reply only if the target IP address is local address
	configured on the incoming interface and both with the
	sender's IP address are part from same subnet on this interface
	3 - do not reply for local addresses configured with scope host,
	only resolutions for global and link addresses are replied
	4-7 - reserved
	8 - do not reply for all local addresses

	The max value from conf/{all,interface}/arp_ignore is used
	when ARP request is received on the {interface}

gda · 03-30-2016, 04:47 AM

Markus you are absolutely right! Thanks a lot for the suggestion! Now everything is more clear to me...
What I thought it was a problem actually is the default behavior to reply to ARP requests in case of server with multiple interfaces in the same network!

This is also confirmed by the some tests I have made which I report below.

First of all I set up a test client in the same subnet where the server is. I did that to be able to capture the ARP traffic (in particular the ARP replies from the server) running tcpdump from the client.

So my testing configuration is:

Server

interface name: eth0
MAC: 00:50:56:9f:5c:7a
IP: xxx.xxx.xxx.216

interface name: eth1
MAC: 00:50:56:9f:10:55
IP: xxx.xxx.xxx.217

interface name: eth2
MAC: 00:50:56:9f:5b:43
IP: xxx.xxx.xxx.218

interface name: eth3
MAC: 00:50:56:9f:5e:f0
IP: xxx.xxx.xxx.219

Client

interface name: eth0
MAC: 00:50:56:9f:74:cf
IP: xxx.xxx.xxx.222

With the server in the original configuration I just run on the client first the command

Code:

#tcpdump arp

and then (using another terminal) I tried to ping xxx.xxx.xxx.216. This is the output tcpdump captured:

Code:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:54:22.741072 ARP, Request who-has xxx.xxx.xxx.216 tell xxx.xxx.xxx.222, length 28
08:54:22.741570 ARP, Reply xxx.xxx.xxx.216 is-at 00:50:56:9f:10:55 (oui Unknown), length 46
08:54:22.741588 ARP, Reply xxx.xxx.xxx.216 is-at 00:50:56:9f:5b:43 (oui Unknown), length 46
08:54:22.741590 ARP, Reply xxx.xxx.xxx.216 is-at 00:50:56:9f:5c:7a (oui Unknown), length 46
08:54:22.741632 ARP, Reply xxx.xxx.xxx.216 is-at 00:50:56:9f:5e:f0 (oui Unknown), length 46

So independently from which interface is actual associated to xxx.xxx.xxx.216, ALL the four interfaces replied to the ARP request from the client. I suppose the client just get the first one (in this case eth1) to encapsulate the ethernet packet. Probably this is done because most of the applications don't care about the information reported in the layer 2 ethernet frame and so in most of case where there are multiple interfaces in the same subnet on the same server it doesn't really matter which is the actual interface used to communicate. Anyway applications like iptables, if configured properly, can detect that (as it happens in my case

).

Finally I tried the commands suggested by Markus (with some slight modifications). So on the server I executed:

Code:

# sysctl -w net.ipv4.conf.all.arp_ignore=1
# sysctl -w net.ipv4.conf.all.arp_announce=2

I captured again the ARP traffic from the client (after having cleared the ARP cache on the client) and this is what I got:

Code:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes        
09:02:37.890895 ARP, Request who-has xxx.xxx.xxx.216 tell xxx.xxx.xxx.222, length 28
09:02:37.891353 ARP, Reply xxx.xxx.xxx.216 is-at 00:50:56:9f:5c:7a (oui Unknown), length 46

As you can see this time only eth0 replies and the other 3 interfaces are silent!

I think the sysctl reported above definitely fix my iptable problem!

Thanks everybody for the help and support!

Markus Wiesner · 03-30-2016, 05:52 AM

Quote:

Originally Posted by gda

and then (using another terminal) I tried to ping xxx.xxx.xxx.216. This is the output tcpdump captured:

Glad i could help.

Just a little hint: you could use arping (also part of the iputils package) instead of ping+tcpdump

Code:

# arping -I eth0 -b 10.0.0.1
ARPING 10.0.0.1 from 10.0.1.77 eth0
Unicast reply from 10.0.0.1 [xx:xx:xx:xx:xx:xx]  0.764ms
Unicast reply from 10.0.0.1 [xx:xx:xx:xx:xx:xx]  0.849ms

It will show multiple responses, too, and you don't have to clear the ARP cache. Additional benefit: you can „ping“ firewalled hosts, because they still respond to ARP requests. Of course, it only works within the same LAN and not across routers.