Can't remove ARP Spoofing attck

[Edward_Walker]

Note: Please do not post Personally Identifiable Information like email address, personal phone number, physical home address, product key etc.

Issue abstract: Can’t detect or remove a known ARP spoofing attack in on my network. I’ve enabled all security and firewall settings. Run full & startup scans. An ARP detection app still identifies and shows all of the ARP spoofing changes in real time. I have a small home network that is compromised by this attacker. Need help to remove it somehow.

Detailed description: Norton 360 Deluxe

Product & version number: Latest edition

OS details: Win 11 Home

What is the error message you are seeing? 1 Device on the network received a Norton popup that it detected ARP Spoofing but no fix or action was provided

If you have any supporting screenshots, please add them:

[bjm]

@Edward_Walker

Can’t remove ARP Spoofing attck
Can’t detect or remove a known ARP spoofing attack in on my network. I’ve enabled all security and firewall settings. Run full & startup scans. An ARP detection app still identifies and shows all of the ARP spoofing changes in real time. I have a small home network that is compromised by this attacker. Need help to remove it somehow.
1 Device on the network received a Norton popup that it detected ARP Spoofing but no fix or action was provided

Hello @Edward_Walker

ChatGPT: Did you already have the ARP detection application installed before the Norton alert, or did you install it afterward to investigate?

Could you post a screenshot of the ARP detection application’s findings? That would help determine exactly what it is detecting. If possible, also post a screenshot of the Norton ARP spoofing notification (or the corresponding Security History entry), as the exact wording and any associated details may help determine whether this is an actual ARP spoofing attack or a false positive.

If you post screenshots, please mask any personally identifying information such as your public IP address, Wi-Fi SSID, device names, and MAC addresses before uploading them.

ChatGPT: A Norton ARP spoofing notification indicates that suspicious ARP traffic was detected, but Norton does not generally remove an attacker from the network or automatically correct ARP tables.

Before concluding your network is compromised, it’s worth confirming that the ARP changes are actually malicious. Frequent ARP updates can also occur on some normal home networks, especially with mesh Wi-Fi systems, multiple access points, virtualization software, or certain routers.

Some questions that may help narrow this down:

• What operating system is the affected device running (Windows, macOS, Android, etc.)?
• Which Norton product and version are installed?
• What make and model is your router?
• What ARP detection application are you using, and what exactly is it reporting?
• Are multiple devices seeing the same activity, or only one?

If you believe an unauthorized device is present, I’d recommend:

• Log into your router and review the connected device list.
• Change the router’s administrator password if it has not already been changed from the default.
• Update the router’s firmware.
• Change your Wi-Fi password (WPA2/WPA3) and reconnect only your trusted devices.
• Reboot the router after making the changes.

The additional information above may help determine whether this is an actual ARP spoofing attack or a false positive.

========== == ========== == ========== == ========== == ==========

Leo AI: This is a serious security situation. If your Norton software has detected an ARP spoofing attack but provided no fix, and a dedicated detection app is still seeing changes in real-time, it means an active attacker is currently intercepting or manipulating traffic on your local network.

Here is the immediate step-by-step plan to stop the attack and secure your network:

1. Immediate Isolation (Stop the Bleeding)

• Disconnect from the Internet: Unplug the Ethernet cable or turn off Wi-Fi on the infected device immediately. Do not attempt to “fix” it while connected.
• Power Cycle the Router: Unplug your home router and modem from the power source for at least 60 seconds. This clears the ARP caches on all devices and the router itself.
  • Note: If the attacker has compromised the router’s firmware or admin password, a simple reboot might not be enough, but it is the necessary first step.

2. Identify the Attacker

Since you have an ARP detection app running, use it before reconnecting to the internet to identify the malicious MAC address.

• Look for a MAC address that does not belong to your known devices (phones, laptops, smart TVs) or your router.
• Check your Router’s Admin Panel: Log into your router (usually 192.168.0.1 or 192.168.1.1) and look at the “Connected Devices” or “DHCP Client List.”
• Match the MAC: Compare the suspicious MAC address from your detection app with the router’s list. If you see a device you don’t recognize (e.g., “Unknown,” or a manufacturer you don’t own), that is the attacker.

3. Secure the Network

Once you have identified the intruder (or if you cannot identify a specific device but suspect compromise):

