AVM offers a friendly user interface with Fritz!OS for their Fritz!Box’es to unleash a nice range of features. Many things are possible, though some things take quite a few clicks.
One of the things that take many clicks, is arranging port fortwarding for hosts on the LAN.
The easiest way, after a fashion, is to make a backup of the configuration, make changes and import the file again. The difficulty here is that the file is checksummed, and Fritz refuses to read the configuration.
While the ages, solutions have been written in various languages. I use a python script, fritzchecksum, written by Mementum/DRe.
It is an pip-installable module, pip install fritzchecksum, takes a Fritz-file as input and returns the old and new checksum for easy search and replace. The program supports automatic editing of the file as well, I have always replaced by hand.
AVM does not write in large letters on their website that the Fritz!Boxes can handle public IP subnets. The feature is mentioned in the online help; enabling it in the first place happens via Home Network / item Network / tab Network Settings / header IP Adresses / button IPv4 Adresses / header Public IPv4 Subnet, at the bottom of the page.
And then? Then I got stuck. For evenings in a row. After some tries I got lucky at the XS4all helpline and spoke with someone knowledgeable on the subject. Managed to make a device reachable from the outside world on the public IPv4 on a single port. All happy, hung up the phone and tried another device and another port forwarding. Access denied, ‘An error occurred. Error description: A device with this name has already been configured.’
The awful thing is: not any port forwarding can be added or altered anymore. After contacting the AVM helpdesk, we found some hints of causes:
Renaming
Multiple NIC’s on one system
Renaming: that has to do with renaming the device, and later deleting the device under its new name. Some residual config stays behind under the old name. Since the new devices all came up as ‘Yunohost’ + a number initially, I would rename them to their given host name. Later the next device would come online, initially as Yunohost again. The left over config from the previous round now collides with this Yunohost.
Multiple NIC’s: AVM warned that one machine, connected to the Fritzbox via more than one cable, is not supported and will cause difficult to diagnose problems.
Even after learning some of the possible causes, the situation still has returned. I have a backup of a working configuration now, in which most machines got a basic profile that has most forwardings in place. If something runs amok, I can put that configuration back.
Assigning a public IP
To avoid the situation altogether, I don’t rename temporary devices anymore. The best cure is to be able to assign a device its public IP before connecting it to the FB for the first time. In a headless device that is not always practical.
Specifically for a temporary Yunohost with Armbian on Orange Pi Zero I now do things along these convoluted lines:
Just connect in any way to the FB and request an IP via DHCP
Leave the name as-is
Configure anything needed via SSH on the local IP
Make sure an ethernet cable as well as a serial connection are available
Use nmtui to configure the ethernet port for a public IP
Do not yet activate the new configuration
Disconnect the ethernet cable
Use the serial connection to reboot
Wait for the FB to move the device from active connections to idle connections in the network connections section of the home network.
Delete the stale configuration
That is only possible when the FB thinks the device is inactive
It has only effect when the name of the device has not been changed from what it was when it was first encountered by the FB
Sometimes it helps to reboot the FB, but it is not necessary and also does not always speed things up
Once deleted, reconnect the ethernet cable
After a while (network manager will find a connected cable, and activate the configuration) the host will come up in the FB under its new (public) IPv4.
Some chance it’s difficult to spot, because it got a new generic name, based on the IP address.
Now the device should be reachable on its public IPv4. Configuration of port forwarding should not pose difficulties.
Troubleshooting
Direct troubleshooting is not really an option via the web interface. AVM asked me to generate support data. After reviewing the detailed logs, I could guess the cause of the problem before sending it to the patient people at AVM.
The support data can be generated by clicking the contents at the left hand bottom, and then FRITZ!Box Support. There are two variants, ‘Generate Support Data’ and ‘Generate Advanced Support Data’. The ‘basic’ version had all that was necessary to point at the cause problem.
The problem, once introduced, is very difficult to resolve from the available functionality in the web interface. There used to be a telnet option, but that was on an older model Fritzbox, with a much earlier version of the OS, at a time when we still had a handset in the house that we could connect to the phone port of the Fritzbox. A quick lookup learns that it needed #96*7* typed on the connected phone to enable telnet, but lacking such a device I have no known option to enable it anymore. Options might be still there with alternative firmwares, but at the moment things run OK.
The Yunohosts running in the local network were initially unreachable due to different causes, the cause depending on whether the request was made from the local net or from the public internet.
The local case was easily worked around using the hosts file, by adding a line to /etc/hosts of each device on the local net (and suppressing ensuing headaches):
Once the headaches of trying to edit host files on Android devices promised heavier than those I prospected finding the cause in the local network, I set out finding that cause. It turned out to be DNS rebind protection in the modem/router, an up-to-date (07.01, as of writing) Fritz!Box.
An entry on Marphys blog pointed me to the setting in question:
The list was empty, of course, and after adding online.osba.nl the entries in the hosts files were not needed anymore.
