NDP Table Timeout

TNewshel

I am running pfSense+ 23.01 on a Netgate 6100. Every time I select "NDP Table" from the Diagnostics menu, I time out with a 504 Error on this page: diag_ndp.php

Screenshot from 2023-02-20 13-43-51.png

If I ssh into the 6100 and run "ndp -a" from the CLI, I see my NDP list just fine.

All other Diagnostics menu functions (other php pages) seem to be working just fine.

Any ideas what is causing the timeout?

IonutIT

Reviving this old thread.

It seems I'm in the same boat. Netgate 6100, pfSense+ 23.05.1 and NDP Table doesn't load.

johnpoz

@IonutIT and when you run the ndp -a, how many entries do you get back? And how long does it take to show the complete list?

If -a takes awhile, what if you do -na is it way faster?

From what I recall with people having the same sort of issue with dhcp leases and arp table was it was dns related, where it could take so long trying to resolve names that it would exceed the timeout value and throw a 504 errors.

Could be the same sort of problem with ndp. I see in the diag_ndp.php file there is a section that would be trying to do dns on the entries.. Which if that takes a long time could cause you problems.

// Resolve hostnames and replace Z_ with "".  The intention
// is to sort the list by hostnames, alpha and then the non
// resolvable addresses will appear last in the list.
foreach ($data as &$entry) {
     if (is_null($dnsavailable)) {
        $dnsavailable = check_dnsavailable('inet6');
     }
     if ($dnsavailable) {
        $dns = trim(_getHostName($entry['mac'], $entry['ipv6']));
     } else {
        $dns = "";
     }
     if (trim($dns)) {
        $entry['dnsresolve'] = "$dns";
     } else {
        $entry['dnsresolve'] = "Z_ ";
     }
}

IonutIT

@johnpoz

Running ndp -a starts displaying entries after 1-2 seconds, and keeps adding entries every second or so. The command finishes after about 2 minutes with about 60 or so entries displayed.

Running ndp -na shows all results instantly, though I suspect it's caching the results of the previously run ndp -a

I don't know if the delay is because of hosrname resolving, running ndp -a it's not actually resolving any hostname other than the router itself.

Is it possible that maybe make the NDP Page in the webUI to also display results dynamically as they appear and not have to wait for the command to finish in it's entirety?

johnpoz

@IonutIT said in NDP Table Timeout:

running ndp -a it's not actually resolving any hostname other than the router itself.

Well thats the thing - its not resolving, but it is trying..

If you look in that code of diag_ndp.php - its actually doing a ndp -na, but then if there is a dns available it tries to resolve them.. So that can be a huge delay.. Which I would believe is where you run into the 504 issue. Now could the page be setup to dynamically update - maybe..

I would think maybe checkbox or something to just have it not do dns at all be better option to be honest. Or ability to increase timeout or something if you have so many in the list that dns going to take a while..

You could prob just edit that code to not have it do dns for ndp no matter if you have dns available or not..

IonutIT

@johnpoz

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.

johnpoz

@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

IonutIT

@johnpoz

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.

TNewshel

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.

johnpoz

@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::/10

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

IonutIT

@johnpoz

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.

johnpoz

@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

IonutIT

@johnpoz

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 -a it 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?

johnpoz

@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::2004

And 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: 170

Look 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: 101

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

IonutIT

@johnpoz

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