Hi all!

I have a quite strange problem on one of my linux servers running Slackware 14.1 64 bit.

Actually the server runs on a vmware virtual machine which has attached 4 different virtual ethernet interfaces. All these 4 interfaces are connected to the same physical interface via a vmware virtual switch (actually the virtal switch just bridge the interfaces).

Moreover I have iptables running as firewall filtering different type of incoming packets on the base of destination IP, destination interface and destination port.

In general this configuration seems to work perfectly but sometimes (apparently randomly and rarely) it happens that iptable drops connections that should be allowed because the interface names are somehow mixed up. In particular according to ifconfig I have the following situation:

eth0 --> XXX.XXX.XXX.2
eth1 --> XXX.XXX.XXX.3
eth2 --> XXX.XXX.XXX.4
eth3 --> XXX.XXX.XXX.5

To allow ssh connection only on IP:XXX.XXX.XXX.2 on port 22 and on the interface eth0 I have the iptable rule like:

iptables -A INPUT -p tcp -s IP_SOURCE -d XXX.XXX.XXX.2 --dport 22 -i eth0 -j ACCEPT

where IP_SOURCE is the ip address I want to allow to connect to the server.

Similarly, I have other rules allowing http connection on the other interfaces and IPs.

As already mentioned, this configuration works in general well but sometimes it happens that iptable drops for example ssh connection because apparently they have the correct destination IP and port but the wrong destination interface.
For example if I try to connect to the server from an allowed IP via ssh, my connection gets dropped and in the iptable log file I found:

Mar 24 13:20:36 xxxxxxxxx kernel: [2682350.220828] IPTables- DROPPED INPUT: IN=eth3 OUT= MAC=XXXXXX SRC=YYY.YYY.YYY.YYY DST=XXX.XXX.XXX.2 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=22947 DF PROTO=TCP SPT=55423 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0

where YYY.YYY.YYY.YYY is the IP from which I'm trying to connect to the server.
As you can see, for some reason, iptables seems the connection directed to the right IP but to the WRONG interface (eth3 instead of eth0) and so the connection is dropped.

This happens also for http connections.

If, in this condition, I reboot the server everything works again perfectly (it means I'm able to connect from the same IP that before was dropped without changing anything in both the server and the client).

The system log files are clean and do not report any problem to any of ethernet interfaces or connection drops.

Actually I have no idea what exactly generates the problem. I'm quite sure iptable and Slackware network is configured property because the problem appear only rarely. Most of the time the server works perfectly. On the other side I don't think it is a vmware problem because in that case it wouldn't be fixed by a server reboot...

I'm confused....

Any idea?

Thanks a lot for your attention!

I'm not sure what's causing that - maybe some udev strangeness? but as an aside if your ip addresses rules are constant, do you absolutely need to specify the interface? For instance why not omit it?

Thanks a lot for the feedback!

Actually I also had your same idea to not specify the interface in the iptable role. At moment this is the firewall configuration I'm using. Anyway I consider this only a partial solution because I would like to better understand what is really going on the server and why my initial configuration does not work as expected...

Is the interface actually changing names? As in, is eth0 not consistently associated to the same MAC?

If that is the problem, you could look into some static udev rules, there's a few examples out there, I found this for example. I've found in Slackware 14.1 there is already a rule file that ties the interfaces together consistently. What do you have under:
Secondly, how is the addressing on the linux VM allocated - is it via DHCP, or a static address? I'm wondering if DHCP is renewing the address on the interface and they're getting swapped around, although this doesn't seem likely.

Maybe this will help https://kindlund.wordpress.com/2007/...utes-in-linux/

I think this is not my case. The association between interface name and MAC address does not change. Even in the part of iptables log file I have reported above, the MAC address is the one corresponding to the eth3 which is always the same independently from the problem.

Thanks for the link! However the problem described there is a bit different from my case where the interfaces seems to get mixed up while the system is running and not at the boot.

Anyway the file you mentioned is empty on my system.

All the interface IPs are statically addressed.

Thank you very much for the support!

Hi Richard and thanks for the interesting link!

Anyway I think it does not apply to my case where all the interface IPs belong to the same subnet. Is my supposition correct?

No, I don't think that has much to do with it. I believe that you'll need specific routing rules to ensure that packets coming in via eth0 are responded to via eth0 and so on. Maybe that's been fixed in later kernels.

Ok I see the point. But I'm not sure this will fix the problem. In my case the incoming connections seem to be sent via the wrong interface (and the correct ip). While in the case described in the link the pockets coming out from the server could be sent via the wrong interface. Even if this happened how the packets sent by the client could be influenced by that?

Moreover in my case the default interface is eth0 which is also the interface used by ssh connections. So apparently there are no reasons for which this interface could be mixed with eth3. Maybe the communications via eth3 could be sent back by the server via eth0 and not the opposite.

Does all this make sense?

Thank you for your attention.

Well, at some point it depends upon the application.

An application can explicitly state that it wants its end of a TCP socket to use address XXX.XXX.XXX.2. An application can also state, "I don't care what endpoint I'm using on this end, I just want to talk to (some other address)." Both scenarios use your routing tables in a different fashion.

I guess that I'd ask how do you know, exactly, that ssh will go over eth0? Is that your gateway interface? What is the output of "route -n"? How about "route -n"? (You should examine both of those before you post to ensure that we don't see things that you don't want to be seen. It might be easier if you run both without the -n flags.)

I think that you should run the arp command as root and see what your system has decided what your routing should be. Some of the routing logic will exist on whatever switch is between you and the greater internet.

Hi again!

yes, eth0 is my gateway interface. Moreover I can assure you that before posting I checked several times the output of both route and arp commands without find any valid reason to explain the behavior I see.

But you are right I should have mention that.

Anyway this is the output of the "route -n"

I think in this particular situation the output of the "arp" command is not so useful because on the server is stored only the arp table relative to the local subnet. As I'm trying to connect from a different subnet the relevant arp table is stored elsewhere (as you said on switch between the server and the greater network) where unfortunately I cannot access to.

Finally the ssh is configured to listen only on the ip assigned to eth0. So I suppose that (at least at server level!) all the ssh connections (incoming and outcoming) should go via eth0.

Really thanks for the help and patience!

Did you also use 255.255.255.128 for the netmask on your interfaces, or just the routing entries? I don't know what you're trying to achieve with this set-up, but it looks like the destination and netmask values of the routing entries for eth0-3 don't match their addresses. Also your default gateway doesn't appear to be in the same subnet as any of your interface addresses.

Obviously I don't have full information so I may be missing some critical information, but the whole set-up looks somewhat odd, though admittedly it will sort of work. I guess I'd just feel more comfortable if it had a xxx.xxx.xxx.0 rule in there to match the local interface addresses and wasn't routing local traffic through the default gw. (though that probably doesn't have any bearing on your issue, so apologies for the noise.).