• Change Wi-Fi Password: Change your Wi-Fi password immediately in the router settings. This forces all devices to reconnect with the new key, kicking off anyone who might have the old one.
• Change Router Admin Password: Ensure the attacker hasn’t logged into your router’s admin panel. Change the admin password to something strong and unique.
• Enable MAC Address Filtering (Optional but effective for home): If your router supports it, enable “Whitelist” mode. Only allow devices with MAC addresses you explicitly know and trust to connect. Block the suspicious MAC address.
• Disable WPS: If your router has Wi-Fi Protected Setup (WPS) enabled, turn it off. It is a common vulnerability used to gain network access.

4. Clean Infected Devices

The device that received the Norton popup might be the source, or a victim.

• Run a Full Scan: Run a full system scan with Norton (and a second opinion scanner like Malwarebytes) on the affected device while offline if possible, or immediately after reconnecting.
• Check for Rogue Software: Look for recently installed software that might be running ARP spoofing tools (e.g., “BetterCAP,” “Ettercap,” or generic “Network Scanner” tools) and uninstall them.

5. Long-Term Prevention

• Enable Static ARP Entries (Advanced): On your critical devices (PCs), you can manually bind the router’s IP to its MAC address.
  • Windows Command (Admin): arp -s <Router_IP> <Router_MAC>
  • Note: This must be redone if the router changes.
• Update Firmware: Check the manufacturer’s website for your router and update the firmware to patch known vulnerabilities.
• Use HTTPS Everywhere: Ensure you are using sites with HTTPS (look for the lock icon). This encrypts the data even if an attacker is spoofing ARP and trying to intercept traffic.

Why Norton Didn’t Fix It

Norton and similar antivirus tools are often detect-only for ARP spoofing because they cannot “fix” a network protocol issue without potentially breaking connectivity. They alert you because the attack happens at the network layer (Layer 2), which requires network hardware (router) intervention, not just software removal.

Recommendation: If you cannot identify the device or the attack persists after changing passwords and rebooting, the attacker may have physical access to your network (e.g., a neighbor or someone connected via a compromised smart device). In this case, consider resetting the router to factory defaults and setting it up as a new network.

LeoAI: Norton 360 uses its Intrusion Prevention System (IPS) and Network Threat Protection engine to detect ARP spoofing. This engine monitors network traffic for anomalies in the Address Resolution Protocol (ARP) layer. Specifically, it looks for “ARP poisoning” attempts where a device on the local network sends falsified ARP messages to link its MAC address with the IP address of a legitimate device (usually the router).

When Norton detects this, it typically generates a “Man in the Middle” or “ARP Spoofing” alert. However, the engine is heuristic and signature-based, meaning it flags the behavior of the traffic rather than identifying a specific malicious file on your disk. This is why the alert often appears without a “Fix” button: the antivirus cannot “delete” a network protocol attack; it can only block the traffic or alert you to the network misconfiguration.

Could the ARP Reporting Application Be the Cause?

Yes, it is highly possible. In many home network scenarios, the “attacker” Norton detects is actually a false positive triggered by legitimate network devices or the detection app itself.

Here are the common causes for false positives that mimic ARP spoofing:

1. Mesh Wi-Fi Systems and Access Points:

• Modern mesh systems (like Eero, Google Nest, or Netgear Orbi) often use a technique called ARP proxying or ARP caching to manage traffic between nodes. This behavior looks identical to ARP spoofing to security software because the router (or a mesh node) is responding to ARP requests for IP addresses that technically belong to other nodes.

• Users have reported that switching to mesh networks frequently triggers these specific Norton alerts, even when no attack is occurring.

2. Smart Home Devices (IoT):

• Devices like smart speakers (Echo, Google Home), NAS drives (Synology), or security cameras may send unsolicited ARP replies to optimize connection speeds or handle “wake-on-lan” features. Norton’s engine may interpret these unsolicited replies as an attack.

3. The Detection App Itself:

• If the “ARP detection app” you are using is actively scanning the network (sending probe packets) or running in a mode that modifies ARP tables to test for vulnerabilities, it can trigger Norton’s IPS. Norton sees this activity as an active attack and alerts you.
• Furthermore, if two detection tools are running simultaneously, they may conflict, causing one to flag the other’s scanning traffic as malicious.

4. Duplicate IPs or MACs:

• If you have two devices accidentally configured with the same IP address (or a device with a spoofed MAC address for privacy, like some phones do), Norton will flag this conflict as an ARP spoofing attack.

Recommended Next Steps

To determine if this is a real attack or a false positive:

1. Check the MAC Address:

• Look at the Norton alert details. Does it list the MAC address of the “attacker”?
• Compare this MAC address to the manufacturer list (OUI). If it belongs to a known router manufacturer (e.g., Eero, Netgear) or a device you own, it is likely a false positive caused by legitimate network behavior.
  .
