DNS/DHCP stop working suddenly

stephenw10

OK interesting. Not the SSD then, so that's good.

One CPU core seems to be stuck at 100%. We can only see it's interface io traffic so something attempting (and seemingly failing) to send or receive. From the fact tailscale could not be stopped I'd guess it's that somehow. Are you able to disable that as a test?

michmoor

@stephenw10
I have uninstalled Tailscale.
I’m glad I got some more data on this so thanks for the assistance.

If this is a bug - let’s say it might be for sake of conversation - I don’t have much data to prove this isn’t just environmental to my setup. Any other data points I can gather?
Losing a WAN ip address does make Tailscale chatty but i can’t find the link to why dns breaks for local resolution.

stephenw10

It looks like whatever is using that CPU core is preventing anything sending/receiving traffic or possible opening states. Causing problem for numerous services.

michmoor

@stephenw10
Interesting and i love that theory. Seems very logical.
Would explain why almost all functionality related to the firewall is broken - web-configurator , dns , dhcp...
Considering the 6100 has 4x cores, its not odd that a single core choking the firewall breaks connectivity?

edit: So whatever is using that core is related to traffic? High throughput? This 6100 can for sure push well over 10G from my testing but looking at the monitoring i see pretty low WAN throughput considering.
Tailscale seems like the smoking gun but checking my historical syslog it seems that once ix3 (WAN) goes down and cant renew a dhcp address, tailscale becomes very verbose. As i discovered today i am unable to reboot the router because it gets stuck on the tailscale process. High level but the trigger is losing the WAN.
If we're stable this weekend, i will install tailscale again and unplug the wan..see if i can reproduce.

stephenw10

@michmoor said in DNS/DHCP stop working suddenly:

Considering the 6100 has 4x cores, its not odd that a single core choking the firewall breaks connectivity?

It is I agree. Though I'm assuming it's choking something in the network stack so it doesn't matter than then other cores are still available.

tinfoilmatt

@michmoor said in DNS/DHCP stop working suddenly:

I went ahead and went for the reboot through console. It could not stop the Tailscale package. This forced me to pull the plug and plug it back in.

what's the longest you waited for the system to shutdown gracefully when it appeared to be 'stuck" stopping Tailscale package? conservative estimate in minutes...

michmoor

@cyberconsultants
maybe 5mins or so.
Reboots generally do not take long

@stephenw10 so far since the TS package removal things have been stable since. I’ll add the package tomorrow and let you know how things go.

tinfoilmatt

@michmoor five minutes doesn't seem reasonable given documented precaution:

https://docs.netgate.com/pfsense/en/latest/diagnostics/system-halt.html

...and what you seemed to be dealing with more specifically.

abrupt and repeated power losses over time might be closer in line with your 'root cause' than any particular package. i personally think it'd be advisable to make not cutting the power until you've waited at least an unreasonable period of time given the specific reboot context (sysem updates, maintenance, system crash, etc.) a more regular practice.

pfSense is a software firewall that doesn't load its config strictly out of NVRAM like typical consumer devices often do. despite filesystem and backup/recovery/snapshot improvements over time, OS corruption is still a real concern with abrupt loss of system power.

stephenw10

In reality I don't think I've ever seen a correctly functioning install take more than 5 mins to shutdown.

tinfoilmatt

@stephenw10 said in DNS/DHCP stop working suddenly:

In reality I don't think I've ever seen a correctly functioning install take more than 5 mins to shutdown.

so you would pull the physical power after five minutes of Stopping package Tailscale... in some kind of unstable system state?

stephenw10

If the console was hung at that point then yes. I might try hitting ctl+t first to see what it's actually waiting for. That won't allow it to continue but might give a clue as to why it failed.

tinfoilmatt

@stephenw10 said in DNS/DHCP stop working suddenly:

If the console was hung at that point then yes. I might try hitting ctl+t first to see what it's actually waiting for. That won't allow it to continue but might give a clue as to why it failed.

lol

michmoor

@stephenw10
Hey Stephen,
It happened again. I collected some data to help diagnose

I initially SSH'd to my firewall and was able to run a top -aSH.

last pid: 37748;  load averages:  5.19,  5.30,  5.34                                                                                                         up 5+14:27:25  06:36:49
536 threads:   10 running, 488 sleeping, 38 waiting
CPU:  1.1% user,  0.0% nice, 26.6% system,  0.1% interrupt, 72.3% idle
Mem: 471M Active, 1981M Inact, 1400M Wired, 3937M Free
ARC: 341M Total, 106M MFU, 214M MRU, 2972K Anon, 2640K Header, 14M Other
     267M Compressed, 972M Uncompressed, 3.64:1 Ratio
Swap: 1024M Total, 1024M Free

  PID USERNAME    PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
    0 root        -60    -     0B  2160K CPU3     3 260:17  99.91% [kernel{if_io_tqg_3}]
   11 root        187 ki31     0B    64K CPU0     0 127.5H  96.51% [idle{idle: cpu0}]
   11 root        187 ki31     0B    64K CPU1     1 126.0H  95.49% [idle{idle: cpu1}]
   11 root        187 ki31     0B    64K RUN      2 126.7H  95.47% [idle{idle: cpu2}]
