ICMP over IPv6 failures. IP seems to be getting modified

Question

Hello,

I'm working on a problem in which several Windows Servers (not part of a domain) suddenly lost the ability to send ICMP traffic to IPv6 destination addresses. When attempting to ping an IPv6 IP all requests will timeout. In Wireshark, the destination addresses do not match the IP put into the command to run them which seems to be causing the failure.

For example a ping to Google DNS IPv6 Address:
ping -6 2001:4860:4860::8888

This ping will timeout, but in Wireshark, all 4 ICMP messages are shown as having a Destination address of 0:0:2001:4860:4860::

Has anyone seen anything like this where it seems that Windows is simply mangling an IPv6 address?

Thanks!

Answer 1

Hello @Steve Burns ,

Could you post a picture of the Wireshark dump of the ping request including the all of raw bytes (the bottom part of the picture)?

The problem with the appearance of the IPv6 address might just be a problem with the Wireshark capture - unlikely as that sounds. Actual mangling of the IPv6 address sounds even more unlikely to me. Before thinking further about why IPv6 ping has suddenly stopped working, I would want to be completely sure that the tracing tools are not showing misleading information.

Gary

Answer 2

Hello @Steve Burns ,

There are at least two ways of introducing code into the networking stack that would be capable of modifying packets: NDIS filters and WFP callouts. These mechanisms are often used by third party firewall and anti-virus products.

Do you have any such products installed?

If you issue the command pktmon list --all, does the "Filter" information for the NIC that was used in the test look substantially different from this (for a wired NIC):

        Id Driver      Name  
        -- ------      ----  
        35 wfplwfs.sys WFP Native Filter  
        34 pacer.sys   QoS Packet Scheduler  
        33 wfplwfs.sys WFP 802.3 Filter  

or this (for a wireless NIC):

        Id Driver       Name  
        -- ------       ----  
        32 wfplwfs.sys  WFP Native Filter  
        31 vwififlt.sys Virtual WiFi Filter Driver  
        30 nwifi.sys    Native WiFi Filter Driver  
        29 pacer.sys    QoS Packet Scheduler  
        28 wfplwfs.sys  WFP 802.3 Filter  

Checking WFP Callouts in use is trickier - let's defer that for the time being.

Gary

Answer 3

Hi @Steve Burns

Windows enables stateless autoconfiguration (SLAAC) on ipv6 interfaces by default. You probably are seeing some ::/0 routes on the interface. This can be disabled by issuing the following command for the interface in question...

netsh inter ipv6 set interface "xxxx" routerdiscovery=disabled

When SLAAC gets disabled, the ::/0 On-Link route gets removed and everything starts to work.

Hope this helps with your query,

--If the reply is helpful, please Upvote and Accept as answer--

Answer 4

Hello @Steve Burns ,

You did not answer the question about 3rd party anti-virus/firewall software, but the pktmon output suggests that no such product is installed/active.

My next suggestion would have been to issue the commands pktmon start --capture --comp all --file-name ping.etl followed by ping -6 2001:4860:4860::8888, pktmon stop, pktmon etl2pcap ping.etl --out ping.pcapng and finally to analyse ping.pcapng with Wireshark.

If you have a copy of Microsoft Message Analyzer (MMA), there is no need to convert the .etl file to a .pcapng file.

The pktmon command captures data at each layer/filter in the network stack; in my test, the echo request is captured at 8 points in the stack and the echo reply at 10 points. When viewed with MMA a single ping looks like this:

If the packet is being modified, this should show at which stage the modification occurs.

Unfortunately, when I use the etl2pcap conversion and view the .pcapng file with Wireshark, the display is more confusing:

The problem is that the captured data at each level in the stack varies between a "generic" "Ethernet" style format (simple source, destination, protocol type header) and an actual data link header (802.11 wireless format in my example). Depending on your scenario (perhaps simple "Ethernet" format throughout), you may or may not encounter this problem.

In any event, I suggest that you try this and let us know your results.

Gary