Since the C203 upgrade, I frequently run into DNS issues with my managed corporate device which runs almost completely on the Microsoft stack. Outlook does not connect to Exchange. Several intranet sites are not reachable. The device runs in the blue (WiFi) zone.
All post-C203-upgrade steps are executed. I checked DNS Firewall settings, all lists are unchecked.
Any idea what could be the reason? Are there any DNS logs in IPFire which I could check for hints?
Yes. Go to the Web User Interface (WUI) menu - Logs - System Logs. In the drop down box labelled Section: select Domain Name Server and the date when you have the problem and then press the Update button. You will then see all the log entries related to DNS.
Thanks a lot for the reply. Unfortunately, I do not see any suspicious log entry there. I was looking for something more detailed though. Ideally all DNS requests (and replies) of the day or so. Is something like this available, maybe also via console?
I have now found a publicly available URL which does not work any more in my green and blue networks after the C203 update:
https://de.linkedin.com/in/michael-s-tremer
How do I best proceed debugging from here?
Disable the DNS Firewall. Uncheck all lists and make sure to press the Save button.
Disable the Enable IP Blocklists checkbox if enabled and press the Save button,
Then go to the Firewall rules page and press the Green “Apply changes” button.
Then make sure that the URL Filter checkbox on the Web Proxy page is not enabled. Disable if enabled.
Then at the bottom of the Web Proxy page press the Save and Restart button and after that has completed press the Clear Cache button on the same page.
Then clear your browser cache and then try and access the same URL and see if it then works.
I have no URL Filter or DNS Firewall selected but have the IP Address Blocklist selected, you can see in the above image for that page what lists I have enabled.
I ran that url and got
So on my CU203 system it worked without any issues.
I checked the domain name de.linkedin.com in the IPFire DBL list and it showed that url as being blocked in the Social Networks list
So it would be blocked if using the DNS Firewall option with the Social Networks list enabled but then you would find the response in the System Logs for Domain Name System.
I just enabled the Social Networks list in my DNS Firewall, cleared the browser cache and then tried to access de.linkedin.com and got the message that the access timed out.
In the logs the following line was found
21:29:45 kresd[3681]: [rules ] => local data applied, user: 192.168.26.32, name: de.linkedin.com.
which shows that de.linkedin.com was blocked
Unfortunately, the issues persists.
All DNS firewall lists are disabled (I enabled one and disabled it again to be on the safe side).
IP Blocklists are disabled (I enabled them and disabled them again).
URL Filter is unchecked (I check and and unchecked it again).
Cleared the browser cache. Unfortunately, de.linkedin.com is still not reachable.
I do not see any related entries in System Log, sections Domain Name System or IP Address Blocklists.
In section Domain Name System, every hour or so, I get the following log entries:
| 01:30:36 | knot_resolver.manager.server: | Reloading event triggered… |
|---|---|---|
| 01:30:36 | supervisord: | spawned: ‘policy-loader’ with pid 31979 |
| 01:30:36 | supervisord: | success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) |
| 01:30:37 | kresd[31979]: | [cache ] Cache top initialized using existing data (generic). |
| 01:30:37 | supervisord: | exited: policy-loader (exit status 0; expected) |
| 01:30:38 | knot_resolver.manager.server: | Configuration file successfully reloaded |
Looks like the C203 upgrade somehow broke my IPFire installation. Any further ideas how to proceed from here?
Check your DNS configuration (dns.cgi).
Based on the advice given in previous discussions on this forum:
Avoid using external DNS servers, especially Google DNS (8.8.8.8, 8.8.4.4).
Prefer Recursive DNS, which is the native mode in CU203 using knot-resolver.
New DNS Firewall appears not to be working - #36 by alexand
If you want to use DNS servers and enable the TLS option, make sure that you enter the correct FQDNs for your DNS servers.
After modifying or removing external DNS servers, make sure to click Save at the bottom of the page. Otherwise, the configuration will not be changed.
Those logs are just where it is doing a reloading event of knot. That is totally normal.
Your results so far show that the block of that domain is not occurring due to the DNS Firewall, URL Filter or the IP Blocklists.
The only thing left is if you have some Firewall rule that blocks the IP’s related to de.linkedin.com
Try and access the url and then go to the WUI page Logs - Firewall Logs and then press the Export button. You will get a browser tab showing all the Firewall Log entries and you can then search it (On Firefox with Edit - Find in Page and enter the IP’s for that URL)
The IP’s used by de.linkedin.com are shown from the dig command in the Answer section
dig de.linkedin.com
; <<>> DiG 9.20.26 <<>> de.linkedin.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34453
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;de.linkedin.com. IN A
;; ANSWER SECTION:
de.linkedin.com. 84624 IN CNAME cctld.linkedin.com.
cctld.linkedin.com. 284 IN CNAME cctld.es.lnkdns.net.
cctld.es.lnkdns.net. 284 IN CNAME www.linkedin.com.cdn.cloudflare.net.
www.linkedin.com.cdn.cloudflare.net. 159 IN A 172.64.146.215
www.linkedin.com.cdn.cloudflare.net. 159 IN A 104.18.41.41
;; Query time: 559 msec
;; SERVER: 192.168.26.254#53(192.168.26.254) (UDP)
;; WHEN: Fri Sep 11 12:38:24 CEST 2026
;; MSG SIZE rcvd: 175
If you find any entries in the Firewall Logs with those IP’s, then you can see what is causing them to be dropped or rejected.
If there are no entries with those IP’s then I would say that the blockage is not occurring due to IPFire.
What type of client system are you using when trying to access the URL. Is it a Windows or Linux system.
Do you have Location Blocking enabled?