USG FLEX 200H (uOS): Connectivity Check on internal interface reports DEAD although target responds

baba · October 19

Device: USG FLEX 200H
Firmware: uOS V1.39(ABWV.0)ITS-26WK37-m12845

Note: this is an ITS build (ITS-26WK37-m12845). Please confirm whether the issue is known for this build and whether a newer regular or ITS build contains a fix.

Configuration

Interface ge5 (port P7), internal interface, static 10.15.10.1/24, no gateway, dedicated zone
A second Zyxel firewall at 10.15.10.2 is directly connected (Layer 2, via a point-to-point bridge link)
Connectivity Check on ge5:
Method ICMP, Period 10 s, Timeout 3 s, Attempt 3, Source 10.15.10.1 (also tested with Source empty), Destination 10.15.10.2, Success Criteria "Any"

Problem
Shortly after enabling the check, the log reports "The link status of ge5 interface is DEAD." even though 10.15.10.2 is reachable and replies to ICMP. The interface then switches sporadically between DEAD and active. As a result, routes via ge5 are deactivated and traffic is incorrectly redirected.

Analysis
Packet capture on ge5 (filter ICMP, host 10.15.10.2) while the check was enabled:

22:46:07 Echo Request 10.15.10.1 → 10.15.10.2, reply after ~2 ms
22:46:17, 22:46:27, 22:46:37: no Echo Request visible on ge5
22:46:39 log: "ge5 … DEAD"
22:46:57 Echo Request on ge5, reply after ~2 ms, log: "ge5 … active"

With a configured period of 10 s, probe pings only appear on ge5 roughly every 50 s. The ICMP sequence numbers jump considerably (e.g. 26220, then 6097). The probes that are sent are answered immediately. The remaining probes apparently do not leave the device via ge5.

Also tested in parallel:

ICMP from a client behind the FLEX to 10.15.10.2 via ge5: 60/60 replies, ~2 ms
On the peer device (USG FLEX 200, ZLD) there are no drops in Security Policy. ICMP from 10.15.10.1 is explicitly allowed there.
The Connectivity Check on a WAN interface (VLAN, DHCP) of the same FLEX 200H works correctly.

Expected behavior
The check sends an ICMP Echo Request to 10.15.10.2 via ge5 every 10 s. It marks the interface DEAD only after three consecutive requests remain unanswered.

Question
Is this a known issue with the Connectivity Check on internal / non-WAN interfaces in uOS? Is there a fix, workaround or beta firmware available?

A packet capture and screenshots of the log and the Connectivity Check settings are available on request

baba · October 20

fixed in 1.40

baba · October 19

Additional finding: same issue with the Policy Route Health Check

To rule out an interface-specific problem, I disabled the Connectivity Check on ge5 and configured the Health Check on the policy route instead.

Policy route configuration

Name: Parents
Incoming: any (Excluding ZyWALL), Source: any, Destination: remote subnet (10.20.0.0/16)
Next Hop: Type gateway, 10.15.10.2 (via ge5)
A static route for the same subnet via a route-based VPN (VTI) acts as backup.

Health Check (Advanced Settings)

Disable policy route automatically while interface link down: enabled
Enable Connectivity Check: enabled
Method ICMP, Period 10 s, Timeout 3 s, Attempt 3
Source 10.15.10.1, Destination 10.15.10.2, Success Criteria "Any"

Observed behavior (2026-10-19)
The policy route flaps continuously between active and disabled every ~20–40 s, although 10.15.10.2 answers every ping sent from a client during the same time. Log / Events, category Connectivity Check, reports this as "ge5 interface" (not as the policy route):

┌──────────┬─────────────────────────────────────────────┐
│ Time │ Message │
├──────────┼─────────────────────────────────────────────┤
│ 22:58:19 │ The link status of ge5 interface is DEAD. │
├──────────┼─────────────────────────────────────────────┤
│ 22:58:59 │ The link status of ge5 interface is active. │
├──────────┼─────────────────────────────────────────────┤
│ 22:59:21 │ … DEAD. │
├──────────┼─────────────────────────────────────────────┤
│ 22:59:49 │ … active. │
├──────────┼─────────────────────────────────────────────┤
│ 23:00:11 │ … DEAD. │
├──────────┼─────────────────────────────────────────────┤
│ 23:00:39 │ … active. │
├──────────┼─────────────────────────────────────────────┤
│ 23:01:01 │ … DEAD. │
├──────────┼─────────────────────────────────────────────┤
│ 23:01:29 │ … active. │
├──────────┼─────────────────────────────────────────────┤
│ 23:01:52 │ … DEAD. │
└──────────┴─────────────────────────────────────────────┘

Measured from a client during the same time: RTT to the remote subnet alternated between ~2 ms (bridge link, policy route active) and ~6 ms (VTI backup, policy route disabled), in sync with the log entries. No packet loss to 10.15.10.2 at any time.

After the last "DEAD" entry at 23:01:52, no further "active" entry was logged for more than 5 minutes while the Health Check was still enabled. During this time the policy route stayed disabled and all traffic remained on the VPN backup (~6 ms RTT), although 10.15.10.2 kept answering pings from a client. Disabling the Health Check immediately re-activated the policy route, and traffic returned to the bridge link (~2 ms RTT).

Conclusion
Both the interface Connectivity Check and the policy route Health Check show the same false DEAD detection. They appear to share the same probing mechanism. The issue seems to affect checks towards a directly connected peer on an internal (non-WAN) interface.