It is asking for a default route, and you almost certainly do not have one. The phrase "default interface" means "the interface the default route points out of", and if there is no default route there is no answer to give.
On a console, print the routing table. If there is no line for the default destination, that is the whole problem and everything else follows from it.
Why creating a bridge does this, specifically. This is the single most common way to end up here and it catches everyone once.
Before: your physical interface holds the address, the netmask and the gateway, and the gateway installs a default route.
When you build a bridge for virtual machines, the physical interface must become a plain member of the bridge with no address of its own, and the bridge takes over the address, the netmask and the gateway. What tends to happen instead is that the bridge gets created and given an address, the physical interface keeps its old address too, and the gateway ends up attached to neither properly — or to an interface that is now enslaved and cannot route.
Result: two interfaces with addresses, no default route, and a system that cannot answer the question "which interface do I send outbound traffic through".
Fixing it from the console. Most of these systems have a console menu with a network configuration option, and this is what it is for. Reconfigure so that:
- the physical interface is a bridge member with no address
- the bridge holds the static address and netmask
- the default gateway is set once, at the system level, and points at your router
Apply, then print the routing table again and confirm a default route exists pointing out of the bridge.
Why the web UI is gone and why that is a symptom rather than a second problem. If the address moved to an interface that is not correctly up, or nothing has a route back to your subnet, the UI is listening but unreachable. It will come back with the route. Do not go debugging the web service.
The one trap to avoid. These systems usually apply network changes with a test-and-revert timer — the new config is applied, and if you do not confirm it within a couple of minutes it rolls back, precisely so that a bad change over the network does not lock you out. On a console that safety net feels like the machine undoing your fix for no reason. Confirm the change when prompted, and prefer doing all of this from the physical console rather than over the network you are currently reconfiguring.