IPV6 Neighbor Solicitation Not answered !?? => No IPV6 :(
-
@louis2 I haven't noticed any other reports of such an issue.
If you take truenas and your jails out of the equation are you seeing the same problem.. So your saying IPv6 isn't workable on pfsense 2.6.. I find that hard to believe, or you would think there would be multiple threads/posts about it not working.
IPv6 is pretty hard to work if RAs don't function, or client can not discover pfsense via NDP..
-
John, In first instance I mainly verdict TrueNas-core which is based on FreeBSD 12.3 just like pfSense. However I was not sure as well, so I opened this blog.
However since I had severe issues with TrueNAS-core, I did decide to try TrueNAS scale with is their linux based release candidate (I think it is not jet RC but that apart). And up to my surprise the IPV6 behavoir or that linux version was identical to the FreeBSD version. And that did my doubts related to pfSense increase ! .... and I started again testing with all kind of dhcp and RA settings on pfSense.
When that did not solve any thing, I asked for help here.Do note that:
- the problem only occurs when the server in this case TrueNAS initiates the communication. (The other way around works!)
- I ones did a test connect my windows PC on the truenas host vlan, which seems to work (I can redo that test), however it is for sure that windows behaves different
- I can not go back to pfsense 2.5 to test that, since the config files are not compatible, that would be a too big effort (and error sensitive)
-
I forgot to add that
- if I start a command like "ping6 www.google.com" on truenas, that only results in a lot of the unanswered NS — Neighbor Solicitation (ICMPv6 type 135) messages
- however ... surprise surprise (not) ...... if I start some form of communication from the other side (ping -6 truenas from my pc) then
- As expected I get ping results on my pc AND
- as by magic the pings starting at truenas towards google start working as wel :)
-
@louis2 well first thing I would do is get current on your snapshot.. You are a few days behind..
-
Done! No change
-
@louis2 I don't run dev, and for sure can not duplicate what your seeing on my network - ipv6 working just fine..
As to rolling back to 2.5 - where did you see you could not do that because of issues with xml? I was not aware that was a thing..
This seems odd?
Src: A:B:C:110::1:10, Dst: ff02::1:ff00:1
Did you edit that to obfuscate something.. A:B:C ??
-
John the ABC is edited just to hide my address. Since I try not to share too much.
By the way, I do not mind to share full wireshark traces etc, wich you, however not via the public forum
-
@louis2 Let me see how my afternoon looks for real work ;) if its quiet which I think it is, not seeing any meetings on my cal ;)
I could fire up a 2.6 dev box on a VM and see if I can duplicate your problem.
-
Ok thanks! I will create a drawing from my test setup. That will perhaps help as well.
-
Here two pictures
- a schematic version of the physical setup. Based around a 1G SW, a 10G SW and pfSense. pfSense has a 1G lagg towards the 1G SW and a 10G lagg towards the 10G SW. 1G VLAN's are forwarded to the 1G-lagg, 10G VLAN's to the 10G lagg. There is a trunk between the switches, e.g. to make a slow copy of the 10G vlans available to the test-nas in my "office"
- a schematic version of the vlan-setup. All vlans come together in pfSense and nowhere else. The TrueNas test system is intended to play as NAS but also as "VM-server" as such that TrueNas-machine will have one vlan for the host and jails and vm's will in most cases be connected via their own vlan.
TrueNas host it-self will be in the "GreenZone" where the Jails and VM's will be in more risky zones (e.g. a webserver in "RED")
-
@louis2 so question - your using lag from your switches to pfsense where these vlans run.. Have you tried turn that off and see if working?
I see your 2x1g and 2x10g which looks like uplinks from your switches.
And your saying you only see this problem on stuff coming from your truenas, you show say vl2 and vl3, with some devices on them - are they using ipv6, are they having any issues with seeing RA or using NDP to find pfsense?
-
The LAGG's are the downlinks form pfSense towards the main switches or the uplinks from the switches to pfSense whatever you like :)
If the lags would not work, I could not access any thing, however since I can reach my-wifi, my-server and my nas-systems, I am sure they are working. Apart from that I can of course see that on GUI of the switches.
In principle the whole network is IPV6 and IPV4. And most equipment is using both. Mobiles, my pc. my server etc. Not the printer or the hifi-receiver :)
As far as I know every thing is working, with exception of the TrueNas systems, in case the ipv6 is initiated on/from those systems. Which is of course verdict !
However note that
- Every thing works "As far as I know" because I did not trace the behavoir of most equipment and apart from that a lot of traffic is still IPV4 or incoming IPV6.
- the NAS-systems are, apart form the switches and pfSense, the only machines who are vlan aware. All other devices do not know that their traffic is handled via a vlan
- the new NAS / test system is the first system in the network which will be accessed via multiple vlans (possible as a result of the use of jails and vm's_
- it is clear that the behavoir of freebsd, linux, windows. android differs
- my small server is windows based, and not vlan aware.
But big question is of course, if the TrueNAS systems behave different, is it wrong!? and is the fact that pfSense does not react correct!!??
-
@louis2 not saying in general your lacp/lagg isn't working - but take that out of the equation for the testing.
In your sniff where you show client doing Neighbor Solicitation - how did you sniff that exactly. Was that traffic correctly tagged?
-
John,
I have been wondering long ago how to show vlan tags in wireshark. Still no idea :(However it seems impossible that there is a problem with the vlan taggings, since the whole network is build with additional to the core switches small netgear managed switches connected via trunks.
Never the less, thinking about how to remove the laggs out of the equation, to keep it simple I could only imagine one thing.
- shutting down one of the two sides from each lagg
That is what I did, and that did not change the situation.
-
One other thing what I could do tomorrow, should not change any thing!, but you never know!
Is connecting the test NAS via a long cable directly to the 10G core switch (that is the place where it is intended to go in the future).That will remove the inter-core switch link, the 1G-switch and the "room switches" out of the equation. It is just vlan of course, but since we are looking into strange things .... I could try
However if, that it is something for tomorrow
-
By the way ...... IPV4 and IPV6 are both based on the same VLAN's and LAGGs and .... ipV4 is no problem
-
@louis2 said in IPV6 Neighbor Solicitation Not answered !?? => No IPV6 :(:
VLAN's and LAGGs and .... ipV4 is no problem
IPv4 doesn't use multicast to find its neighbors.. There are differences between how ipv4 and ipv6 works.. So such things are not always proof that something is working for both.
But I find it hard to believe its something wrong in pfsense in such a way that it would be common to just not answer a solicitation.. Or there would be lots of posts complaining its not working, and none of your IPv6 network would work, etc.
There is a piece of the puzzle missing that is for sure.. Kind of hard to solve a puzzle with pieces missing.
-
I took an "extreme test measure" and placed an additional UTP-card in the router and defined two new vlans on that interface.
At the side of the TrueNAS server I used a spare UTP-connection to define the same two vlans.
I did connect them via a long UTP-cable ...... and I must admit a see different behavoir. It might be, ..... not sure because of "situation" holding times in the network, .... that the communication works this way.
Assuming that this temporarily setup really works (lets hope) it leaves two questions:
- what is wrong with my network setup !?
- why does it not work with FreeBSD/Linux but does work with windows !?
The first question is probably most interesting.
- something wrong with the laggs ??
- or the inter switch communication ??
- or something else ??
-
@louis2 said in IPV6 Neighbor Solicitation Not answered !?? => No IPV6 :(:
why does it not work with FreeBSD/Linux but does work with windows !?
Your saying it works with a windows VM running on your truenas, but not bsd/linux vm? Is this windows box on the same vlan ad the bsd/linux vms?
Still missing puzzle pieces - LAGs can be tricky sometimes, it is possible for example to have a flood port in the lag, where broadcast and multicast use this specific port, etc.
At min that is a variable we are unsure of.. Your test of using a different path this not lagg for sure could be helpful in finding the missing puzzle pieces.
-
No, I did not say it works with a windows VM(!) , I only mend to say that I did not notice ipv6 issues in relation with the TrueNAS core (FreebSD) and TrueNas scale (debian).
ping -6 www.google.com from my windows pc or windows server is simply working. The traffic is different the OS is different and their traffic is different and they are not vlan aware.
Of cause the traffic towards e.g. this windows machines is transported via the same vlans, swithes and laggs ..
BAD NEWS
- I just detected that also with the direct connection, I still have the same issue. I do not know why it worked for a short time. I expect due to the fact that there has been a guery starting from the pfsense side first