If you're going to want to make specific protocols always use specific interfaces then I think you're probably going to have to delve into NAT and iptables 'mangle' rules, at which point you kind of get into a "is it worth the pain" sort of deal.

You are right!

I have made a bit of confusion while posting... Sorry for that.

The details of my network configuration:

All the 4 interface are in the subnet

xxx.xxx.xxx.128/25

with gw:xxx.xxx.xxx.129.

Actually the IPs associated to the interfaces are:

xxx.xxx.xxx.216 (eth0)
xxx.xxx.xxx.217 (eth1)
xxx.xxx.xxx.218 (eth2)
xxx.xxx.xxx.219 (eth3)

The IPs I wrote in my first post (xxx.xxx.xxx.2, xxx.xxx.xxx.3,...) were just a (not relevant!) example to describe the background configuration.

I apologize for the mess.

1 members found this post helpful.

np, that kind of makes more sense now. Thanks for clarifying.

Probably I miss something important (I'm not an expert in network theory!) but I think this would not solve my problem.

Let' suppose one client tries to connect via ssh to the server using the IP xxx.xxx.xxx.216 (for example typing "ssh user@xxx.xxx.xxx.216") . So to encapsulate the ssh packet it needs to know:

- Source MAC address
- Source IP
- Destination IP
- Destination MAC

The first three items in my case are supposed to be known. The only missing information is the destination MAC which should be obtained using ARP (sending out an ARP query packet to resolve an IP address to a MAC address). According to my knowledge, an ARP request is basically just a broadcast that says "whoever has IP address xxx.xxx.xxx.216, send me your MAC address". ARP tables are build up on the base of these requests and they are stored on routers and computers as well. If the client and the server are not in the same subnet (as in my case) the relevant ARP tables are stored somewhere on the routers between the two machines.

So it sounds that occasionally and for an unknown reason, the IP xxx.xxx.xxx.216 is not associated to the MAC address of eth0 within these ARP tables, but to a MAC address corresponding to another server interface. So, basically, the understanding of why this happens will fix my problem.

I can see only one reasons for which this could happen:

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.

I consider really unlikely an issue in the ARP cache of the router because in that case I would not be able to explain why this happens only for this particular server and not for the others ones on my subnet having similar configuration.

Am I missing (or misunderstanding) any other important thing??