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.