Cannot change IP address of TrueNAS CE

TrueNAS General
,
1

Cannot change IP address of TrueNAS CE

The general situation:
TrueNAS CE ElectricEel-24.10.2.2 on 192.168.0.200
br0 192.168.0.200/24 and 192.168.0.253/32 with enp8s0 as sole member
pfSense 2.8 CE on 192.168.0.1 (why not 192.168.1.1? see below)
Main LAN is LAN1 192.168.0/16
Also LAN2, LAN3 but no devices on these
No VLANS
Firewall rules open (any LAN to any LAN)
No external ports
A broad spread of IP addresses on the /16 network while I get things separated (eg: network infrastructure on 192.168.2.x, wireless APs on 192.168.3.x, trusted servers [inc TN] on 192.168.20.x, and so on)

I have a lot of IT experience but am a network n00b and recently got started with pfSense and a couple of used Cisco managed switches. have had a nightmare with HAProxy but that’s another thread. Today’s project was to group devices on my network into fake subnets (hence the /16 network) before the next step which would be separate LANs or VLANS or something. Everything I do seems to be a battle due to my lack of knowledge, hence the baby step of broadening the 192.168 network into a /16 and this also gain more network experience and try to develop some sort of intuitive grasp of this stuff.

LAN1 and pfSense server started out on 192.168.0.0/24 because those were the static addresses I’d assigned through my ISP’s router and I wanted to make the transition to pfSense smooth and avoid a “big bang” change. That worked fine. Next step was to move to a 192.168.1.0/24 network and that also started out okay. Then I decided to make the network into a /16 so there was loads of space to divide devices into groups.

That also went well until I tried to move TN’s IP from 192.168.0.200 to 192.168.20.1 and the gateway from 192.168.0.1 to 192.168.1.1.

My method is AFAICT according to the instructions: change the IP alias for br0 from 192.168.0.200/24 to 192.168.20.1/16, save the changes, test the configuration, open up a new browser tab to the new target address and if the test is successful then save the TN network config change there.

The problem is that nothing I try works. I moved my laptop back to a 192.168.0.120 (from 192.16.10.1) address and even changing br0’s IP fro 192.168.0.200/24 to 192.168.0.199/24 does not work. The test never passes and TN is never available on 192.168.0.199 using any browser or even curl from the terminal.

This can’t be a subnet problem because there’s only one (a deliberate choice as I move through this process in baby steps) and there are no firewall rules at work because again both TN and laptop are on the same subnet.

I just do not understand what is going wrong. I have read dozens of posts and articles (including the official TN docs) and the method for achieving this simple change is the same and also the one I followed. I know my IP addressing “scheme” (shambles) is not ideal but this setup is temporary while I find my way around and work towards something better.

Sorry for the long post but I wanted to get all the information written down.

Please help as this is driving me MAD MAD MAD MAD MAD MAD MAD MAD MAD MAD

2

So on pfsense I set up LAN2 as a 10.10.0.1/24 network on a different switch. I moved everything on TN to LAN2 (firewall rules enable all traffic everywhere for now). The TN UI is on 10.10.0.51.

I downloaded the TN config database and searched through all tables using a SQL tool and the only reference to br0 or 192.168.0.200/17 is the bridge interface definition itself. Nowhere else.

I cannot delete the TN 192.1680.200/16 bridge interface br0. I can shrink it to a /17 and change the IP address (say from 192.1680.200 to 192.1680.201) but when I delete br0 and test the changes, lose access to the TN UI until the test period of 60 seconds is over.

As a test I tried moved br0 from enp6s0 to enp7s0 and that worked. Although I cannot see anything using br0 in the TN config DB, when I unplug enp7s0 from the switch, I lose access to the UI.

Also, if this is relevant, the TN UI loses its connection to the TN server very frequently now, where as it did not before I shifted everything over from the 192.168.0.1/16 network to 10.10.0.1/24.

Any ideas?

3

I did not yet read the whole thread, but if your changes are complex and after clicking “Test changes” in TrueNAS you need to adjust other devices like switches etc. … you are aware that you can edit these 60 seconds and use a more reasonable value like e.g. 300?

Also with interface switches it frequently helps to delete the ARP cache on your desktop and/or router/firewall. arp -d -a or similar depending on the OS.

1 Like
4

Thank you for your reply and the ARP information could be really useful. However, would any of that mean that the bridge interface could not be removed in TN?

5

No it does not. Assuming your configuration changes are correct I just wanted to tell you how to increase the timeout as well as how to work around another problem that frequently causes reconnection (from “test” to “save”) to fail even when everything is correct.

Work methodically, set a sufficiently large timeout, clear those ARP caches. If an IP address moves from one interface to another, ARP cacheing always gets in the way.

1 Like
6

So being unable to remove the bridge interface could be an illusion because it appears that access to the UI has been lost, which it may well have, but only because the test timeout is too short for other network config things to be implemented.

