Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 2 subscribers
  • Views 9852 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARP table error / wrong ARP response from UTM?

Vasteel
Hello,

I recently upgraded from Astaro ASG 8 to Sophos UTM 9, hoping that my problem will solve itself, but unfortunately it didn't...

I'm using the software appliance/personal edition on a classic PC, that has 4 interfaces (internet network, wifi network, wired network, VM network).
eth0 is assigned to wifi network
eth1 is assigned to wired network
eth2 is assigned to internet network
eth3 is assigned to VM network

My DNS servers are on 2 virtual machines, located behind eth3.
My PC, my wife's Mac Mini, and our media center are wired, located behind eth1.
(I placed a rule allowing DNS requests from these 3 PCs to the DNS servers)


Here is the problem :
Every time I power on any of the 3 machines located behind eth1, I can't "get access to the internet" for at least 1 minute or 2.

When I dig a little bit, I notice that I don't have DNS resolution within these 1-2 minutes I have to wait for (hence the lack of internet connectivity).

Actually, if I dig deeper, I can see that the ARP table (on every machine) is false : the wired network gateway interface's MAC address should be eth1's MAC address, but is actually eth0's MAC address!
At least for these 1-2 minutes... Once the MAC address has been corrected in the ARP table, everything goes back to normal.
(fig1.jpg : ARP table after boot up, then after waiting for a few minutes)

Of course, as long as the ARP table is false, the DNS request packets are not really properly routed through the UTM, and I get "default drop" messages in the firewall log.
(fig2.jpg : firewall log showing the wrong dstmac for a while, then the good one)


In a way, this is not a serious issue for the PC and the Mac Mini, but on the media center (Ubuntu-based XBMC), the ARP table can take 5 to 10 minutes to be refreshed.
(I'll let you imagine what happens when I'm not home and my wife can't watch her favorite shows on the media center at once after booting it up...)


Well, I suppose there is a slight problem with the ARP response packets the first time the UTM sees a machine on the wired network.

Is there something I have to set up to fix this issue?
Any help would be greatly appreciated!
Thanks a lot in advance!


This thread was automatically locked due to age.
  • 0
    Hi, switches are sometimes configured with STP which is extremely slow to allow new connections. RSTP is a faster option, if you even need STP at all (you don't need it if you only have 1 switch).
    Spanning Tree Protocol - Wikipedia, the free encyclopedia

    If it's not the switch, maybe you have something mis-wired where 2 networks are physically connected.

    It's also conceivable that it's a NIC problem, but I doubt it.

    Barry
  • 0
    Please check your network wiring. Linux by default will reply with ARP requests for all IP address on any Interface. E.g. if your system receives an ARP request for x.x.x.x which is configured on eth0 on eth0 AND eth1, it will reply twice (once with MAC from eth0 on eth0 and once with MAC from eth1 on eth1).

    To disable this feature, you can set interfaces->arp_ignore to 1 via confd command line
    or do a proper network segmentation.
  • 0
    Thank you for all your answers!
    I finally found where the problem was. (I feel a bit dumb on this one)

    I was pretty sure there was no mis-wire (at least from an ethernet point of view).
    But I forgot the PLC plugs I had in my house (2 pairs, one on the "wired" network, one on the "wifi" network).

    I had to encrypt one pair, to be sure one couple won't see the other (and join the 2 networks).
    However, I had some bandwidth issues a few weeks ago, and had to apply a firmware patch on 2 adapters to correct it.
    It didn't even occur to me that some parameters might have been reset to factory values, thus disabling encryption on the patched pair...
    I enabled encryption again, and everything is now back to normal!

    Not a UTM problem, after all.
    Again, thank you for all the answers you provided!
Unfiltered HTML