NDP Table Timeout
-
Was this a recently new change?
I distinctly remember that the NDP Table loaded properly when I first setup my 6100. It was on pfSense+ 22.05 though.
-
@IonutIT I think there was some changes - there was something to do with ndp not showing hostnames at all that I recall from redmine.. I am not a big user of Ipv6 in general, while I have it on couple of my vlans.. There are only a couple of hosts that have it enabled at all, etc. And I don't have dns doing IPv6, and don't have it listening on any IPv6 etc.. So maybe that is why I have not seen any issues with it - but again I don't normally look at that table with the gui or even cmd line.. And just looking at it now - its really small.. And the only thing in it other than link-local is is pfsense interfaces that have IPv6 on them.
edit: looks like I had even put in that redmine ;)
https://redmine.pfsense.org/issues/13318
Would of been someone asking about it in a thread, I was able to duplicate, etc. so I put in a redmine.. Looks like they did their change with 23.01
Here is the thread that got me to put in the redmine
https://forum.netgate.com/topic/172830/ndp-table-not-showing-hostname
-
I have no issue with the hostname part, but that page should work regardless of that Hostname column or not. I'm using Stateless DHCP so I don't even know how hostname resolving would work...
Either load a blank page with a message "please wait until all info is gathered" and icon indicating it's loading instead of a timeout, or like you said, a toggle that will search for hostnames or not.
Either way, the fact that the page doesn't load at all, is a bigger issue than the resolving or not of Hostnames in the first place.
-
I appreciate the follow-up to this issue. It had been so long since I posted, I had given up.
After seeing these recent replies, I tried once again today for the first time in months. To my surprise, the UI page for NDPTable worked fine. The first time I selected it, there was an appreciable delay but the page did not time out. The 2nd and subsequent times I tried it, with logouts from the UI in between, the page rendered very quickly with accurate results. I am not sure if my intervening update to the now current pfSense + version 23.05-1 was the cause of the solution. But all is well now.
Just for reference, I tried "ndp -a" and "ndp -na" from the CLI, and the two ran quickly, with the "-na" argument defintely noticeably faster. But both variations ran fine.
As far as my original post, now under v23-05.1, the problem can be marked as resolved.
Thank you both for your recent input.
-
@TNewshel yeah if your using local dns, even looking up hundreds should be fairly quick.
If I had to take a guess its possible @IonutIT is maybe using external dns? Or his ndp table is full of gua addresses that taking longer to query externally? @IonutIT how many entries are in your table, and are they lots of gua addresses or all link-local addresses?
If you are only using local dns, could be possible to setup a always nx for the IPv6 gul prefix your using locally so, those would never go external.
If you look in the unbound.conf - if link local it should never go external
cat /var/unbound/unbound.conf
# DNS Rebinding # For DNS Rebinding prevention private-address: 127.0.0.0/8 private-address: 10.0.0.0/8 private-address: ::ffff:a00:0/104 private-address: 172.16.0.0/12 private-address: ::ffff:ac10:0/108 private-address: 169.254.0.0/16 private-address: ::ffff:a9fe:0/112 private-address: 192.168.0.0/16 private-address: ::ffff:c0a8:0/112 private-address: fd00::/8 private-address: fe80::/10But if loads and loads of gua that could take some time to resolver which such a delay could be causing the problem.
edit: this info is wrong, this is for dns rebind, see my posts below for better info..
-
I'm using the local resolver (with pfBlockerNG if that makes any difference). My NDP table has about 60 entries, with about half link-local and half GUA.
Edit: I'll try to add the private-addresses list in unbound, see if that makes a difference.
-
@IonutIT I posted that wrong, that is not the AS112 entries that keep rfc1918 from being asked PTR.. I am trying to dig up now what unbound does for IPv6 link-local, I would assume it would be like AS112.. but its default, so don't think it would be actually listed in the conf..
Those are the rebind address space.. My bad on that - sorry.
If your pointing to yourself, ie 127.0.0.1 for dns, unbound should be smart enough not to try and resolve stuff that would never resolve public, like ptr for rf1918, and same for IPv6 link-local.. Just trying to dig up the actual listing of what those are.
But as a test even, you should be able to create a nx entry for whatever your gua prefix is to keep from those being attempted to be resolved..
here is info about AS112 from the unbound.conf doc
so by default, it shouldn't be doing external for link-local and ula and such for IPv6
But yeah for gua it would be trying to resolve those.. Which could maybe have enough delay to cause 504, as a test you could try creating a nx for your local gua prefix, so those do not try and resolve externally.
See I tried to query for IPv6 link-local PTR and got back nx right away
$ dig -x fe80::208:a2ff:fe0c ; <<>> DiG 9.16.43 <<>> -x fe80::208:a2ff:fe0c ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57855 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;c.0.e.f.f.f.2.a.8.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN PTR ;; AUTHORITY SECTION: 8.e.f.ip6.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 ;; Query time: 3 msec ;; SERVER: 192.168.3.10#53(192.168.3.10) ;; WHEN: Sun Sep 03 12:49:00 Central Daylight Time 2023 ;; MSG SIZE rcvd: 160 -
Any pointers on how/where to make the nx entry for my current GUA prefix?
Looking at how the list is populated in cli when doing
ndp -ait seems that it's waiting more when resolving a GUA item and instantly shows when resolving a link-local item, so that's in line with your suspicion about trying to resolve GUA addreses.So where can I put a temporary nx entry for my current GUA prefix?
And if this solves it, is there anyway to code this inside pfSense, to automatically add this nx entry for whatever the GUA prefix is being allocated via DHCPv6-PD from ISP?
-
@IonutIT that might be a good feature request sure.. So for example, you would have to use your own prefix.. So for example I took the IP of google..
;; ANSWER SECTION:
www.google.com. 316 IN AAAA 2607:f8b0:4009:809::2004And if I do a ptr on that - it looks it up..
$ dig -x 2607:f8b0:4009:809::2004 ; <<>> DiG 9.16.43 <<>> -x 2607:f8b0:4009:809::2004 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12454 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;4.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.9.0.8.0.9.0.0.4.0.b.8.f.7.0.6.2.ip6.arpa. IN PTR ;; ANSWER SECTION: 4.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.9.0.8.0.9.0.0.4.0.b.8.f.7.0.6.2.ip6.arpa. 86400 IN PTR ord37s33-in-x04.1e100.net. 4.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.9.0.8.0.9.0.0.4.0.b.8.f.7.0.6.2.ip6.arpa. 86400 IN PTR ord31s22-in-x04.1e100.net. ;; Query time: 1738 msec ;; SERVER: 192.168.3.10#53(192.168.3.10) ;; WHEN: Sun Sep 03 12:51:59 Central Daylight Time 2023 ;; MSG SIZE rcvd: 170Look how long it took, almost 2 seconds..
Now if I create a nx for that prefix..
$ dig @192.168.9.253 -x 2607:f8b0:4009:809::2004 ; <<>> DiG 9.16.43 <<>> @192.168.9.253 -x 2607:f8b0:4009:809::2004 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 58457 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;4.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.9.0.8.0.9.0.0.4.0.b.8.f.7.0.6.2.ip6.arpa. IN PTR ;; Query time: 1 msec ;; SERVER: 192.168.9.253#53(192.168.9.253) ;; WHEN: Sun Sep 03 13:19:15 Central Daylight Time 2023 ;; MSG SIZE rcvd: 101If that fixes it for you, you might want to use static vs the nx always setting. Since then if you actually have local data for specific IPv6 those would be return, but if not then nx.. or nodata Which should allow you to resolve any gua you do actually have local data for, but not for anything you don't and it shouldn't try to externally resolve.. I am not 100% on that but should be easy enough to test.
-
Yup, that seems to fix it. NDP Table loads up on webUI after setting my current GUA PD as local-zone.
So yeah, an option to always set the PD as local-zone would be nice...