• If the MAC address is unknown or generic, it is more suspicious.

2. Verify Network Topology:

• Did you recently install a new router, mesh system, or smart device? If so, the alert is almost certainly a false positive caused by the new hardware’s network management features.

3. Test with the Detection App Disabled:

• Temporarily disable the third-party “ARP detection app.” If the Norton alert stops, the detection app was likely the cause of the conflict or the trigger.

4. Use Wireshark (Advanced):

• For a definitive answer, use a tool like Wireshark to capture traffic. If you see legitimate devices (like your router) sending ARP replies, it confirms a false positive. If you see a device with no legitimate business replying to ARP requests for the gateway IP, it is a real attack.

Conclusion: While Norton’s engine is detecting real traffic patterns, it often misinterprets legitimate network management techniques (common in modern mesh Wi-Fi and IoT) as attacks. The “no fix” message is standard because the issue is usually a network configuration, not malware. If the MAC address in the alert belongs to your own hardware, you can likely safely ignore the alert or adjust your router’s settings to reduce ARP proxying.

AI sourced content may make mistakes

[bjm]

Hello @Edward_Walker
Care to share your progress
Thanks

[Edward_Walker]

I’ve been working through the list.

I installed a new WIFI router through a bridge mode on my ISP Modem and created a whole new locked down network

• My Router doesn’t provide the granular view of DCHP client list and neither Modem or Router has Address Filtering

  I’ve scanned the suspect PC with Norton, Malwarebytes & ESET Scanner- nothing found. I did find a program called WinPcap and unistalled it.

  I cleared the ARP cache and connected to the WIFI, immediately shut the WIFI down and looked at the ARP cache, it showed 3 different MAC for the device, 2 were Static,1 of them is ff-ff-ff-ff-ff-ff-ff, so clearly the attacker is still there.

[bjm]

@Edward_Walker

I’ve been working through the list.

I installed a new WIFI router through a bridge mode on my ISP Modem and created a whole new locked down network

• My Router doesn’t provide the granular view of DCHP client list and neither Modem or Router has Address FilteringI’ve scanned the suspect PC with Norton, Malwarebytes & ESET Scanner- nothing found. I did find a program called WinPcap and unistalled it.I cleared the ARP cache and connected to the WIFI, immediately shut the WIFI down and looked at the ARP cache, it showed 3 different MAC for the device, 2 were Static,1 of them is ff-ff-ff-ff-ff-ff-ff, so clearly the attacker is still there.

ChatGPT: This is exactly the kind of follow-up I was hoping for. It gives us actual troubleshooting steps instead of just conclusions.

That said, I think the OP may be drawing one conclusion that doesn’t necessarily follow from the evidence.

The sentence that concerns me is:

“I cleared the ARP cache… it showed 3 different MAC for the device… 1 of them is ff-ff-ff-ff-ff-ff… so clearly the attacker is still there.”

I would be very cautious with that conclusion.

About ff-ff-ff-ff-ff-ff

That MAC address is not the MAC address of an attacker.

FF-FF-FF-FF-FF-FF is the Ethernet broadcast MAC address. It’s a reserved address used by every Ethernet network. For example, an ARP request (“Who has 192.168.1.1?”) is typically sent to the broadcast MAC because the sender doesn’t yet know the destination’s MAC.

So seeing ff-ff-ff-ff-ff-ff in some networking contexts is perfectly normal. By itself, it is not evidence of ARP spoofing.

The “3 different MACs”

This depends entirely on what command they ran and what the ARP cache actually contains.

If they ran something like:

arp -a

it’s normal to see multiple entries, for example:

• the router
• the broadcast address
• multicast addresses
• perhaps IPv6 neighbor entries (depending on the tool)

The key question is whether the same IP address is associated with multiple different MAC addresses over time.

That’s what would be concerning.

WinPcap

Uninstalling WinPcap is probably unrelated.

WinPcap is (or was) a packet capture driver used by software like:

• Wireshark
• Nmap
• various network monitoring tools

Its presence alone is not evidence of malware.

The router

This is interesting:

“My Router doesn’t provide the granular view…”

That makes the investigation harder because ideally we’d compare Norton’s reported MAC against the router’s client list.

I’d want to ask one thing next

Rather than debating whether the attacker is still present, I’d ask:

Can you post the output of arp -a (with your public IP and any personally identifying information removed if desired), and the screenshot of the Norton ARP Spoofing alert?

Those two pieces together would tell us much more than the current interpretation.

---

One other thought: the OP says they:

