Unable to access web UI via IPv4 on LAN

TrueNAS General
,
1

After changing my LAN IP address from 192.168.31.0/24 to 10.32.0.0/16, I can no longer access the web UI via IPv4; only the local domain (hostname.local) and IPv6 are accessible. However, accessing SSH, SMB, and NFS via IPv4 works normally. In Windows network sharing, I cannot directly scan for devices by hostname, and accessing SMB via \\hostname is quite slow.

2

GUI under System → General settings

Check there if you previously set something under “Web Interface IPv4 Address”.

3

I don’t like to assume things, so to verify, is your client system, DNS and router/gateway also on the 10.32.0.0/16 network?

Did you update the GW and DNS fields when you changed the IP in the TrueNAS GUI?

4

@neofusion @Whiskydrinker
No changes were made; I simply changed the LAN DHCP configuration. The TrueNAS network configuration uses DHCP to obtain its settings.

And I confirmed via command (lsof -i:80) that ports 80 and 443 are listening on IPv4.

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nginx 9508 root 7u IPv4 22234 0t0 TCP *:http (LISTEN)
nginx 9508 root 8u IPv6 22235 0t0 TCP *:http (LISTEN)
nginx 9509 www-data 7u IPv4 22234 0t0 TCP *:http (LISTEN)
nginx 9509 www-data 8u IPv6 22235 0t0 TCP *:http (LISTEN)

root@truenas[~]# lsof -i:443
COMMAND  PID     USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
nginx   9508     root    5u  IPv4   22232      0t0  TCP *:https (LISTEN)
nginx   9508     root    6u  IPv6   22233      0t0  TCP *:https (LISTEN)
nginx   9509 www-data    5u  IPv4   22232      0t0  TCP *:https (LISTEN)
nginx   9509 www-data    6u  IPv6   22233      0t0  TCP *:https (LISTEN)

root@truenas[~]# ping 10.32.0.254
PING 10.32.0.254 (10.32.0.254) 56(84) bytes of data.
64 bytes from 10.32.0.254: icmp_seq=1 ttl=64 time=0.281 ms
64 bytes from 10.32.0.254: icmp_seq=2 ttl=64 time=0.330 ms
^C
--- 10.32.0.254 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1029ms
rtt min/avg/max/mdev = 0.281/0.305/0.330/0.024 ms
root@truenas[~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp7s19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
    link/ether bc:24:11:7e:7e:31 brd ff:ff:ff:ff:ff:ff
    inet 10.32.0.1/16 brd 10.32.255.255 scope global dynamic enp7s19
       valid_lft 6752sec preferred_lft 6752sec
    inet6 240e:391:cd8:a911:be24:11ff:fe7e:7e31/64 scope global dynamic mngtmpaddr proto kernel_ra 
       valid_lft 2443757sec preferred_lft 456557sec
    inet6 fe80::be24:11ff:fe7e:7e31/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether ee:ec:8b:47:e1:9d brd ff:ff:ff:ff:ff:ff
    inet 172.16.0.1/24 brd 172.16.0.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fdd0::1/64 scope global nodad 
       valid_lft forever preferred_lft forever
5

As neofusion already wrote, what about the default GW and the DNS resolver - are those both appropriately configured from the DHCP?

You can use those commands from the shell to validate this:

ip r
resolvectl status
cat /etc/resolv.conf
nslookup google.com
nslookup google.com 8.8.8.8

Share the output, if you have a problem to figure it out :wink:

Cheers

6

Yes, I have confirmed that the nameserver is working properly, because I can remotely back up to object storage and check for system updates without any problems.