Is it possible to view entries in the DNS cache?
-
I'm trying to troubleshoot a "Block by default IPv4" rule that doesn't make sense (the default rule on the interface is permit all IPv4 & IPv6 traffic not restricted by any higher priority rule).
My goal was just to whitelist the specific internet host (or hosts) via Aliases. In order to do so I need to see what's in PfSense's DNS cache. If that's possible, I could sort by resolved domain so I can pull out what I'm looking for.
The larger issue is my Synology NAS is unable to connect to the Synology QuickConnect servers. PfSense is blocking it due to the default IPv4 blocking rule - where, as stated above, there is no reason for it to do so as the destination IP matches in the default outbound permit rule.
I've learned the NAS is reaching out to 52.38.239.161. I was able to evaluate a certificate present on the IP and it is a wildcard cert for *.lp.quickconnect.to. While this is useful, it isn't enough to simply add an Alias to it, and corresponding rule permit on the affected interface. Lacking any further useful information from nslookup or whois (it's an IP in an Amazon-owned block), I wanted to see what the DNS cache on PfSense said for any lookups it has performed which resolved to that domain to assist in building the whitelist aliases.
Is there a way to view/dump the DNS cache?
-
Unbound has a control utility (unbound-control) that can dump your cache. Shell in and run:
unbound-control -c /var/unbound/unbound.conf dump_cacheWhy are you locking down your LAN so tightly? This inevitably leads to the problems you are having. Whitelisting by alias rarely works since most of the big sites use CDNs and their domains can resolve to many, many different IP addresses. pfSense only resolves an alias every 10 minutes or so to a single address.
-
I just never understand this... There is one thing where your on a corp network and users are idiots and you are trying to keep themselves from shooting themselves in the head and taking out your whole network, etc. etc.
There is another when your just causing yourself pain.. Its your PC, or other PCs on your network - that I have to assume you control.. And hopefully don't go clicking and running willy nilly any and all code you come across...
Where exactly do you think your nas is going to be going that you have to lock it down to only that?
I could understand your trying to limit your teenage boys from surfing midget p0rn, etc. But seems like all your doing is locking down your own shit from going to its own legitimate stuff because you have some idea this makes you "safer" - can not think of any other reason why anyone would put themselves through this..
You do understand you dicking with your firewall rules because now this doesn't work, and oh shit that doesn't work.. Gawd Dangit - now that doesn't work doesn't make you any more secure ;) What it does do is keep you from actually just using your own shit..
But you go ahead and have fun with that.
-
I'm actually a bit shocked at the tone of your response, John. I believe there is a misunderstanding as to the goal here.
This isn't a matter of locking down something, it's the inverse. For some reason the default IPv4 blocking rule is denying outbound access to a specific IP where a permit-all rule exists.
As a troubleshooting tool, I wanted to get into the cache to understand to what domains these requests are going, so I can resolve and white list them, then observe the results.
There's no locking down happening here. I'm only asking for a method to evaluate what DNS requests have been made through PfSense as a diagnostic aid in discovering what may be unique about a specific scenario.
There is a real possibility this is occurring because of (this and this).
I apologize if I've miscommunicated in any way, and I don't know, maybe you've had a bad day and I'm the unlucky guy to get under your skin. I sincerely apologize if I made your day any worse.
-
@ttmcmurry said in Is it possible to view entries in the DNS cache?:
PfSense is blocking it due to the default IPv4 blocking rule
Sorry, I understood this to mean that you had removed or modified the Default Allow All to Any rule on LAN, so the default deny rule was blocking stuff. Usually default deny doesn't come into play on LAN since you're allowing everything in to the LAN interface.
How about you post a screenshot of your LAN rules so we can see what we're dealing with here.
-
Here are my rules for the inside. The NAS is on the inside @ 10.10.50.50. There are no denies between that IP and the public internet.
Snort and pfBlockerNG are also not interfering, there is no matched traffic blocking - the deny in the log was explicitly the Default IPv4 Deny Rule. I'd share a screenshot of that, but I would need to generate more interesting traffic.
The log entry with the deny was from 10.10.50.50:<random> to 52.38.239.161:443, Flag TCP:A.
I am trying to differentiate between the problem described in the linked articles in my last post and the possibility of whitelisting based on known URL destinations to work around it, hence looking at the DNS cache.
-
@ttmcmurry said in Is it possible to view entries in the DNS cache?:
The log entry with the deny was from 10.10.50.50:<random> to 52.38.239.161:443, Flag TCP:A.
Well that is out of state, that is not a syn.. These are normal for sessions that have expired, or if the states on the firewall have been reset.
Say for example if you wan went down for a say even a minute, and you have it set to reset all states on a loss of wan (which I think is default?).. Now your client doesn't know this - so he thinks hey I was talking to 52.x.x.x just a few minutes ago - and now I want to continue the connection, so send just Ack..
Pfsense says hey wait just a sec there guy - there is no state for that = BLOCK..
You clearly got something odd going on there with all of those easy rules.. Why are you setting those.. Most of that is just noise that should be dropped, not going to go anywhere anyway. LLMNR is name resolution noise for L2 only..
Same shit goes for the WS discovery and mdns - these are all L2 protocols that pfsense can not do anything with anyway.
None of those rules should come into play at all anyway since your bottom any any rule would allow that traffic to not be logged anyway.