• installed a new router,
• created a new network,
• scanned with three security products,
• cleared the ARP cache.

Those are significant troubleshooting steps. Yet the only remaining evidence they’re citing is their interpretation of the ARP table.

At this point, I think the investigation needs to shift from “I still have an attacker” to “Let’s verify what the ARP table is actually showing.”

Otherwise there’s a real risk of mistaking normal ARP behavior for proof of compromise.

So I’d be careful not to validate the statement:

“so clearly the attacker is still there.”

From what they’ve shared so far, I don’t think that conclusion has been established yet.

AI sourced content may make mistakes

[SoulAsylum]

@Edward_Walker May we ask:

-What is the maker and full model of the ISP device you have? Who is your ISP? Just asking that question to gather some basic information about your hardware and its capabilities.

-Do you have WiFi enabled on BOTH devices or disabled on your ISP device and are using your router’s wifi?

-What is the maker and full model of your personal router?

SA

[Edward_Walker]

Hi SA

ISP is Rogers Canada, device is an Xfinity Easy Connect 6300 and is in Bridge Mode (no WIFI enabled)

New WIFI router is D-Link R36 BE3600 WIFI 7

[bjm]

@Edward_Walker

ISP is Rogers Canada, device is an Xfinity Easy Connect 6300 and is in Bridge Mode (no WIFI enabled)
New WIFI router is D-Link R36 BE3600 WIFI 7

ChatGPT: This is getting more interesting. A few observations stand out.

First, the network topology is now much clearer:

Internet
    │
Rogers ISP
    │
Xfinity Easy Connect 6300
(Bridge Mode)
    │
D-Link R36 BE3600
(Wi-Fi router)
    │
LAN devices

With the Xfinity gateway in bridge mode and its Wi-Fi disabled, you’ve eliminated one common source of odd behavior (double NAT, competing DHCP servers, dual Wi-Fi networks). That’s a good troubleshooting step.

However, one statement still concerns me:

“I cleared the ARP cache… it showed 3 different MAC for the device… 2 were Static, 1 was ff-ff-ff-ff-ff-ff… so clearly the attacker is still there.”

I don’t think that conclusion follows.

I would want to know exactly what “3 different MACs” means.

For example, was this from:

arp -a

If so, what were the three entries?

Because:

• ff-ff-ff-ff-ff-ff is the Ethernet broadcast address—not an attacker’s MAC.
• “Static” entries are often created by Windows itself for well-known broadcast or multicast addresses.

Windows commonly has static ARP entries that are completely normal.

The router information actually reduces one hypothesis

Initially I wondered whether the ISP gateway and the user’s own router were both answering ARP requests.

Since the gateway is bridged and Wi-Fi is off, that seems less likely now.

WinPcap

I’d almost disregard this.

WinPcap doesn’t perform ARP spoofing. It’s a packet capture driver. Lots of legitimate software installs it.

What I would ask next

I think the investigation is now at the point where raw data is more valuable than descriptions.

I’d ask for:

1. The Norton popup screenshot.
2. The exact ARP detection app name.
3. The output of arp -a immediately after the alert.
4. The IP and MAC Norton reported.

I’d also ask one additional question that we hadn’t considered earlier:

Does the D-Link router have any security features such as AI Protection, network scanning, device isolation, or MAC randomization enabled?

Modern Wi-Fi 6/7 routers sometimes implement features that can make network behavior look unusual to diagnostic tools.

Chat GPT: One last thought.

The OP says:

“I immediately shut the Wi-Fi down and looked at the ARP cache…”

I’d like to know exactly what they mean.

Did they:

• disconnect the Windows PC from Wi-Fi?

or

• disable Wi-Fi on the router?

or

• simply turn off the wireless adapter?

That sequence matters, because an ARP cache can retain entries for a while even after connectivity changes. Seeing entries after disconnecting is not, by itself, evidence that an attacker is still present.

So at this point, I think the thread has shifted from “Is there an attack?” to “Let’s interpret the networking evidence correctly.” The OP is doing good troubleshooting, but I don’t yet think the evidence proves an active ARP spoofing attack.

AI sourced content may make mistakes

[Edward_Walker]

I was using XARP to monitor the spoofing but it now seems to have stopped working.

I also used RKill to a scan

Here is a screenshot of the ARP cache just after I connect the device to WIFI

The list of IP was twice a long the screen shot shows, probably 50-60 entries

I disconnected the WIFI connection on the device

[Edward_Walker]

@bjm

