A looped back NS message is detected during DAD
-
Same problem here, with both 2.3.2.RELEASE and 2.4.0.BETA running on a Windows Server 2016 Hyper-V VM: when VMQ hardware acceleration is enabled (which it is by default) on anyone of the virtual NICs, the pfSense log gets flooded with "a looped back NS message is detected during DAD…" messages and IPv6 is broken.
Simply disabling VMQ from all VM NICs fixes the problem (and the IPv6 stack).
Specifically I'm using an Intel X520-DA2 (which has full VMQ support) with one 10Gbs port assigned to the host OS and the other dedicated to an Hyper-V switch with 4 VLANs: (1) LAN, (2) WAN, (3) DMZ, (4) GUEST.
-
"Looped back NS message is detected during DAD" messages are almost always a sign of switch/AP/bridge/virtual NIC/whatever misconfiguration or a bug, nothing that pfSense has anything to do with nor could it even do anything about because it is just following the IPv6 spec correctly and spits out the correct error message for the error condition it is detecting.
-
@kpa:
"Looped back NS message is detected during DAD" messages are almost always a sign of switch/AP/bridge/virtual NIC/whatever misconfiguration or a bug, nothing that pfSense has anything to do with nor could it even do anything about because it is just following the IPv6 spec correctly and spits out the correct error message for the error condition it is detecting.
Perhaps.
Yet in my evaluation of linux/unix-based firewalls, pfSense was the only one to have ipv6 problems on VMQ hardware accelerated NICs. Moreover, I have 3 other Windows based VMs running on the same server with fully functional ipv6 stack.
And this is not just a Microsoft Hyper-V isolated problem. The same issue happens on vmWare virtualized NICs/switches.
BTW, I see this flood of "Looped back NS message is detected during DAD" messages not only in the pfSense system log but also in the console, during installation and at every startup. Perhaps FreeBSD is the source of this.
-
It's the VM, I have a couple of VMWare FreeBSD setups I use for different purposes, both show this and pfSense is nowhere in sight.
-
Agree. It's FreeBSD that generated all those messages, not pfSense.
-
Just wanted to say that in my case the OpenVPN interface ovpns1 and my WAN interface had the same IPv6 addresses, and that was the reason for this message.
-
Just fired up a new virtualized pfSense 2.4.4_1 on Windows Server 2019 with some Intel NICs and this is still an issue. Disabling VMQ seems to fix the problem.
The exact message in case anyone else is searching and finds this is:
hn0: a looped back NS message is detected during DAD for fe80:xxxxxx. Another DAD probes are being sent.
I will try to reproduce it in vanilla FreeBSD and then file a bug with them.
-
@edooze said in A looped back NS message is detected during DAD:
It is to do with pfSense, because the error is in pfSense. If the resolution is not, so be it, but that's what we're here to find out.
I suggest you read up on how IPv6 duplicate address detection works. With it, a device is supposed to send out a NS to see if any other device is using the address it wants to use. If that address is in use, the device will then have an error condition to deal with. It has nothing to do with pfSense.
-
I encountered this same problem on Hyper-V on Windows Server 2019. After finding this thread and disabling VMQ in the virtual machine NICs, it solved the problem like it had for others. I went a step further and replaced the stock Microsoft drivers for the Intel X520-T2 NIC with the latest version from Intel's web site. I was then able to re-enable VMQ without any side effects. It would appear there is a bug in the stock Intel driver from Microsoft in Windows 2019 as it relates to VMQ. I hope this helps anyone else that might run into this issue as well.
-
@vabello said in A looped back NS message is detected during DAD:
I encountered this same problem on Hyper-V on Windows Server 2019. After finding this thread and disabling VMQ in the virtual machine NICs, it solved the problem like it had for others. I went a step further and replaced the stock Microsoft drivers for the Intel X520-T2 NIC with the latest version from Intel's web site. I was then able to re-enable VMQ without any side effects. It would appear there is a bug in the stock Intel driver from Microsoft in Windows 2019 as it relates to VMQ. I hope this helps anyone else that might run into this issue as well.
Very interesting, I will give this a try as well. I was planning on trying to reproduce in vanilla FreeBSD and then filing a bug with them but never got around to it.
-
@kmo12345 So interestingly, I was playing around with SR-IOV and saw it was "Enabled" but not "Active" on my FreeBSD VM nor my pfSense VM. It was showing active on my Windows 2019 VM (after I had installed the correct supporting driver for support of the X520 Intel NIC) and Ubuntu LTS 18.04 VM. After examining it further and reading a bunch of posts in forums, I haven't had success in getting SR-IOV to be active, so I just disabled it. It seems the ix driver won't attach to the passed through PCI device for some reason. Anyway, when I did that on my FreeBSD 12 VM, the duplicate DAD issue came back after reboot. VMQ was left enabled. On the pfSense VM with the same configuration it wasn't showing the kernel warnings, but it seems SLAAC wasn't functioning with pfSense from my MacBook Pro. I honestly didn't verify this as I don't have a ton of time to mess with it at the moment. I just disabled VMQ and rebooted it again and all was happy.
So, I'm not totally sure of what to make of this, but it seems SR-IOV being enabled, even if it's not active, seems to fix the VMQ issue. It might be that SR-IOV effectively disables VMQ even though it's still selected in the VM configuration. I don't know where the issue lies and I'm not skilled enough in that area to really determine that, but I wanted to pass along my own personal findings for the community based on my own experiences. FreeBSD bug in hn driver maybe? Again, Linux and Windows seem fine in the same setup. I wanted to correct my earlier statement that the updated driver on Windows Server 2019 appeared to fix the problem with VMQ, as that doesn't appear to be the case now.
If I get time, I'd like to run disable SR-IOV on my other VM's and run Wireshark on Windows and tcpdump on my Linux VM just to verify that they also don't see the duplicate DAD issue and are just being silent about it. That would lead me to believe it's more of a Hyper-V and/or Intel driver problem on the host. If not, I'm back to supposing it's the hn driver in FreeBSD at fault with VMQ enabled.
-
@vabello It would be nice if the guide for installing pfsense on Hyper V included this issue.
I have run into it and trying basically everything in this thread and whatever sleuthing turns up to get these errors to go away.
I am working with Hyper V 2019 and the NICs (for now) are Intel X722 (10 Gbe) ones. I know the physical NICs have VMQ enabled (power shell command spit that out). The console messages though were for two virtual devices and it kept spamming (so I was unable to continue setup after initial install from iso).
If I figure anything out, I will share it.