After configuring SPAN, Wireshark was able to read ICMP packets (ping traffic) on the destination port that was sent across the configured source port, using an older PC. However, another newer PC was unable to read the traffic, despite identical configuration.
- Both PCs happen to use the same endpoint firewall system, so that rules out firewall as an issue.
- Changing the SPAN encapsulation from native to dot1q did not have any effect
What are some other possible reasons Wireshark would pick up packets on one PC but not another? What could be the likely issue here?
Using a Cisco 2960-S, newer DELL PC (the one not picking up traffic), and an older DELL PC (this one picks up the traffic).
If the span was working fine before, then it is not likely the problem. I thing the PC is the issue. Disable or uninstall the firewall and test. Upgrade the drivers of the network card.
Does that PC work fine on the network and only fails when monitoring spanned traffic?
Both PC's use Kaspersky Endpoint firewalls, which are controlled by the organization remotely I guess. I don't have privilege to shut them off and cannot access the firewall settings on either machine. However, since one PC worked fine with the same firewall system in place, I had ruled out firewalls.
I agree it seems like an issue with the PC or its NIC.
Turning off the network (the Wifi) didn't affect the situation.
I checked for updates on the driver and it says the best is already installed.
Cannot rule out firewall, but no way to turn it off due to privileges. But one machine works fine with the same firewall system which is controlled by the organization.
I double checked and it is the correct interface.
Not clear on the last tip you provided. The switches are not connect to any routers or any internet. The pc that does not see the SPAN traffic does have a wifi connection, and it is able to pick up its own wifi interface traffic. It does see some packets on the destination port, just not seeing ICMP traffic despite pings over the source port.
When I issue a ping, instead of ICMP traffic, it picks up the following:
An ARP broadcast request from the mac address of the PC issuing the ping
Two LLMNR protocols from the IP of the PC issuing the ping, which each have a multicast destination IP of 244.0.0.252, not the ip that the ping was sent to.
The ping shows as successful on the CLI
Having said that, wireshark captures happen before the local firewall processes traffic. so if you have for instance FTP traffic on a local client, with a FW blocking FTP. your packet capture should see that incoming ftp traffic on port 21, even though it gets blocked by FW.
(i am not saying this issue is not FW related BTW).