1. The Norton popup screenshot. I can’t find the exact Norton Popup or the notice in the alert history file but it essentially just said ARP Spoofing detected. This notice actually came up on a different device, and alerted me to the potential issue in the network that I’ve been trying to resolve to over a week now
2. The exact ARP detection app name. App is Xarp & RKill
3. **The output of arp -a immediately after the alert. -**See post below
4. The IP and MAC Norton reported. I don’t have this, I don’t believe the Popup had an IP or MAC in the notice and all devices now have new IP address

I’d also ask one additional question that we hadn’t considered earlier:

Does the D-Link router have any security features such as AI Protection, network scanning, device isolation, or MAC randomization enabled? The Router does have AI Protection, device isolation, not sure about MAC randomization, I set each device to a reserved/static IP address

type or paste code here

[bjm]

@Edward_Walker

I was using XARP to monitor the spoofing but it now seems to have stopped working.

I also used RKill to a scan

Here is a screenshot of the ARP cache just after I connect the device to WIFI

The list of IP was twice a long the screen shot shows, probably 50-60 entries

I disconnected the WIFI connection on the device

ChatGPT: This screenshot is very interesting, and it actually makes me less convinced of an active ARP spoofing attack.

Let’s walk through it.

Interface 1: 192.168.200.226

This is the Wi-Fi/LAN interface.

192.168.200.1      d0-32-c3-2e-1a-fb    dynamic
192.168.200.255    ff-ff-ff-ff-ff-ff    static
224.0.0.22         01-00-5e-00-00-16    static
255.255.255.255    ff-ff-ff-ff-ff-ff    static

Nothing here alarms me.

• 192.168.200.1 is almost certainly the D-Link router.
• 192.168.200.255 → ff-ff-ff-ff-ff-ff is the subnet broadcast address. Normal.
• 255.255.255.255 → ff-ff-ff-ff-ff-ff is the limited broadcast address. Normal.
• 224.0.0.22 → 01-00-5e-00-00-16 is an IPv4 multicast address (IGMP). Also normal.

These static entries are created by Windows. They are not evidence of an attacker.

---

The second interface is the real mystery

Interface: 10.252.55.107

That is not on the home LAN.

Then we see dozens of public IPs:

3.161.x.x
3.162.x.x
3.211.x.x
8.8.4.4
8.8.8.8
13.219.x.x
13.225.x.x
...

That immediately tells me this is not a normal Ethernet ARP table for a home network.

ARP doesn’t resolve Internet IP addresses directly.

Those 3.x.x.x and 13.x.x.x addresses are public Internet addresses (many are Amazon AWS/CloudFront ranges).

So the obvious question becomes:

What is Interface 10.252.55.107?

---

My suspicion

I suspect that interface belongs to something like:

• a VPN,
• a virtual adapter,
• WSL,
• Hyper-V,
• VMware,
• VirtualBox,
• Tailscale,
• ZeroTier,
• WireGuard,
• OpenVPN,
• or another virtual networking component.

The OP earlier mentioned:

“I disconnected the WIFI connection”

Yet this second interface still exists.

That tells me Windows has another active network interface besides Wi-Fi.

---

I do not see evidence of ARP poisoning here

If this were classic ARP spoofing, I’d expect something like:

192.168.200.1 -> AA-BB-CC-DD-EE-FF

and later

192.168.200.1 -> 11-22-33-44-55-66

or duplicate mappings.

I don’t see that.

I see exactly one MAC associated with the router.

---

I would now ask the OP:

Can you run

ipconfig /all

and identify which adapter has the address 10.252.55.107?

That may explain the second interface immediately.

---

One more thing…

Remember earlier we discussed the OP saying:

“there were 50-60 entries”

Now I think I know why.

They weren’t necessarily looking at 50 ARP entries on the Wi-Fi LAN.

They were looking at multiple interfaces, one of which appears to be a virtual/tunnel interface with many cached destinations.

That’s a completely different situation.

---

My current confidence level

Ironically, after seeing this screenshot, my confidence that this is a genuine ARP spoofing incident went down, not up.

The LAN interface shown looks entirely ordinary. The only unexplained piece is the 10.252.55.107 interface, and before concluding “attacker,” I’d want to identify exactly what Windows created that interface.

If I were replying in the Community, I would avoid saying “the attacker is still there.” Instead I’d ask:

“Can you post the output of ipconfig /all and tell us whether you use a VPN or virtualization software? The second interface (10.252.55.107) doesn’t appear to be your home network, and the first interface’s ARP entries look normal.”

AI sourced content may make mistakes

[bjm]

@bjm

