A looped back NS message is detected during DAD



  • Dear All,

    I spend the whole nights awake to find out why this issue is happening.

    But Finally I came to the cause root that has a work around solution but not permanent.

    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 read about it in google and came to know that this will happen if Duplicate (IPV6) detected.

    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 )

    Work around solution is to configure this virtual interface to be (NAT: Used to share the host's IP address)

    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.

    There is a bug in pFsense 2.3 which is related to IPv6 and need to be solved by developers.

    and maybe there is relation to post https://forum.pfsense.org/index.php?topic=110380.0;topicseen

    I wish I helped you to work around.



  • I split this to its own topic because it doesn't appear to have any relation to where it was posted.

    It sounds like you have something looping traffic inside your network. What exactly is the log message you're getting? The snippet you posted doesn't exist in the source code.



  • 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?


  • LAYER 8 Global Moderator

    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...



  • @pfsensier:

    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.

    @pfsensier:

    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.

    @pfsensier:

    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.

    @pfsensier:

    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.

    @pfsensier:

    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.

    @pfsensier:

    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.

    @johnpoz:

    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?


  • LAYER 8 Global Moderator

    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.""



  • @johnpoz:

    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.

    @johnpoz:

    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.

    @johnpoz:

    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.


  • LAYER 8 Global Moderator

    "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..



  • @johnpoz:

    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.


Log in to reply