Well, there’s good and bad news… I used the cloned copy of ZS I made, and using the brctl commands… I did get the 2 nics deleted from the bridge, and then got the bridge to successfully delete itself too – but – both the nics still showed up as members of the bridge in the web interface. After that there’s nothing I could do with either nic to modify them or reassign them to anything else with either CLI or web. I’d get an error saying they were members of the bridge (which didn’t exist), and the command would exit.
I cloned another one and went back to the web interface to take another run at it that way, and this time I did get the 2 nics removed from the bridge – along with them not being members any more – and also got the bridge removed entirely without error. I went back to all the areas that needed to be ‘un-bridged’, and set things back to their ‘routed’ settings… then rebooted.
Even though it looked like the setup was in the same state as it was before the bridge was created, there was no internet connection at all. None of the logs showed any errors, and everything showed as being ‘UP’ and running – but there wasn’t any traffic on eth00 either. I couldn’t ping the gateway, or ping back to ZS from the rest of the network that’s on the same 192.169.1.x (etho1) segment. The 192.168.0.x (eth00) segment behind ZS was pingable and working fine. DNS was resolving internally for the eth00 side, HAVP displayed ‘No connection’ screens, Captive portal logins worked, etc.
I tried going through and disabling everything that might affect the connection in case there was any other issues somewhere else, but no luck.
So I think my only choice might be to start with a fresh profile and rebuild from scratch – making sure to not create a bridge this time… unless someone sees something I’m missing, or has a quicker fix.