1. The Norton popup screenshot. I can’t find the exact Norton Popup or the notice in the alert history file but it essentially just said ARP Spoofing detected. This notice actually came up on a different device, and alerted me to the potential issue in the network that I’ve been trying to resolve to over a week now
2. The exact ARP detection app name. App is Xarp & RKill
3. **The output of arp -a immediately after the alert. -**See post below
4. The IP and MAC Norton reported. I don’t have this, I don’t believe the Popup had an IP or MAC in the notice and all devices now have new IP address

I’d also ask one additional question that we hadn’t considered earlier:

Does the D-Link router have any security features such as AI Protection, network scanning, device isolation, or MAC randomization enabled? The Router does have AI Protection, device isolation, not sure about MAC randomization, I set each device to a reserved/static IP address

ChatGPT: Here’s what stands out to me.

1. The Norton popup is gone

This is unfortunate because it was our strongest piece of evidence.

The OP says:

“I don’t believe the Popup had an IP or MAC…”

That’s possible. Norton’s UI has changed over the years, and not every notification contains the same level of detail. If that’s true, then we can’t compare Norton’s observation with XArp’s.

2. “This notice actually came up on a different device”

This is the new bombshell.

Earlier we assumed the Windows 11 PC displaying the thread was the device that got the alert.

Now the OP says:

“This notice actually came up on a different device.”

That changes the investigation.

Now we have:

• Windows 11 PC = being investigated.
• Another Norton-protected device = received the ARP Spoofing alert.

That actually makes more sense if the suspicious network behavior was transient. One endpoint saw it; another endpoint is now being used to investigate.

I’d ask one follow-up:

What was the other device?

• Windows PC?
• Laptop?
• Android?
• iPhone?
• Another Windows computer?

That matters.

---

3. AI Protection

This is the one answer I find most interesting.

The D-Link has:

• AI Protection
• Device Isolation

Those features can absolutely affect network behavior.

I’m not saying they’re causing the Norton alert.

But before concluding “attacker,” I’d want to know exactly what those features do on that router model.

---

4. Reserved IP addresses

Good.

That eliminates one variable.

---

5. XArp + RKill

I’d probably clarify one point.

RKill isn’t an ARP detection tool.

XArp is.

So the discussion should stay focused on XArp.

---

Where I think the investigation is heading

At this point I have less confidence in the OP’s conclusion than I did at the beginning.

Not because I think they’re wrong.

But because every new piece of evidence seems to open another explanation.

For example:

• The ARP cache screenshot looked normal.
• The “attacker MAC” turned out to be the broadcast MAC.
• The Norton popup can’t be examined.
• The alert occurred on a different device.
• The router has AI Protection.
• There’s an unexplained second interface on the Windows PC.

That’s a lot of variables.

---

If I were replying on the Community…

I’d probably say something like:

Thank you for the additional information. The ARP cache screenshot you posted appears to contain normal static broadcast and multicast entries, so I wouldn’t interpret those entries alone as evidence that an attacker is still present. Since the original Norton popup occurred on a different device and is no longer available, it would also help to identify which device received it (Windows, Android, iPhone, etc.). At this point, the most useful next step may be determining what the 10.252.55.107 interface shown in your arp -a output represents (for example, by running ipconfig /all), and confirming whether XArp is reporting duplicate IP-to-MAC mappings or simply normal ARP activity.

I think that’s where the discussion should go next.

One final observation: the OP has been thorough. New router, bridge mode, multiple scanners, ARP cache, XArp, RKill—they’re putting in the effort. The challenge now isn’t effort; it’s making sure the evidence is interpreted correctly before concluding there’s still an active ARP spoofing attack.

AI sourced content may make mistakes

[Edward_Walker]

I did a ARP -a and then ARP -a with the WIFI on. Then the Norton VPN jump on. In the past few days the VPN wouldn’t connect, now it connects very quickly.
ARP -a no WIFI

ARP -a with WIFI & VPN on

• Windows PC?
• Laptop?
• Android?
• iPhone?
• Another Windows computer?

To clarify there are 3 Win 11 PCs on the LAN, 1 laptop(on WIFI) received the Norton Spoofing alert and I installed Xarp on a different Win 11 laptop (on WIFI) with showed multiple network IP spoofing attacks, the most common attacks (IP addresses)were on the LT with Xarp, the Gateway and a Firestick. I’ve removed and reinstalled Xarp but it give me an error about no network interface and privileges.
Thank You for all of your advice and feedback

[bjm]

@Edward_Walker

I did a ARP -a and then ARP -a with the WIFI on. Then the Norton VPN jump on. In the past few days the VPN wouldn’t connect, now it connects very quickly.
ARP -a no WIFI