Assuming that my configuration changes are correct is a massive leap of faith!

I should mention that I also tried the same bridge interface removal through the console but with the same results - as one would expect I supppose.

As I have been battling this for weeks, I was gearing up for the thermonuclear option: a fresh install of TN with a restore of a modified config DB from which references to the bridge interface have been manually removed.

7

My educated guess so far, yes.

1 Like
8

So I tried this. I logged into the switches ready for the ARP cache clear. I set the TN test timeout to 300 seconds, removed br0, hit test and cleared the ARP cache on three switches, pfsense and on my laptop.

Access to the TN UI was lost, confirmed via two different browsers and curl. Access returned after the 300 second test timeout. Ping is also lost.

9

And you did try to reconnect to the new IP address by manually changing the address in the browser within the 300 seconds time?

1 Like
10

The UI IP address is not being changed as part of this. AFAIT the 192.168.0.200 address is not used anywhere. But yes, I have been caught out by that before when changing UI IP addresses.

All I am trying to do is delete the bridge interface with the 192.168.0.200/17 alias defined on it.

11

Where is the UI IP address bound to?

1 Like
12

I managed to remove br0, but only by the high-risk thermonuclear option.

I downloaded the TN config DB and manually edited that to remove br0 and its references but the upload failed due an authentication token error - usual useless TN error message.

So then I uploaded the modified freenas-v1.db file to /data/ as freenas-v1.db.nobr0 and backed-up the original DB file. Then I swapped the DB files over. Live. And then rebooted the system.

After reboot, the UI was not accessible but in the console I reconfigured one of the interfaces for DHCP and rebooted again and then the system was available again through the UI.

There were quite a few network config things to tidy up, especially with Docker containers but everything’s now working fine. I suspect that it was the Docker subsystem that had a hook into br0 but I saw no way in the UI to change that and by this point TN had got its knickers in such a twist that non-anesthetised surgery was the only option.

If this live DB change had not worked then providing the system booted up, I could have swapped the DB files back again. If the system had not booted then I would have had to figure out a solution for that.

I would not recommend this option to anyone, but I am confident that after having tried everything else for weeks, there was no other choice than this last resort.

13

Hello,

I have a very weird issue and so far I have found no way to fix this. So here it goes …

Setup: TrueNAS is installed on a dedicated machine (barebone install, no VM) and up to date. I have access to the CLI (either directly or via KVM).
Old Network IP Range: 192.168.178.0/24 >> 192.168.178.230
New Network IP Range: 192.168.10.0/24 >> 192.168.10.230
Working Network setting is with two bonded NICs and a static IP.

A couple of months ago I switched the drives of my TrueNAS server and while doing that, installed it fresh. I installed it in the old network IP range and everything worked as it should be. So WebGUI, access to files and so on. After installation I created a bond (LAGG) with the additional NICs I installed, which worked perfectly.

So far so good.

Yesterday I changed the changed the router and split the WLAN subnet from my LAN subnet, TrueNAS is obviously part of the LAN subnet. Prior to the switch I reverted all the static IPs in my network to DHCP, including TrueNAS. That worked, apparently, as I could still access everything back then.

After the switch I got everything working again with the sole exception of the webGUI of TrueNAS in the new IP Range.

I changed the IP via CLI Menu to a static IP, changed Gateway and DNS to the current one and after finishing rebooted. Default route is set to 0.0.0.0/0; 192.168.10.1.
Good news, I can still access my files under the new IP. Bad news, the CLI shows no IP for the webinterface and the WebGUI responds with “ERR_CONNECTION_REFUSED” when I try to access it via browser. And here comes the kicker, when I revert the IP and the default IPv4 gateway back to the old settings (i.e. 192.168.178.230/192.168.178.1) both the WebGUI works and I get the IP adresses shown in the CLI menu.

In short: It’s not a network issue, that works. I suspect that the IP on which the WebGUI responds is somewhere “hardcoded” during installation and I have no idea how to fix this.

I’ve read through the thread above and it seems at least partially cover the issue I have. Maybe someone can point me to information on how to change the IP for the WebUI. Thanks.

14

Make sure System > General Settings > GUI > Web Interface IPv4 Address is set to 0.0.0.0 before doing the IP address change.

(Assuming you are running TN CE 25.04.x)

2 Likes
15

That feature (binding the UI to all network interfaces) is VERY useful when shuffling IPs around. I wish there was an option on the CLI to change the UI binding IP but I didn’t see one.

What I did (and forgot to mention above) was prior to the DB live edit, to set the UI bind address to all NICs and then upon boot-up in the CLI I deleted the first NIC (enp6s0 in my case) then set it to DHCP and rebooted. pfsense then assigned an IP from the DHCP pool and I could access the UI from there and begin to sort things out now that the entire 192.168.xxx.xxx range wasn’t consumed by br0.

16

Thank you, thank you, thank you.

That did the trick.

1 Like