Thousands of outgoing DNS(?) blocked per hour
-
@py said in Thousands of outgoing DNS(?) blocked per hour:
@bmeeks said in Thousands of outgoing DNS(?) blocked per hour:
You really should consider taking that router out of the path and letting pfSense do everything. If you need the router for wireless, then see about converting it to simple AP mode. Most can be reconfigured to do this. Let pfSense do DHCP, routing and NAT.
I might have to do that, and I know my router can be configured for AP mode. Something new to learn....
Thanks.
It all seems to be coming from your router because it is performing another NAT behind pfSense. It is translating all the IP addresses behind it to the router's IP address on its WAN side where pfSense is connected. This is why you really don't want (or need) double-NAT.
-
I'm having the same issue. The source address of the request is a device on my LAN. The destination is google dns. This is from a Samsung device that has google DNS hard coded in it. I have no double NAT on my network. I tried to pull the URL it uses for it's list, and it redirects to some blog page. I'm thinking I'm going to turn the ISC 30 off for now until I'm able to poll the URL and get a proper list back.
Jan 10 20:32:55 [104] VLAN50 pfB_PRI1_v4 1770010781) UDP 10.37.50.44:37132 Unknown 8.8.8.8:53 dns.google US ISC_1000_30_v4 8.8.8.8 -
@realityman_ You should really start your own thread; however, open all your devices and see which one has a DNS other than pfSense 192.168.1.1...simple!
-
@py I don't have time to re-configure my network right now to switch the router to AP mode, (too many VLANs), but I was able to isolate the problem to the router itself, (disconnected everything and turned off the radios and got same behavior). I also reset the router to default settings, cleared the NVRAM and powered it off for 30 minutes while I rerouted cables in preparation for re-configuring it to AP mode, (again same behavior when it was powered back on).
I would like to know why this particular feed, (ISC_1000_30_v4), is listing this behavior as malicious. Hopefully that may give me more information as to what it is I'm up against, and perhaps a way to fix it. I haven't found a place on the ISC website that specifies such things.
Again, if it's of any use, this started in the wee hours of Friday morning.
Any help appreciated.
-
If you want to let the traffic go thru, you can suppress it.
If you have to restrict DNS traffic out, there is a way to redirect all DNS traffic to pfsense using FW Rules.
https://docs.netgate.com/pfsense/en/latest/dns/redirecting-all-dns-requests-to-pfsense.html -
@RonpfS said in Thousands of outgoing DNS(?) blocked per hour:
If you want to let the traffic go thru, you can suppress it.
If you have to restrict DNS traffic out, there is a way to redirect all DNS traffic to pfsense using FW Rules.
https://docs.netgate.com/pfsense/en/latest/dns/redirecting-all-dns-requests-to-pfsense.htmlThanks, but I'm pretty sure this is not legitimate DNS traffic or the ISC_1000_30_v4 feed of pfBlockerNG would not be blocking it.
Would it?
The last thing I want is DNS queries going to google so I have incorporated the config at that link and I'll see what happens.
-
@py said in Thousands of outgoing DNS(?) blocked per hour:
the ISC_1000_30_v4 feed of pfBlockerNG would not be blocking it.
Well my ISC_1000_30_v4 table only has on ip : 45.76.66.122
From my log file :
[ PRI1_ISC1000_30_v4 ] [ 01/11/20 20:15:07 ] ( md5 feed ) cURL Error: 28 Operation timed out after 15007 milliseconds with 0 out of 0 bytes received Retry in 5 seconds... . cURL Error: 28 Connection timed out after 15005 milliseconds Retry in 5 seconds... . cURL Error: 28 Connection timed out after 15023 milliseconds Retry in 5 seconds... .. unknown http status code | 0 Failed to download Feed for md5 comparison! Update skipped ... [ PRI1_ISC1000_30_v4 ] Downloading update .. 200 OK. completed .. [ pfB_PRI1_v4 PRI1_ISC1000_30_v4 ] No IPs found! Ensure only IP based Feeds are used! ]Trying to open the URL in a browser fails. Maybe the web site changed the location of the date, or maybe the data is no longer provided.
Just disable the URL for now. -
@RonpfS Realized pfBlocker IS NOT snort or suricata, which is what made me think it was not DNS lookups. Implemented the suggested DNS redirect from those links and the constant DNS hits to pfsense stopped, thanks.
I don't know why 8.8.8.8 would be listed in a pfBlockerNG feed, but I'm grateful it was because it made me aware of some mis-configurations in my network.
-
I'm new to using pfBlocker (about 3 weeks now) and poking around today I noticed something in my pfBlocker setup that might explain what you are seeing. In the pfBlocker Reports->Alerts->Alert Settings (which is normally a collapsed menu when you open the tab), there is a selection for a DNS IP address to use for resolving whitelist CNAMEs. In my configuration this was set to 8.8.8.8, which is not the same DNS address my DHCP server hands out.
This setting seems to be specific to pfBlocker, defaults to 8.8.8.8, and is normally on a collapsed menu that you might not normally think to mess with. I changed my selection today and I'll watch access to 8.8.8.8 for a while.
Matthew
-
This DNS server will only be used when you use the Alerts Tab "+" icon to whitelist a Domain.