ARP -a with WIFI & VPN on

• Windows PC?
• Laptop?
• Android?
• iPhone?
• Another Windows computer?

To clarify there are 3 Win 11 PCs on the LAN, 1 laptop(on WIFI) received the Norton Spoofing alert and I installed Xarp on a different Win 11 laptop (on WIFI) with showed multiple network IP spoofing attacks, the most common attacks (IP addresses)were on the LT with Xarp, the Gateway and a Firestick. I’ve removed and reinstalled Xarp but it give me an error about no network interface and privileges.
Thank You for all of your advice and feedback

Hello @Edward_Walker

ChatGPT: This screenshot is actually reassuring.

Here’s what I see.

Wi-Fi disconnected

The command:

arp -a

returns:

No ARP Entries Found.

That’s exactly what I’d expect if the Wi-Fi adapter is disconnected and there are no active Layer 2 neighbors.

It does not suggest an attacker lingering in the ARP cache.

ipconfig

The adapters shown are:

• Norton VPN OpenVPN Data Channel Offload — Media disconnected
• Norton VPN Wintun — Media disconnected
• Wireless LAN adapter Local Area Connection 1* — Media disconnected
• Wireless LAN adapter Wi-Fi — Media disconnected

Nothing there surprises me.

The two Norton VPN adapters are normal virtual adapters installed by Norton VPN.

The Wintun adapter in particular is a virtual tunnel interface used by WireGuard-style VPN implementations.

The OpenVPN adapter is another virtual interface Norton can use depending on protocol.

This also explains something from the earlier screenshot

Remember the mysterious interface:

10.252.55.107

I now suspect that very strongly belongs to one of Norton’s VPN tunnel interfaces.

That would explain why the ARP output looked so odd with public IP addresses.

It’s consistent with a VPN/tunnel interface rather than the physical LAN.

So my current thinking

The evidence is beginning to point toward multiple networking components interacting:

• Norton VPN virtual interfaces
• XArp
• Wi-Fi
• New D-Link router
• AI Protection
• Three Windows PCs

That is a much more complex environment than the original post suggested.

I still don’t have one key piece of evidence

I still haven’t seen evidence of classic ARP poisoning, such as:

• one IP repeatedly changing between different MAC addresses,
• duplicate IP ownership,
• MAC address flapping,
• XArp explicitly saying:

“Host A is pretending to be Host B.”

Everything we’ve seen so far is compatible with:

• a legitimate Norton ARP warning,
• followed by an investigation that has uncovered a lot of normal networking artifacts that are being interpreted as suspicious.

If this were my Community reply…

I’d probably say something like:

Thanks for posting the additional screenshots. With Wi-Fi disconnected, arp -a showing “No ARP Entries Found” is expected. The ipconfig output also shows Norton VPN virtual adapters in a disconnected state, which is normal. Earlier, the ARP cache contained standard broadcast (FF-FF-FF-FF-FF-FF) and multicast entries that Windows creates automatically, so those entries by themselves would not indicate ARP spoofing. At this point, the remaining question is what XArp actually detected when it reported the laptop, gateway, and Fire TV Stick. If possible, a screenshot of XArp’s alert (or its event log) would be more informative than the Windows ARP cache.

I have to say, the OP has been very cooperative and methodical. They’re giving you good data. It’s just that, so far, the data hasn’t confirmed the conclusion of “an attacker is still on my network.” Instead, it’s helping narrow down what is normal versus what still needs explanation.

AI sourced content may make mistakes

[Edward_Walker]

Arp -a With WIFI & VPN

[bjm]

@Edward_Walker

Arp -a With WIFI & VPN

This screenshot is the strongest evidence we’ve seen so far—and ironically, I think it weakens the case for an active ARP spoofing attack.

Let’s break it down.

Interface 192.168.200.226 (Wi-Fi)

192.168.200.1      d0-32-c3-2e-1a-fb    dynamic
192.168.200.255    ff-ff-ff-ff-ff-ff    static
224.0.0.22         01-00-5e-00-00-16    static
255.255.255.255    ff-ff-ff-ff-ff-ff    static

This is exactly what I’d expect on a healthy home network.

• One router.
• One MAC for the router.
• Broadcast entries.
• Multicast entry.

Nothing here indicates ARP cache poisoning.

If Norton had detected the router’s IP bouncing between different MAC addresses, I’d expect to see evidence of that. I don’t.

---

Interface 10.252.3.63

Now we have:

Interface: 10.252.3.63

