Upgraded IPFire hardware, Omada access points stopped working

[bloater99 (Tim Zakharov)]

I have a work network that is exclusively a “guest network”. There are almost no wired devices. Just an Omada controller and 6 access points. I had an opportunity to upgrade the IPFire hardware. I installed IPFire on the new hardware and set up the ISP stuff in the Setup program identically to how it’s set up on the old hardware. Kept the LAN config the same (192.168.11.x). Backed up the old hardware IPFire stuff. Shut it down. Installed new hardware. Booted up, connected via CAT5e, restored backup from old hardware. Rebooted. Connected via ethernet, internet works and I am able to access IPFire GUI and the Omada Controller. But all of the access points show “Disconnected” in the Omada controller. I could not get them to connect. I cannot ping any access point. After about an hour of troubleshooting, I shut everything down, plugged the old hardware firewall back in, rebooted, and the access points showed up like normal. I can ping them and devices connect to them normally. I decided to go home with my tail between my legs to try another day. Any ideas why the access points showed disconnected with the new IPFire hardware?

[pscar13]

Which version of IPFire have you installed?
If it is CU202 and you had URLFilter installed, check whether the backup restoration completed successfully.
The procedure is here.

IPFire 202 Test: Restoring a 201 backup after upgrading to 202

Your problem is not related to the URLFilter list. Load your backup file to /tmp. And run: [root@ipfire ~]# cd /var/ipfire/backup/bin [root@ipfire bin]# ./backup.pl restore /tmp/<your_backup>.ipf And check if there is an exit message before the end of script which must be. Starting OpenVPN Authenticator…

Edit : Or wait for the final CU203 which contains the fix.

[bloater99 (Tim Zakharov)]

It was CU202, but neither web proxy nor URL filter are enabled. I’m think it might have something to do with the ethernet ports, MAC addresses, etc. Both old and new hardware have 4 ethernet ports and I had 3 of them bridged for the LAN. Could it be when I restored the backup to new hardware, it used the MAC addresses from the old hardware, creating a MAC address mismatch?

[pscar13]

No, setup writes NICs config in /var/ipfire/ethernet/settings
This data is not in the backup
(unless you forced them in /var/ipfire/backup/include.user)

Edit:

@bloater99

restored backup from old hardware. Rebooted. Connected via ethernet, internet works and I am able to access IPFire GUI and the Omada Controller

And in that case, you wouldn’t have any working connection.

[hvacguy (Shaun HVAC)]

@bloater99

it used the MAC addresses from the old hardware, creating a MAC address mismatch?

Sounds like a possibility.

Did rebooting the AP’s help? or check AP config.

[bloater99 (Tim Zakharov)]

I can’t reboot the APs because they are disconnected. Most of them are out of reach too, mounted where you need a ladder or lift to access them. I tried power cycling the hardware controller and there was one AP I could reach easily. I tried both power cycling it and doing a physical reset on it (paperclip in hole). Neither had any effect. But when I plugged the old IPFire device in, they all came up immediately. Weird.

[pscar13]

I am not familiar with how Omada access points work, but they might be retaining a link to the “green” network’s MAC address.
If your new hardware also uses Bridge mode, you could try using the same randomized MAC address from the old hardware.
You need to find the value of the GREEN_MACADDR parameter in /var/ipfire/ethernet/settings on the old system and copy it to the new one.

[tphz (iptom)]

1.What is your IPFire configuration?
Red, Green
Red, Green, Blue
Red, Green, Blue, Orange

2.What are the models of the APs and the Omada controller?

3.How do the Omada controller and the APs communicate with IPFire?
4.Is there a switch in this configuration?
5.What is the model of that switch?
6.Did you restart the switch after switching to the new IPFire?
7.Are you using VLANs?

8.Have you compared the results on the old and new IPFire
“WUI->Status->Network (others)->ARP Table Entries”
or the console command ip n s

9.Have you checked the DHCP server logs?

[bloater99 (Tim Zakharov)]

Those are all good questions. They will have to wait for another weekend I am available for testing. The network cannot be taken down during the week – too many people and devices use it.

[bloater99 (Tim Zakharov)]

I will answer those questions I can:

1. Red, Green
2. APs are EAP610 qty 6 and EAP660 qty 1. The controller is OC200.
3. The controller and APs are peers on the LAN. They are all using static IPs below the DHCP range.
4. There is a switch plugged into one of the GREEN ports of IPFire, extending the number of available ethernet ports in the vicinity of the firewall hardware. There are other switches throughout the building providing similar extension. All are gigabit, dumb switches.
5. Various, but mostly Netgear and TP-Link. See above.
6. I restarted the switch plugged directly into IPFire, but I did not go around restarting all the other switches throughout the network.
7. Not using VLANs.
8. No and the new IPFire hardware is disconnected until my next afterhours opportunity.
9. No, not on the new IPFire hardware. See #8.