I had a situation where I needed to restore a backed up UTM 9 configuration to a virtual machine for reference. Unfortunately it turned out that the virtual hardware was enummerated differently than the hardware the config was made on (different naming of the network interfaces). Immediatelly after restoring the config backup the Webadmin-Interface did not respond anymore and I had to figure out how to once more gain access to the WebAdmin GUI. Turns out WebAdmin by default allways binds to eth0 and whatever IP address is set at that interface. Good luck if your IP config and firewall rules don't match at all anymore. I tried to change the interface names by editing the "udev" rules, but this did noting at all for me. The names of the interfaces were changed, but the binding was still not correct.
Here are the steps I did to regain full access for your reference. It should be exactly the same for a scenario with "real" hardware, but I only tested this for my virtual machine running in HyperV.
-Install new UTM 9 installation in Hyper-V
-Do the basic setup and connect with WebAdmin
-Restore the old configuration
-Notice that something is wrong and curse loud and hard
-Log in to the machine by console. Above the login promt UTM 9 displays the IP Adress and Port of the WebAdmin interface, which is of course unusable. Note that information. In my case it took the IP-Adress of the former WAN interface. So WebAdmin was now incorrectly bound to 10.209.0.2
-Type "ifconfig eth0". You will see the IP adress and MAC address of eth0, which WebAdmin binds to by default. Note the MAC address.
-Find out what Interface eth0 physically is by looking at the MAC adresses (in my case I used Hyper-V Manager)
-Configure your Admin-Workstation to the same IP-Range that WebAdmin uses and connect it to the WebAdmin NIC.
Example: WebAdmin bound to the address 10.209.0.2/16, so I gave my workstation 10.209.0.66/16
-Try to access WebAdmin from your admin workstation by connecting to https://10.209.0.2:4444
-Curse again, much louder, because a firewall rule blocks your access. After all in your old config you probably allowed access to WebAdmin only from the management network!
-Create a new firewall rule by typing the following at the console:
iptables -I INPUT -s 10.209.0.66 -p tcp --dport 4444 -j ACCEPT
(note that -I is an uppercase I as in Input)
-Try to access WebAdmin again from your workstation. This time it should work and give you access again.
This was not enough for me, however. WebAdmin was still bound to the WAN IP (!) and I once again wanted to manage the firewall from inside my management network. To finally bind WebAdmin back to the correct virtual interface I did the following, additional steps:
-Add another virtual NIC hardware to your UTM and reboot
-Connect to WebAdmin again and go to Management->WebAdmin and set "Allowed Networks" to "Any" (just in case, you can change that later)
-Go to "Interfaces"
-Double check that the interface WebAdmin SHOULD be bound to has the correct IP address set. In my case the correct address was 10.222.0.1/16 (which belongs to my management network)
-Now comes the tricky part: select the wrong WebAdmin interface (the one currently bound to eht0) and bind it to the newly added virtual NIC (ethXY). You will loose connection to WebAdmin immediatelly.
Login to the console again. You need to edit the Apache config file to temporarily bind WebAdmin to the correct IP by force. The directory the config files normally would be in will be empty, because UTM uses a chroot jail of some sort. Probably for security reasons.
-Type in the following commands
cd /var/sec/chroot-httpd/etc/httpd/vhost
vim httpd-webadmin.conf
-You are now inside the texteditor "VIM". Please read below how to use it (trust me).
-Edit the "Listen 4444" line to read the following:
Listen 10.222.0.1:4444
-Leave VIM and save
-Restart WebAdmin with the following command
/etc/init.d/httpd restart
-Change your admin workstation back to the old IP config and connect it to the NIC that is bound to 10.222.0.1
-Connect to WebAdmin again, but this time finally using the correct IP address you were used to use
https://10.222.0.1:4444
-Go to "Interfaces" and change the binding of your management interface to eth0
-Finally connect your eth0 NIC back to the management network
-Go back to the console, type once again
vim httpd-webadmin.conf
and change the listen line back to
Listen 4444
(as it is not recommended by Sophos that you change any configuration) :-p
-Reboot the UTM
-You are done. As your management interface is now bound to eth0 by using WebAdmin, after the reboot you will have no trouble accessing WebAdmin by the correct IP address.
VIM for Linux noobs:
VIM is a real *** to use if you don't know what is expected from you as user. Use this short guide as help.
-Changing text: you need to press the "Insert" button on your keyboard to enter insert mode. Only in this mode you can change any of the contents of your files. If you just type happily, VIM will mistake your input for commands. And god forbid I know more than the absolute mininum of the obscure syntax as to be barely able to change a few lines of text.
-After you are done changing the contents of the file, press the Escape key. You will leave insert mode this way.
-Type :x (that is type a colon, followed by an 'x') and press return. This will save the file and exit.
Conclusion: you can get around the naming trouble by first somehow gaining access to WebAdmin again and then in a second step switch the interfaces using the GUI. Now I ask myself WHY has this to be so bloody hard for the average non Linux literate admin to pull off? Why in gods name is there no simple to use, braindead easy console command to
a) unblock WebAdmin access on all interfaces
b) bind WebAdmin to any IP you want
Take PFSense for example. Directly after you start the system up you are greeted with a bare bones menu in which you can assign the management interface and IP addresses. This is the absolute minimun I would expect from Astaro/Sophos UTM as well if they don't recommend going into the comandline at all.
Not having such a simple menu makes it unnecessarily hard to rebuild an old config on new hardware. Mind you, at the best of all times when you absolutely can't afford to poke around, because your old hardware just died and all you want to do is really just to set up a replacement box QUICKLY. Why am I using Astaro in the first place? Exactly: because I dont WANT to poke around inside the guts of the system. I could use some other kind of Linux for free if that was my kind of fun. Granted: if I knew what to do in the first place I would not have had all the trouble.
Hope this info helps some of you in a similar situation that I was in.
This thread was automatically locked due to age.