Earlier it was:

10.252.55.107

Notice what’s happening.

The 10.252.x.x address changes.

That strongly suggests this is not a physical LAN adapter.

It behaves exactly like a VPN tunnel interface.

---

The public IPs

We again see:

2.16.x.x
3.161.x.x
8.8.8.8
20.96.x.x
23.14.x.x
...

Those are Internet addresses.

That is another clue that this interface is associated with the VPN.

You’re not ARP-resolving Google (8.8.8.8) on your home Wi-Fi.

---

Norton VPN

This now fits together nicely.

Earlier we saw:

Norton VPN Wintun
Norton VPN OpenVPN Data Channel Offload

Those are exactly the kinds of adapters that produce private 10.x.x.x tunnel addresses.

So the second interface no longer concerns me very much.

---

My biggest observation

Across every screenshot we’ve now seen:

I have never seen:

• duplicate MACs
• duplicate IP ownership
• MAC flapping
• changing router MAC
• conflicting ARP cache entries

Those are the classic indicators I’d expect in an ARP poisoning case.

Instead I consistently see:

• a perfectly ordinary LAN interface
• a VPN tunnel interface

---

I think the OP has reached a fork in the road.

There are really two separate questions now.

Question 1

Did Norton genuinely detect something last week?

Absolutely possible.

I don’t dismiss that.

---

Question 2

Do the screenshots posted today prove an ongoing ARP spoofing attack?

I don’t think they do.

Not from what I’m seeing.

---

If I were replying on the Community

I’d probably write something along these lines:

Thank you for posting the screenshots. The arp -a output for the 192.168.200.x Wi-Fi interface appears normal. The router (192.168.200.1) is associated with a single MAC address, and the remaining static entries are standard broadcast and multicast entries created by Windows. The second 10.252.x.x interface appears consistent with a Norton VPN virtual/tunnel interface rather than your physical LAN. Based on these screenshots alone, I don’t see evidence of duplicate IP-to-MAC mappings or other classic signs of ARP cache poisoning. If XArp is still reporting spoofing, a screenshot of the actual XArp alert/event would probably be the most useful next step, since it should identify exactly which IP and MAC addresses it believes are conflicting.

---

I also have to compliment the OP a bit. They’ve done a lot of careful troubleshooting:

• Bridge mode
• New router
• Reserved DHCP
• Multiple scanners
• ARP cache
• XArp
• Norton VPN observations

The remaining challenge isn’t lack of effort—it’s correlating all of these observations to determine whether they describe one real ARP event or several unrelated networking artifacts. Right now, the screenshots lean me toward the latter rather than an ongoing compromise.

AI sourced content may make mistakes

[Edward_Walker]

I reinstalled Xarp and it seems to be running properly. I shows no attack activity. Given all the great input and evaluations from the Community I’m in agreement that any ARP spoofing attack has been mitigated and no longer a threat to the LAN.
Thank you all for sharing your great knowledge and input to resolve this situation.
I will continue to monitor the ARP in case someone is hiding

[bjm]

@Edward_Walker

I reinstalled Xarp and it seems to be running properly. I shows no attack activity. Given all the great input and evaluations from the Community I’m in agreement that any ARP spoofing attack has been mitigated and no longer a threat to the LAN.
Thank you all for sharing your great knowledge and input to resolve this situation.
I will continue to monitor the ARP in case someone is hiding

Hello @Edward_Walker

ChatGPT:

“I’m in agreement that any ARP spoofing attack has been mitigated and no longer a threat to the LAN… I will continue to monitor…”

That’s quite a shift. Instead of asserting an active compromise, the OP is acknowledging that the evidence now points to the issue having resolved.

A few things likely contributed to that conclusion:

• The gateway was placed into bridge mode.
• A new D-Link BE3600 router was installed.
• Multiple scans found nothing.
• The arp -a output looked normal.
• The FF-FF-FF-FF-FF-FF entries turned out to be standard broadcast entries.
• The second interface was consistent with Norton’s VPN tunnel.
• Most importantly: XArp now reports no attack activity.

That last point carries more weight than anything else, because XArp was the OP’s independent source for believing an attack was ongoing.

“I’m in agreement that any ARP spoofing attack has been mitigated…”

That’s a reasonable conclusion based on the current evidence.

“I’ll continue to monitor in case the behavior returns.”

That’s a technically cleaner way of thinking about it. Network attacks don’t usually involve someone “hiding” inside an ARP cache. If the suspicious behavior comes back, XArp and Norton should have another opportunity to detect it.

AI sourced content may make mistakes