Inbound Network Traffic Popup following Duplicate IP Event

[Chelik 0]

At one point yesterday i received a popup about a duplicate IP address and an ARP Poisoning attack. Looking at the source and target it appears they were between my two ASUS Mesh routers (ZenWiFi_XT8). When investigating further it appears one received a firmware upgrade while the other did not. I have since pushed through an upgrade and both are showing the same firmware. Oddly enough the notes include a bullet point about fixing an ARP poisoning vulnerability, so i'm guessing this is related.

However, since then I keep receiving an inbound network traffic popup that just started yesterday. I believe it is associated with the svchost.exe. My network is associated with 192.168.50.x so i'm not sure why this is looking for 192.168.1.1.

How do i best confirm that this is something that i should approve/deny and why would this be popping up now?

[Marcos 5,143]

A pcap log should also show the ICMP communication with 192.168.1.1 so it's not something that ESET would made up. By default all outbound communication is allowed so I assume you have modified all or some of the default firewall rules.

[itman 1,707]

Here's what I believe is the issue.

Due to the firmware updating issue, somehow both routers were assigned the same IP address, 192.168.1.1. Appears one of the router's is trying to communicate with the other via ICMP and Eset is blocking the inbound network traffic due to the identical IP address issue.

The simple solution might be to reset one of the routers which will hopefully via Win DHCP processing, assign it a different IP address.

Edited May 24 by itman

[Chelik 0]

First off thank you both for your responses. I have some questions based on those:

@Marcos to capture this pcap log is that through ESET or do i need to capture it with something else? I tried a couple of settings within Eset Advanced Setup>Tools>Diagnostics>Advanced Logging and tried enabling 'Network protection advanced logging' and 'Network traffic scanner advanced logging'. When opening up the files stored in the diagnostics folder using Wireshark I wasn't able to find the string associated with 192.168.1.1, so wondering if i did not choose the correct function to log.

 

@itman when looking at the IP address for both routers (main and mesh node) the main is 192.168.50.x and the node is applied the IP address that i manually had chosen. With this being the case do you still feel its worth resetting (factory?) the node router?

[itman 1,707]

12 hours ago, Chelik said:

At one point yesterday i received a popup about a duplicate IP address and an ARP Poisoning attack. Looking at the source and target it appears they were between my two ASUS Mesh routers (ZenWiFi_XT8).

If the above is correct, it would indicate that the same IP address was assigned to both routers on your local network.

1 hour ago, Chelik said:

when looking at the IP address for both routers (main and mesh node) the main is 192.168.50.x and the node is applied the IP address that i manually had chosen.

For some unknown reason, Eset is not detecting the manual router address assignment you performed.

The quickest way to resolve this is to create an ARP poisoning exception for 192.168.50.x. Refer to this article: https://support.eset.com/en/kb2933-arp-icmp-or-dns-cache-poisoning-attack-in-eset-home-products-for-windows . If this doesn't work, create the exception for the node manually assigned address. If that doesn't work, create the exception for both router IP Addresses.

Edited May 24 by itman

[Chelik 0]

1 hour ago, itman said:

What IP address did Eset show in the ARP poisoning alert - 192.168.1.1? Is 192.168.1.1 the assigned IPv4 address for the device where the ARP poisoning alert occurred?

 

Eset showed 192.168.50.x and the node MAC address as the source with the target being 192.168.50.x and the main router MAC address. Which this was around the time that the main router firmware was upgraded but the node router was not. I have since upgraded the nodes firmware. The main router is 192.168.50.x and the node is 192.168.50.y which i have confirmed i can access the routers gui by using those IP addresses.

So I'm not sure if duplicate IP is still an issue, but i was thinking this was a catalyst to the issue that i screenshoted in the original post. Since then i repeatedly get the inbound network traffic popup saying that a system app is repeatedly trying to connect to 192.168.1.1 which I'm assuming this should be pointing to 192.168.50.x. Would it be worth trying to run the Eset DNS Flush tool? I have other computers with Eset that so far are not getting this error, but they were not on at the time of the duplicate IP issue that the computer that is experiencing this popup issue. As far as i can tell it looks like the system application is svchost.exe.

