A looped back NS message is detected during DAD
-
Hi cmb,
I didn't snip source code, but I explained instructions guide on how to avoid the loop back in network which caused by VMware Workstation version.
This is all related to virtual network built in VMware not related to pfsense.
-
I was just curious what the exact, specific log message was so I could find it in the source.
It just sounds like a general problem with your VM network config. What bug do you think exists there?
-
Clearly english is not his native language.. Nor does it have anything at all to do with pfsense…
"this will happen if Duplicate (IPV6) detected."
"This is all related to virtual network built in VMware not related to pfsense.""There is a bug in pFsense 2.3 which is related to IPv6 and need to be solved by developers."
But clearly its a bug in pfsense -- please fix that ;) ROFL... -
The cause root is shown in the system logs with frequent error message keeps logging every second:
a looped back NS message is detected during DAD : HEXADECIMAL … etc.I am having the same problem. My pfsense boxes have been running fine until the upgrade, and all of a sudden this. My network has been down all night.
I read about it in google and came to know that this will happen if Duplicate (IPV6) detected.
I didn't know that was the issue. However, we have IPV6 disabled on our interfaces altogether.
This is happening also in VMWare workstation is configuring the WAN interface within Virtual Machine settings as ( Bridged: Connected directly to the physical network –> Replicate physical network connection state )
We are using KVM virtualisation (vtnet) for our machines. This is not isolated to VMWare.
Work around solution is to configure this virtual interface to be (NAT: Used to share the host's IP address)
We do not have that option.
But this is not a solution for me because in my company WAN we have already installed pfSense 2.2.6 hosted as virtual machine in ESXi Server and the NAT option will change the network ID which is not practical for DMZs.
So the workaround is not a solution.
There is a bug in pFsense 2.3 which is related to IPv6 and need to be solved by developers.
You may be right. Let's see if others are affected.
Clearly english is not his native language.. Nor does it have anything at all to do with pfsense…
"this will happen if Duplicate (IPV6) detected."
"This is all related to virtual network built in VMware not related to pfsense.""There is a bug in pFsense 2.3 which is related to IPv6 and need to be solved by developers."
But clearly its a bug in pfsense -- please fix that ;) ROFL...0/10 for helpfulness or community spirit on this one! pfSense is used all over the world, and wouldn't be available to the rest of us if it wasn't for some of the work put in by non-english developers, I'm sure. Posts like this make people less likely to participate in the community, and make it harder for everyone else to get assistance. Maybe next time, if you're going to write it, press delete instead of post?
-
It has ZERO do with pfsense.. He should of posted it on vmware forum in his own language.
This sort of garbage thread does nothing for the community nor anything to help the developers.. But his desire to call out some bug in pfsense sure happens to make it to the search engines with other users finding it when they too think pfsense has some bug and come to this thread that is completely useless to the pfsense community.
You even jump on the bug band wagon, when clearly the OP states himself in another post that it has nothing to do with pfsense..
Did you read the thread???
""This is all related to virtual network built in VMware not related to pfsense."" -
It has ZERO do with pfsense.. He should of posted it on vmware forum in his own language.
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.
"own language"? Everyone should be welcome here, even if they don't speak english as a first language.
You even jump on the bug band wagon, when clearly the OP states himself in another post that it has nothing to do with pfsense..
I don't know if it's a bug or not, I want to fix the problem so I am here to try and find out what's going on. Possibly he was mistaken about suggesting it was a bug, but clearly it is a problem that more than one person is having so let's try and find a solution.
Did you read the thread???
""This is all related to virtual network built in VMware not related to pfsense.""Once again, we are using KVM virtualisation (vtnet) for our machines. This is not isolated to VMWare.
-
"we are using KVM virtualisation (vtnet) for our machines."
WTF does what you are using have to do with the OP nonsense??
If you have some issue with pfsense running on kvm, then start your own thread with pertinent info. Maybe we can get some info to work with there vs the nonsense this post was and is..
-
It has ZERO do with pfsense.. He should of posted it on vmware forum in his own language.
This sort of garbage thread does nothing for the community nor anything to help the developers.. But his desire to call out some bug in pfsense sure happens to make it to the search engines with other users finding it when they too think pfsense has some bug and come to this thread that is completely useless to the pfsense community.
You even jump on the bug band wagon, when clearly the OP states himself in another post that it has nothing to do with pfsense..
Did you read the thread???
""This is all related to virtual network built in VMware not related to pfsense.""My friend,
I will not comment on the discrimination phrases you stated because this forum is respectful and more likely scientific. But remember that great nations were flourished by science not by language.I was expecting thanks for spending huge efforts trying to figure out and zoom-in the cause root of a problem but your replies and comments were so disappointing and this for sure will impact negatively the forum reputation.
Second thing, if you ever think I am using the phrase (BUG) to attract search engines on my name, then please have a look at the other pfsense threads and count me please how many times (BUG) mentioned by other participants out there to be fair in your judge?!!!
On the other hand, it is impossible to have any software all over the world that is 100% bug free even commercial paid projects. I am wondering why did you get so annoyed when I used that word?!!!
In conclusion, pfsense 2.3.1 has fixed this issue for me and I didn't have to do anything with VMware settings, SO, I was and still right with regards to an issue (instead of bug) which had been fixed in the recent versions.
With my all respect and appreciation to pfsense project developers.
-
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.