Incorrect RADIUS client behavior on USG devices

Nikriaz

We’ve been running several USG devices (110 and 210) without issues for years but recently discovered few issues that seem are persisting on newest FLEX H devices as well.

RADIUS Framed-MTU Issue
The Zyxel RADIUS client (AAA Server) hardcodes Framed-MTU=1400, which is incorrect and not configurable (Microsoft recommendation: 1344, Cisco value: 1002)
This results in attempt to send 1514-byte RADIUS packet, which cannot be properly fragmented and fails reassembly, breaking authentication.
EAP-TLS fails entirely, while MSCHAPv2 works (since it doesn’t rely on large payloads).

RADIUS Accounting Fails Completely
Despite having port 1813 correctly configured, there is zero RADIUS accounting traffic from the USG.
No packets are sent on any interface, making accounting non-functional.

The reason why EAP-TLS is very important is the native Windows VPN client (all versions). By design, it is impossible to arbitrary set a Peer Id there in case of EAP-MSCHAP authentication. In this case it's always set as caller-IP what makes impossible to explicitly set a client Peer Id on USG, so it should be set to "any". This significantly broader attack surface and makes RADIUS server vulnerable to brute force/DDoS. The only option to mitigate this vulnerability is to use EAP-TLS so Peer Id in Windows client becomes dependent from certificate CN, so makes it possible to setup static Peer Id on USG.

The issue was already reported:

https://community.zyxel.com/en/discussion/27464/usg-flex-500-vpn-server-eap-mschapv2-vs-eap-tls-peap-on-radius

Zyxel_Melen

Update:

From other post which has similar issue, we have tested and know the framed-MTU=1400 doesn't effect the authentication. The possible root cause is on ISP side if your authentication server is in other site over VPN.

https://community.zyxel.com/en/discussion/comment/77400#Comment_77400

Nikriaz

No, there is nothing with ISP. Most likely the root cause is the RADIUS-related code was pulled from some open source without adaptation and with sample defaults. I replaced USG by FGT and it works right away. All auth types works. Logs are rich and clean so RADIUS communication is transparent, unlike in USG. All settings are adjustable, also unlike in USG.

Zyxel_Melen

Hi @Nikriaz,

Could you share:

1. In what EAP-TLS scenarios do you currently use RADIUS authentication?
2. Could you help capture the authentication packets so we can investigate this issue?

Zyxel_Melen

Update:

From other post which has similar issue, we have tested and know the framed-MTU=1400 doesn't effect the authentication. The possible root cause is on ISP side if your authentication server is in other site over VPN.

https://community.zyxel.com/en/discussion/comment/77400#Comment_77400

Nikriaz

No, there is nothing with ISP. Most likely the root cause is the RADIUS-related code was pulled from some open source without adaptation and with sample defaults. I replaced USG by FGT and it works right away. All auth types works. Logs are rich and clean so RADIUS communication is transparent, unlike in USG. All settings are adjustable, also unlike in USG.