But i haven't been able to figure out anything from the pcap logs Marcos mentioned, but i'm not sure if i logged the correct setting for capturing that information.

Edited May 24 by Chelik

[Chelik 0]

Some additional information during the ARP poising attack there are 10 events within a 4min time frame with the node as the source and main router as the target. 10 minutes after the last ARP event there are 7 duplicate IP events that some are node as the source with target of the main router and the others with the main router as the source and node as the target.

The ARP events are marked as blocked and the duplicate IP events are marked as allowed.

[itman 1,707]

Did you try the ARP poisoning exclusions I suggested?

[Chelik 0]

8 minutes ago, itman said:

Did you try the ARP poisoning exclusions I suggested?

I will try that now. I would have preferred to not have to add an exclusion as i'm not sure why this even started to begin with. I will report back if i experience any more issues and if not can mark your reply as the solution. Thank you for the support so far.

[Chelik 0]

3 hours ago, itman said:

Did you try the ARP poisoning exclusions I suggested?

Unfortunately, this exception did not appear to work as i'm still getting the popup associated with the system to 192.168.1.1.

[itman 1,707]

12 hours ago, Chelik said:

Unfortunately, this exception did not appear to work as i'm still getting the popup associated with the system to 192.168.1.1.

Identify what device on your local network is associated with IP address  192.168.1.1. I assume it's the PC your currently using.

So why would Eset block inbound ICMP network traffic from your PC to what I believe is one of your router's broadcast IP address; i.e. 192.168.1.255. Well in reality, it's actually outbound network traffic. You say what???

I have seen this Eset behavior before on my PC and it usually occurred upon resume from sleep mode. It originated from an Ethernet powerlink adapter that functioned as an ADSL router. In other words, I had two routers on my local network just like you. It appears there is an Eset firewall startup timing issue with this two router network configuration scenario. The PC is sending normal outbound local network ICMP traffic to router's broadcast address for connectivity purposes. The Eset firewall initializes and interprets the traffic as inbound network traffic and blocks it.

You have two options;

1. Ignore the blocked inbound ICMP alert if only a few are displayed.

2. Create an Eset firewall rule to allow the inbound ICMP traffic from remote IP address, 192.168.1.1.

Edited May 25 by itman

[itman 1,707]

There is another solution that might work in your case since you stated you had no Eset networking issues until you performed a manual firmware update to one of your mesh routers.

Remove the ARP poisoning exceptions. Export your existing Eset settings. Uninstall Eset. Reboot. Install Eset and then import your existing Eset settings.

Eset sets up its internal network settings based on your local network configuration at installation time. Hopefully, this will resolve all your prior issues.

[Chelik 0]

@itman Thank you for all the support.

This morning i ran a test and changed my gateway IP address to 192.168.1.1 to test something. I ran into the ARP poisoning again but this time it was with a different device than my second router. The error that popped up for the inbound traffic point to a fios-gateway. I then noticed that my fios router (which had been configured in bridge mode) had a red light that i can't remember if it had been there or if this is something new. It hadn't occurred to me to check that since it at been in bridge mode. So my current thought is that i'm going to unplug it from the network and monitor to see if i get any more errors. If not then i'm guessing this is the device that i need to look into. Perhaps there is a hiccup with it and am looking to reset it and reconfigure it back into bridge mode.

If none of this works then i'll follow your next steps.

Edited May 25 by Chelik

[Chelik 0]

Looks like that was the issue. I was able to reset the fios router and reconfigure it to bridge mode. Have not ran into the popup error anymore so far for the last 18hrs, but will continue to monitor. I'm guessing with the firmware not updating correctly it caused a hiccup with the network setup.

I don't think i would have figured this all out as quickly without your assistance @itman, so thank you again very much. I'm not entirely sure which one specifically i should mark as the solution as i think it was a combination of your responses which lead me down the path to find. If there's one specifically you feel works as being the solution please mark it as such or let me know which you would like me to mark.