Random internet connection drops
-
@Raffi_ Yes that's a typo, 87 % full of course :D Thanks for the advise, I change it to Google DNS :)
-
If you have trouble again, try clearing your blocks tab (assuming legacy mode) in Suricata and then refresh the web page. If that immediately solves it, then you have to look into your rules to figure out what is triggering the block.
-
@Raffi_ My Suricata has been on blocking mode about 24 hours so that's not the problem. Will paste logs when the outage happens again!
-
Blocking is disabled in Suricata? It is only used for monitoring?
-
@Raffi_ It was only for monitoring, I collected logs to and viewed them in separate platform. But now it is in blocking mode, just configured it!
-
If you are having trouble loading sites. I would advise to disable blocking mode for now and go back to monitoring. Also, when you disable blocking, you still have to clear the blocks tab in order to allow that traffic to pass again.
-
I think that it happened again. Was playing playstation and tried to look someones profile and eventually playstation informed me that there is something wrong with DNS. Immediately went to Pfsense, took a glance at the logs and noticed that there are events like this:
Aug 31 18:27:29 unbound 79372:0 info: start of service (unbound 1.9.1). Aug 31 18:27:29 unbound 79372:0 notice: init module 1: iterator Aug 31 18:27:29 unbound 79372:0 notice: init module 0: validator Aug 31 18:27:07 unbound 79372:0 notice: Restart of unbound 1.9.1. Aug 31 18:27:07 unbound 79372:0 info: server stats for thread 3: requestlist max 2 avg 1 exceeded 0 jostled 0 Aug 31 18:27:07 unbound 79372:0 info: server stats for thread 3: 3 queries, 0 answers from cache, 3 recursions, 0 prefetch, 0 rejected by ip ratelimiting Aug 31 18:27:07 unbound 79372:0 info: server stats for thread 2: requestlist max 2 avg 1 exceeded 0 jostled 0 Aug 31 18:27:07 unbound 79372:0 info: server stats for thread 2: 3 queries, 0 answers from cache, 3 recursions, 0 prefetch, 0 rejected by ip ratelimiting Aug 31 18:27:07 unbound 79372:0 info: server stats for thread 1: requestlist max 2 avg 1 exceeded 0 jostled 0 Aug 31 18:27:07 unbound 79372:0 info: server stats for thread 1: 3 queries, 0 answers from cache, 3 recursions, 0 prefetch, 0 rejected by ip ratelimiting Aug 31 18:27:07 unbound 79372:0 info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0 Aug 31 18:27:07 unbound 79372:0 info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting Aug 31 18:27:07 unbound 79372:0 info: service stopped (unbound 1.9.1). Aug 31 18:27:07 unbound 79372:2 info: generate keytag query _ta-4f66. NULL IN Aug 31 18:27:07 unbound 79372:0 info: start of service (unbound 1.9.1). Aug 31 18:27:07 unbound 79372:0 notice: init module 1: iterator Aug 31 18:27:07 unbound 79372:0 notice: init module 0: validator Aug 31 18:26:45 unbound 79372:0 notice: Restart of unbound 1.9.1.From DHCP logs I saw this
Aug 31 18:26:45 dhcpleases Sending HUP signal to dns daemon(79372) Aug 31 18:26:45 dhcpleases Sending HUP signal to dns daemon(79372)I googled it and based on that I unticked the option "Register DHCP leases in the DNS Resolver" from my router. I will see if that helps.
-
Hmm, 27s seems excessive for Unbound to restart. Do you have pfBlocker running with DNS-BL enabled and a lot of lists?
Steve
-
@stephenw10 I do have quite a list on DNSBL.
-
Hmm, OK if it takes that long reloading then adding dhcp leases probably isn't a practical option. That is probably what you're hitting there.
Steve
-
Good catch @JohanÅ ! Yea, I agree with Steve on this. The combination of large pfblocker lists and the register DHCP leases option in unbound has high potential for trouble. I had to disable DHCP registration in resolver also. Let us know how it goes.