DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times
-
f#$k this looks wide open. i dunno how that happened it says it comes from OpenVPN wizard. Is this wrong? Should Destination port be changed from asterix to 1194?
-
@RickyBaker login-to-view
also, DEF didn't put in this rule, that ip address is my Synology box, think it added this rule via UPNP? -
@RickyBaker I would guess, it was edited at some point and the description remained. If you look at the rule without saving it, it will show a created and last saved date at the bottom.
Yes it should be 1194 UDP.
The floating rule could be from traffic shaping? (per the m_P2P text)
-
@SteveITS this look right then? login-to-view
disabled the floating rule and made this change and still have access to the pfsense remotely so seems to not have broken the openvpn connection, thank you for the confirmation.
I would LOVE to do traffic shaping but I have not actually attempted it in many years and recently redid all the rules to add VLANs so i'm very puzzled by this (I also don't even use the Synology really) but you are absolutely right that qP2P sure looks like a traffic shaping effort...very disconcerting
-
@RickyBaker yes that looks better and will not allow connections to 22/80/443.
What is the date on the floating rule? (bottom of the edit rule page)
-
@SteveITS that's it, Created and Updated 2/4/17 by Traffic Shaper Wizard. That was pre kids and pre VPN. Thanks for teaching me that trick. happy to just disable, possibly just delete
-
@SteveITS thanks so much for your help with this. Assuming for the best that the attacker was not able to gain access, what is my next steps? Could this have caused my weird DNS/DHCP problems or is this just a "happy" coincidence that y'all helped me find this vulnerability.
Currently tracking down the 4 DHCP leases that aren't statically assigned. FIgured out 2 of them, need to google Part II research for the 3rd and the 4th was idle so i just booted it
-
@RickyBaker I think it's just a coincidence but a fortunate one.
Is there anything notable in the DNS Resolver log when the outage happens?
-
The final device has this mac address manufacturer. The most common device seems to be a Dreo fan (which I don't have). Googling isn't ringing any bells and pointing to the IP address doesn't give me a splash page or anything. Any advice on blocking just this mac address so I can see what breaks?
@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
Is there anything notable in the DNS Resolver log when the outage happens?
Surprisingly sparse....
-
@RickyBaker the DHCP log seems like all the same as well:
login-to-view -
@RickyBaker if your DNS outage wa around 6:26-6:40 and you have DHCP set to register leases in DNS, unbound would have restarted a bunch of times there.
re: MAC, it has to be something on the network. You could find its IP on the Status/DHCP leases page and create a rule on LAN to block (or allow, and/or log) it.
-
@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
if your DNS outage wa around 6:26-6:40 and you have DHCP set to register leases in DNS, unbound would have restarted a bunch of times there.
per @johnpoz suggestion i have unchecked "Register DHCP", should I re-enable for testing purposes?
@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
re: MAC, it has to be something on the network. You could find its IP on the Status/DHCP leases page and create a rule on LAN to block (or allow, and/or log) it.
good suggestion. I THINK i found it. My wife recently purchased a fancy humidifier that, for some reason, has internet connectivity. So i will confirm when i'm home but that's most likely it...So no errant devices that aren't accounted for aside from the stale lease i booted.
-
@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
i have unchecked "Register DHCP", should I re-enable for testing purposes
No, having it on is unlikely to help here. It's hard to keep track of multiple threads over a few days...
So is unbound no longer restarting? But still the errors? I do not have another idea. Perhaps, on the DNS Resolver advanced page raise Log Level temporarily and see if that provides any info.
-
@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
This is going to restart unbound..
i thought this was fixed last year, no?
-
@michmoor said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
thought this was fixed last year, no?
nope still open
https://redmine.pfsense.org/issues/5413 -
@michmoor said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
i thought this was fixed last year, no?
update: https://forum.netgate.com/topic/187506/kea-dhcp-feature-roadmap/6
-
@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
per @johnpoz suggestion i have unchecked "Register DHCP", should I re-enable for testing purposes?
Certainly not ;) Keep it of.
Your DHCP log image above show about 10 DHCP request/renewals in let then (42-26)=16 minutes.
That means 10 unbound restart in 16 minutes ...
Every restart takes ... 30 seconds ? So during this 16 minutes your DNS is 'out' for 5 minutes.
That's not good at all.And before you start to think : isn't that totally flawed ?
Yes, it is. But help is coming - see here what cmcdonald said this morning.
( some of us are waiting for this to happen ... ten years )@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
f your DNS outage wa around 6:26-6:40 and you have DHCP set to register leases in DNS, unbound would have restarted a bunch of times there.
Exact.
As I said above.
Or, his unbound doesn't restart that often. Not 10 x in 16 minutes ^^@RickyBaker : I saw you use 10.10.10.x as a LAN network
You don't use pfBlockerng, right ? -
@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
So is unbound no longer restarting? But still the errors? I do not have another idea. Perhaps, on the DNS Resolver advanced page raise Log Level temporarily and see if that provides any info.
i mean, there was no indication to me other than the log that it was restarting. so I guess it's not? I will raise the log level of the DNS Resolver....cause it happened again this morning. Text from my wife 8:26am:
system.log:
login-to-view
DHCP log:
login-to-view
Nothing new in the DNS Resolver log@Gertjan said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
You don't use pfBlockerng, right ?
I don't (intend to) but during this thread it's been clear things I did years ago have left breadcrumbs of settings I didn't intend. Where would I check?
@Gertjan said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
That's not good at all.
Not to get too in the weeds, but what is Register DHCP used for if it's that unwieldy?
-
@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
raise Log Level temporarily and see if that provides any info.
login-to-view
I went to do this in the advanced settings and when i saved (I've never changed anything in Advanced Settings of dns resolver to my knowledge) I got this error:
login-to-view
So i disabled that, but maybe that was causing issues? -
@RickyBaker the sshguard log entries are irrelevant by themselves, but it showing every 3 minutes means you have a large amount of logging going on somewhere, and a log is rotating every 3 minutes.
The DHCP log looks like it is assigning the same address multiple times (10.10.10.177)? Are you using Kea or ISC? If Kea change back to ISC since Kea is still in preview mode. If ISC there was a bug in the initial release of 23.09 but IIRC that was fixed in a slipstream a few days later and then fixed in 23.09.1.
re: pfBlocker, it is in the Firewall menu, or would be an installed package.