Firewall time out of sync. 7 hours ahead of actual system time
-
As the title states, when I check the firewall in the system logs, it will always be 7 hours ahead of the system time. All of the other logs time corresponds exactly to the system time on the main page. I feel that this is what may be causing another issue that I have, which is that all of my firewall blocklists can't resolve their respective urls with cURL code 6. This only seems to not only affecting the IP firewall logs, as I am also seeing the time discrepency when the system does a sync during a check_reload_status. Local time was 9:53 PM on may 11th when this screenshots was taken
-
So you changed time zones? Have you rebooted since you changed the time zone?
https://forum.netgate.com/topic/142407/timestamp-in-firewall-logs-is-wrong -
well, how embarassing. that fixed the hour issue. The only thing remaining is the cURL code 6 and the lists not updating due to them not resolving
I whitelisted the domains, just in case, and put the lists in FLEX vs ON mode, but still the issue persists.
I can get to the websites just fine through a browser, but it will not resolve within pfsense.
-
what what do you have pfsense pointing to for dns, out of the box it should be pointing to itself and resolving.
If your browser is pointing to pfsense, and pfsense points to itself then it would be working - so you got some thing not right there.
-
@johnpoz i have it set up to resolve dns itself. The rules that I have set up for LAN in order to prevent DNS leaks. Maybe something is up with the rules, which is causing this?
Below are the DNS resolver logs
-
@johnpoz How can I find out why these simple hosts will not resolve?
-
@johnpoz It appears that Pfsense is unable to resolve anything itself
-
@themadsalvi had to reload from a previous config to try and salvage the unbound resolver. Was able to get it to come back up and resolve after that and a restart.
-
Hi,
This answer came back right away with "not resolved", or did it take some time ?
The unbound process was running ? You had a look at the DNS log the same moment that that request was handled by unbound.
Etc.
That's a PTR lookup - a reverse lookup is IP to FQDN.
It should answer :
Btw : the first 2 images, at the top of the thread, are your LAN and WAN (interface names are curt of, so the rules have no meaning at worst, tend to confusing at least) ?
Well .... what to say : looks messy.Several identical UDP/VPN /1194 NAT (?) rules on WAN.
Several identical rules on LAN - but DNS traffic comes in from the LAN clients (forced to use pfSense as a DNS, that part seems ok). -
Yeah those rules are a MESS... In what scenario is pfsense running plex? You have a rule that says ok to hit your lan address on 32400..
Then you have a rule on your wan with lan address is source??? WTF? Clearly you do not understand how the rules are evaluated.. It would be impossible for your wan to see lan address source.
You have a any rule on your wan for whitelist... This HORRIBLE!!! Have brought this up in another thread... pfblocker allowing this to happen is HORRIBLE!!! Security issue for sure..
Your resolving - and your worried about dns leak? You understand that every dns query will come directly from your wan IP right? That is how resolving works.
What I would suggest is start freaking over!!! Validate that pfsense is working out of the box with the default setup, no pfblocker.. No nonsense rules with redirecting dns, etc.. Then if you want to stop clients from using other dns then do that..
Also 8.8.8.8. with the period on the end like that is now asking it to resolve that as name.. not as a ptr..
Host "8.8.8.8." could not be resolved.
Would be what you should get..
Your also asking those 2 other dns.. In your other when you get host google.com could not be resolved... This would point to maybe dns manipulation, or dnssec failing, etc...
Lets start from a clean slate and figure out why you can not resolve... From your log there when you asked for that arpa you got a NX... Which is correct I get NX for that as well.
$ dig -x 185.216.34.228 ; <<>> DiG 9.14.1 <<>> -x 185.216.34.228 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57661 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;228.34.216.185.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 185.in-addr.arpa. 3600 IN SOA pri.authdns.ripe.net. dns.ripe.net. 1557734757 3600 600 864000 3600 ;; Query time: 548 msec ;; SERVER: 192.168.3.10#53(192.168.3.10) ;; WHEN: Mon May 13 03:59:55 Central Daylight Time 2019 ;; MSG SIZE rcvd: 116
