Diagnostics ARP Table 504 Nginx Gateway Timeout

johnpoz

Well your PTR zone there - yeah if you were asking some other NS to resolve the ptrs - and it didn't know them or you couldn't actually talk to that NS then yeah you could have issues when your trying to resolve hundreds of IPs to their names..

lddj9090

@johnpoz
Exactly, I think not beeing able to resolve the IP's caused the problem in the end. Thanks for your help mate!

lddj9090

Alright, to clarify for other users who may have problems with this:

Configuration under DNS Resolver -> General Settings -> Domain Overrides looked like:

Domain:
18.16.172-in.addr.arpa (our VLAN)

Lookup Server IP Address:
172.16.18.1 (Pfsense interface for this VLAN)

The reason I configured it like this was, I wanted that clients from that VLAN do not use an outside lookup server. Instead, using our Pfsense itself.

After deleting this entry, the ARP table shows up nicely.

johnpoz

What did you think that would do?

I wanted that clients from that VLAN do not use an outside lookup server. Instead

That makes no sense.. How would that of redirected say a client wanting to use 8.8.8.8 for dns??

You wanted a dns redirect..

https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html

You were telling pfsense, hey if you want to look up what this IP is - ask yourself? Well duh ;) How would that redirect a client to use pfsense vs googledns? Could create a loop I would think? But I think your issue is different than the other poster.. who had public IP in his arp table.

lddj9090

@johnpoz

When I tried lets say from VLAN 14 to nslookup a client in the 18 VLAN, I wanted pfsense to handle this as it is DNS/DHCP for the 18 VLAN.
So I thought I had to make this entry in the config. After deleting it, I was still able to resolve IP's in the 18 VLAN.

But I am not sure how domain override entries affect loading ARP entries. Have you got an idea?

Test wise I added the domain override entry again, and again ARP wouldn't load up.

johnpoz

My guess to why that problem would cause you an issue with arp, is it was causing some sort of loop/issue with actually doing the PTR request.. So it was causing timeouts when the arp table tried to resolve your local IPs to names.. Which would cause delay in the arp table being displayed.

The other users issue was related to trying to resolve PTR for large number of public IPs.. Which may or may not of resolved causing the delay.

Normally doing PTRs for local IPs should be pretty instant, since it would be just pfsense asking its local unbound for them. Or some other local NS authoritative for that IP range.. But yeah if there is issue talking to whatever NS it would resolve these IPs, or there is a LOT of them that are not local and have to query some external NS, that could cause delay in the table to be displayed.

lddj9090

This post is deleted!

lddj9090

@johnpoz
Your explanation sounds logical and makes sense.

How to investigate this any further? As pfsense itself is DNS for the VLAN 18 interface and therefore should be able to resolve those IPs.

johnpoz

I would pick an IP form your network - does it resolve? If not - why?

Pfsense is only going to be able to resolve stuff it has record for. Be it via dhcp registration, static registration, or you actually created a record.

Pretty much all my ips resolve because most of my network is reserved, and I register the static registrations in dns. But there are a few that do not..

In the past, and maybe even still there are issues "depending" on registration of dhcp leases into dns because of restarts of unbound..

even if the records do not exist.. if the NS is local - it should come back almost instant... For example

$ dig -x 192.168.9.44 @192.168.9.253

; <<>> DiG 9.16.18 <<>> -x 192.168.9.44 @192.168.9.253
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45780
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;44.9.168.192.in-addr.arpa.     IN      PTR

;; AUTHORITY SECTION:
168.192.in-addr.arpa.   10800   IN      SOA     localhost. nobody.invalid. 1 3600 1200 604800 10800

;; Query time: 0 msec
;; SERVER: 192.168.9.253#53(192.168.9.253)
;; WHEN: Wed Jul 14 09:48:16 Central Daylight Time 2021
;; MSG SIZE  rcvd: 113

Here I did a PTR lookup for something I know there is no record for it. NX is sent pretty much instant.

lddj9090

@johnpoz
There are some ips which do not resolve as they are out of dhcp range and not static or the device doesn't tell a hostname. But almost all ips resolve proper.

If domain override exists with the lookup server pointing to itself, it causes the problem. Guess pfsense gets into a loop "ask itself many times" for the entries it can't resolve.