[uOS 1.39] Problems with HTTPS sessions

Dylan96

After updating to 1.39, we noticed, particularly on the 200H models but also on some 100H models, a significant increase in "log deny wan-to-device" entries. Specifically, I’ve noticed that the destination IP is my public IP, and the source always appears to be legitimate websites.

Since the destination port is always an ephemeral port, I suspect this is related to an issue with HTTPS sessions.

Has anyone else encountered this behavior?

Zyxel_Judy

Hi @Dylan96 , @Mk88_it ,

Thank you for your time and for joining the remote sessions, which allowed us to investigate the issue. Here's a summary of the case:

The firewall's fragmentation mechanism was not functioning correctly, causing some fragmented packets to be dropped by the firewall after being split. This specifically affected your environment, where the MTU needed to be set to a value other than the default 1500.

A solution was provided to you, and you confirmed the issue was resolved. This fix will be included in the next firmware release, 1.40, scheduled for Q4 2026.

PeterUK

Yes the issue is and I see it too

I have narrowed the issue down to it being UDP show wrong blocked logs

hmm this is odd…let me think about what I'm seeing in packet capture

so on my FLEX 200H I have a test WAN as 192.168.177.3 Ge3 and LAN Ge4 192.168.255.243/26

this is what the client sends

and this the the WAN FLEX send

but why is this traffic being sent out in red?

Mk88_it

@PeterUK maybe do you mean TCP?

PeterUK

nope I think this is just UDP if you firewall on client for doing TCP only and allow DNS I don't see the issue I'm not sure if it just QUIC or might happen to other UDP traffic.

Mk88_it

Mmh, but in our cases it seems the TCP handshake completes successfully and the TLS Client Hello is transmitted. Subsequently, the client starts retransmitting packets while the server generates Duplicate ACKs and repeated FIN/ACK retransmissions. This suggests that packets belonging to an already established session are being lost or not correctly associated with the existing state entry after NAT translation. In that cases we can see in the packet capture a lot of TCP retrasmission and in the firewall logs like this (dest ip is WAN1 and WAN2)

PeterUK

Think your seeing something different Mk88_it to Dylan96

Your looks like background Radiation due to WAN IP being on the front line

Unless the TCP happens because of that? just checked TCP seems fine

Mk88_it

FYI: Zyxel has confirmed that there are issues with 1.39 firmware regarding routing / MTU / VPN in certain scenarios.

Zyxel_Judy

Hi @Dylan96 , @Mk88_it ,

Thank you for your time and for joining the remote sessions, which allowed us to investigate the issue. Here's a summary of the case:

The firewall's fragmentation mechanism was not functioning correctly, causing some fragmented packets to be dropped by the firewall after being split. This specifically affected your environment, where the MTU needed to be set to a value other than the default 1500.

A solution was provided to you, and you confirmed the issue was resolved. This fix will be included in the next firmware release, 1.40, scheduled for Q4 2026.