In all my fresh installs of CU203 I have been unable to access the WUI via the fqdn but can access it via the IP with no problems. Even after I have confirmed that knot is running it still fails to access the WUI. On the green client running ping -c4 IP gets a normal ping response. Running ping -c4 fqdn gets ping: fqdn: Temporary failure in name resolution
> https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=8b3db73f71b2cec9d24875064a4363fdfd820956 Nice find. Solved.
Tested on Development Build: next/07805a0e but still not working. What I see in the domain name system logs are lines like 13:12:43 supervisord: captured stdio output from kresd0[2023]: Called for skrymir.saturn.pimb.org.saturn.pimb.org. (1) 13:12:43 supervisord: captured stdio output from kresd0[2023]: 13:12:43 supervisord: captured stdio output from kresd0[2023]: Called for skrymir.saturn.pimb.org.saturn.pimb.org. (28) 13:12:43 supervisord: captured stdio output from kresd0[2023]: Called for 0.ipfire.pool.ntp.org.saturn.pimb.org. (28) 13:12:43 supervisord: captured stdio output from kresd0[2023]: Called for pakfire.ipfire.org.saturn.pimb.org. (1) 13:12:45 supervisord: captured stdio output from kresd0[2023]: Called for 1.ipfire.pool.ntp.org.saturn.pimb.org. (1) 13:12:45 supervisord: captured stdio output from kresd0[2023]: Called for 1.ipfire.pool.ntp.org.saturn.pimb.org. (28) 13:12:45 supervisord: captured stdio output from kresd0[2023]: Called for 1.ipfire.pool.ntp.org.saturn.pimb.org. (1) It looks to me like the IPFire domain name has been added to the ends of every fqdn being accessed, so trying to access the wui with fqdn of skrymir.saturn.pimb.org is shown in the dns logs as skrymir.saturn.pimb.org.saturn.pimb.org So https://skrymir.saturn.pimb.org:444 fails to access the wui but https://192.168.200.254:444 works fine. Confirmed that build next/07805a0e contains the commit for Load /etc/hosts
(In reply to Adolf Belka from comment #2) > Tested on Development Build: next/07805a0e but still not working. > > What I see in the domain name system logs are lines like > > 13:12:43 supervisord: captured stdio output from kresd0[2023]: Called for > skrymir.saturn.pimb.org.saturn.pimb.org. (1) > 13:12:43 supervisord: captured stdio output from kresd0[2023]: > 13:12:43 supervisord: captured stdio output from kresd0[2023]: Called for > skrymir.saturn.pimb.org.saturn.pimb.org. (28) > 13:12:43 supervisord: captured stdio output from kresd0[2023]: Called for > 0.ipfire.pool.ntp.org.saturn.pimb.org. (28) > 13:12:43 supervisord: captured stdio output from kresd0[2023]: Called for > pakfire.ipfire.org.saturn.pimb.org. (1) > 13:12:45 supervisord: captured stdio output from kresd0[2023]: Called for > 1.ipfire.pool.ntp.org.saturn.pimb.org. (1) > 13:12:45 supervisord: captured stdio output from kresd0[2023]: Called for > 1.ipfire.pool.ntp.org.saturn.pimb.org. (28) > 13:12:45 supervisord: captured stdio output from kresd0[2023]: Called for > 1.ipfire.pool.ntp.org.saturn.pimb.org. (1) This is probably coming from the client and we cannot do anything about that. > It looks to me like the IPFire domain name has been added to the ends of > every fqdn being accessed, so trying to access the wui with fqdn of > skrymir.saturn.pimb.org is shown in the dns logs as > > skrymir.saturn.pimb.org.saturn.pimb.org > > > So https://skrymir.saturn.pimb.org:444 fails to access the wui but > https://192.168.200.254:444 works fine. > > Confirmed that build next/07805a0e contains the commit for Load /etc/hosts Okay, but if that file has been loaded, we should see the entry for the host in there. Could you run the query with a simple dig command and see what the resolver is actually responding with?
From my client on green I ran dig skrymir.saturn.pimb.org and got the following info dig skrymir.saturn.pimb.org ; <<>> DiG 9.20.23 <<>> skrymir.saturn.pimb.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24813 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;skrymir.saturn.pimb.org. IN A ;; ANSWER SECTION: skrymir.saturn.pimb.org. 9 IN CNAME saturn.pimb.org. saturn.pimb.org. 14 IN A XX.XXX.XXX.XXX ;; Query time: 1 msec ;; SERVER: 192.168.200.254#53(192.168.200.254) (UDP) ;; WHEN: Thu May 28 17:23:56 CEST 2026 ;; MSG SIZE rcvd: 82 So it is getting the public IP from its gateway which is my main IPFire. The contents of /etc/hosts on skrymir is 127.0.0.1 localhost.localdomain localhost 192.168.26.254 gateway and 192.168.26.254 is my main IPFire's green interface that the red interface from skrymir is connected to. The /etc/hosts file on the CU202 version of skrymir is the same but on that system if I run the dig command from the green client machine I get the following dig skrymir.saturn.pimb.org ; <<>> DiG 9.20.23 <<>> skrymir.saturn.pimb.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47563 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;skrymir.saturn.pimb.org. IN A ;; ANSWER SECTION: skrymir.saturn.pimb.org. 60 IN A 192.168.200.254 ;; Query time: 0 msec ;; SERVER: 192.168.200.254#53(192.168.200.254) (UDP) ;; WHEN: Thu May 28 17:47:12 CEST 2026 ;; MSG SIZE rcvd: 68 which is giving me the correct private address for skrymir.
https://www.ipfire.org/blog/ipfire-2-29-core-update-203-is-available-for-testing
Confirmed to be working.
Core Update 203 has been released: > https://www.ipfire.org/blog/ipfire-2-29-core-update-203-released