98424 unbound      23    0   179M   139M kqread   1   0:06   3.65% /usr/local/sbin/unbound -c /var/unbound/unbound.conf{unbound}
98424 unbound      21    0   179M   139M kqread   2   0:05   2.39% /usr/local/sbin/unbound -c /var/unbound/unbound.conf{unbound}

I noticed that my WAN IP has changed. Being on ATT fiber it has remained the same for over two years but its DHCP so now its time to change.

All logging stopped at the same time

-rw-------  1 root       wheel       572K Mar  7 02:29 filter.log.1.bz2
-rw-------  1 root       wheel       534K Mar  7 02:35 filter.log.0.bz2
-rw-------  1 root       wheel       214K Mar  7 02:37 resolver.log.1.bz2
-rw-------  1 root       wheel       149K Mar  7 02:39 resolver.log.0.bz2
-rw-------  1 root       wheel       2.9M Mar  7 02:39 auth.log
-rw-------  1 root       wheel       938K Mar  7 02:39 dhcpd.log
-rw-------  1 root       wheel       3.1M Mar  7 02:39 gateways.log
-rw-------  1 root       wheel       544K Mar  7 02:39 ntpd.log
-rw-------  1 root       wheel       2.6M Mar  7 02:39 nginx.log
-rw-------  1 root       wheel       2.8M Mar  7 02:39 routing.log
-rw-------  1 root       wheel       2.5M Mar  7 02:39 ipsec.log
-rw-------  1 root       wheel       2.5M Mar  7 02:39 openvpn.log
-rw-------  1 root       wheel       6.5M Mar  7 02:39 system.log
-rw-------  1 root       wheel       8.4M Mar  7 02:39 filter.log
-rw-------  1 root       wheel       426K Mar  7 02:39 resolver.log
-rw-------  1 freeradius freeradius  879K Mar  7 02:40 radius.log
-rw-r--r--  1 root       wheel       591B Mar  7 06:36 utx.lastlogin
-rw-------  1 root       wheel        22K Mar  7 06:36 utx.log

I still couldn't get to the GUI on the LAN side as it was unresponsive so from SSH I went ahead with the reboot. It was stalling on stopping certain packages so I did ctrl t

Netgate pfSense Plus is rebooting now.
 Stopping package arpwatch...done.
 Stopping package freeradius3...done.
 Stopping package lldpd...done.
 Stopping package WireGuard...
load: 5.71  cmd: php_wg 65403 [nanslp] 10.49r 0.68u 0.07s 3% 53036k
done.
 Stopping package haproxy...done.
 Stopping package nut...done.
 Stopping package syslog-ng...done.
 Stopping package softflowd...done.
 Stopping package suricata...

 Stopping package suricata...
load: 5.59  cmd: php-cgi 56784 [nanslp] 35.07r 0.54u 0.04s 0% 53360k

Waiting over an hour...........yes an hour...pfsense never came back from the reboot and within that hour I lost access to the shell. So I went in through the console and the console was flooded with the following logs.

arpresolve: can't allocate llinfo for 192.168.1.254 on ix3

I couldn't access anything else via console. Just the flooding of the arpresolve log tied up anything. Even disconnecting the ix3 interface from the ATT modem didn't matter..arpresolve still kept flooding console.

Finally, a reboot fixed it. Back online..

tinfoilmatt

@michmoor sounds like a simple gateway alarm/action triggering a cascade of headache. you might review configuration of the packages whose services you're not allowing to stop, likely compounding the kludge each time you do. it'll only get longer and kludgier if you keep "resolving" it the way you are.

Suricata initialization (both start and stop) is what's causing those arpresolve kernel notices.

stephenw10

Do you have the service watchdog installed? That can cause problems with stopping services when incorrectly used. It should only really be used for debugging. You would see that logged though.

michmoor

@stephenw10
When @cyberconsultants mentioned suricata i did immediately go to my service watchdog and I have the following enabled.

This is a set up Ive had for years now. I don't mind removing these services from monitoring but i don't see how it prevented a reboot. Ive upgraded/rebooted many times with these enabled.

edit: I would also say that its likely something environmentally changed here but I have no idea what it could be. Short of adding a firewall rule, the config is static. Goes down for an upgrade every few months. So whatever is causing a cascade of headaches for me (love the term) its proving difficult to isolate.

stephenw10

Well the service watchdog should log if it restarts anything so I'd expect to see that in the system logs. Unless it's not logging anything of course.

It's an easy test to remove those though. Unbound is the only thing I could imagine being an issue though.

NollipfSense

Very interesting diagnosing here, indeed and Steve is bad to the bone!

stephenw10

Not sure about that. Come back to me if/when we find the root cause.

tinfoilmatt

@stephenw10 it's pretty obviously, based on OP's detailed posts and a fair bit of 'reading between the lines,' triggered gateway monitoring action following either transiest latency/loss of connecitivty or DHCP lease renewal.

the rest of it is just system tailspin—which in fairness would, in all likelihood, eventually recover given enough time to do so. BSD and pfSense be solid like that.