Bug 13994

Summary: Cannot access WUI via FQDN, only IP
Product: IPFire Reporter: Adolf Belka <adolf.belka>
Component: ---Assignee: Assigned to nobody - feel free to grab it and work on it <nobody>
Status: CLOSED FIXED QA Contact:
Severity: - Unknown -    
Priority: - Unknown - CC: michael.tremer
Version: 2   
Hardware: unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 13972    

Description Adolf Belka 2026-05-27 11:49:40 UTC
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
Comment 2 Adolf Belka 2026-05-28 11:32:54 UTC
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
Comment 3 Michael Tremer 2026-05-28 13:35:36 UTC
(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?
Comment 4 Adolf Belka 2026-05-28 15:49:14 UTC
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.
Comment 6 Adolf Belka 2026-06-11 10:44:50 UTC
Confirmed to be working.
Comment 7 Michael Tremer 2026-07-20 16:14:17 UTC
Core Update 203 has been released:

> https://www.ipfire.org/blog/ipfire-2-29-core-update-203-released