Anyone running USG FLEX H-series in a complex multi-site environment?

Aften_Bil_IT

Hi all,

We've been running Zyxel USG firewalls for about 10 years now — first the USG 20/60 series, then the USG FLEX 200/700 — and have been very happy with them throughout. Recently we upgraded part of our fleet to the new USG FLEX H-series (200H and 500H, currently on firmware 1.38(ABWV.0), Nebula-managed), and honestly, it's been a rough ride. I'm hoping to hear from others running the H-series in a non-trivial environment to find out whether we're the unlucky ones or whether these are known issues.

For context, our setup spans 10 sites with multiple networks per site — a mix of our own internal subnets and IPsec VPN connections to various supplier networks. There's site-to-site VPN between all of our locations and several external tunnels to third parties on top of that. Nothing exotic in terms of features — policy routes, dual-WAN failover, DNS forwarding, the usual — but the topology is large enough that small bugs become real operational problems quickly.

Here are the issues we've hit on the H-series specifically. None of these were a problem on our older FLEX units running the same kind of configuration:

1. Nebula Portal and local USG GUI getting out of sync on policy routesIn the Nebula Portal, you can add a routing rule with "Disable policy route automatically while interface link down" enabled with any "Next Hop" type except "Auto." In practice, this only actually syncs down to the USG when "Interface" is the selected next hop. With any other next-hop type (Gateway IP, VPN tunnel, etc.), the rule appears in Nebula but never makes it to the local device, so the two configs silently drift apart.

2. GUI shows one thing, routing table shows anotherWhen adding policy routes and toggling SNAT between "None" and "Outgoing interface," the change appears to apply in the GUI, but under Maintenance → Packet Flow Explore → Routing Status → Policy Route the rule stays stuck on the previous setting. The only way to know if a change actually took effect is to check the routing table after every single modification. Configuration changes you can't trust is not a great place to be — especially across 10 sites.

3. Ping loss from the firewall itselfPings sourced from the firewall (not transiting through it) drop intermittently. This makes "Connectivity Check" on dynamic policy routes effectively unusable — the check fails enough pings to disable the rule even when the underlying connection is perfectly fine. The data path works, but the firewall's own ICMP just drops packets for no obvious reason.

4. Kernel routes not rebuilding after WAN2 flap on dual-WAN VPNThis one is the most concerning. On sites where Nebula VPN is configured to use both WAN connections (WAN1 primary, WAN2 secondary), if the WAN2 link goes down and comes back up, the kernel routing table sometimes doesn't fully rebuild. We end up in a state where routes for some remote sites have metric 2, while the default route (0.0.0.0/0) has metric 0 or 1. The result: traffic that should go through the VPN tunnel instead egresses straight to the internet. The only workaround we've found is to reboot both USGs on the affected sites — which obviously isn't acceptable in a production environment of this size.

These are just some of the problems we've encountered. There are other smaller issues I could go on about, but I need to keep this post to a reasonable length.

Questions for the community:

• Is anyone else running H-series units in a multi-site VPN environment with policy routes and seeing similar behavior?
• Are any of these known issues with current firmware, or is there a release that addresses them?
• For those who have been on the H-series for a while — are these the kinds of issues that actually get fixed in firmware updates, or have you learned to just live with them? Because what I'm seeing so far doesn't feel like polish-and-bugfix territory; it feels like fundamental sync and routing logic that should have been solid before this platform shipped.

We have an open ticket with Zyxel support on a separate matter, but I wanted to get a wider read from people actually using these in the field. Genuinely hoping someone tells me we've configured something wrong, because right now we're not feeling great about the platform — and to be straight about it, if these issues don't get addressed we're going to be forced to look at switching to another brand for our network infrastructure. After 10 years on Zyxel that's not something we want to do, but we can't keep running production sites on firewalls we can't trust.

Thanks in advance for any input.

Zyxel_Tina

Hi @Aften_Bil_IT,

Thank you for taking the time to write such a detailed post. We understand your frustration, and we want to assure you that your concerns are being taken seriously. That said, we'd like to offer a bit of context: the USG FLEX H-series runs on a fundamentally different operating system compared to the classic USG FLEX series. While this new platform brings significant improvements in performance and architecture, we acknowledge that the transition can come with a learning curve. We appreciate your patience as we work through these together.

To better assist you and efficiently investigate each of the four issues you've described, could you help us with the following?

1. Additional details for each issue — any error messages or specific configuration snippets related to the policy route sync issue, routing table discrepancies, etc.
2. Screenshots — captures from both the Nebula Portal and the local USG GUI where the inconsistencies are visible would be especially helpful.
3. Timestamps — approximately when issues first occurred (e.g., after a specific firmware update, after a configuration change, or spontaneously).

In addition, if possible, we'd kindly ask that you enable Zyxel Support Access on the affected devices. This would allow our team to directly review the device status and configuration, which would significantly speed up the investigation.

Thank you for your understanding and cooperation!