Incorrect RADIUS client behavior on USG devices

Options
Nikriaz
Nikriaz Posts: 7  Freshman Member
First Comment Friend Collector

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:

Best Answers

  • Zyxel_Melen
    Zyxel_Melen Posts: 3,519  Zyxel Employee
    Zyxel Certified Network Engineer Level 1 - Switch Zyxel Certified Network Administrator - Switch Zyxel Certified Network Administrator - Nebula Zyxel Certified Sales Associate
    Answer ✓

    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.

    Zyxel Melen


  • Nikriaz
    Nikriaz Posts: 7  Freshman Member
    First Comment Friend Collector
    Answer ✓

    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.

All Replies

  • Zyxel_Melen
    Zyxel_Melen Posts: 3,519  Zyxel Employee
    Zyxel Certified Network Engineer Level 1 - Switch Zyxel Certified Network Administrator - Switch Zyxel Certified Network Administrator - Nebula Zyxel Certified Sales Associate

    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


  • Zyxel_Melen
    Zyxel_Melen Posts: 3,519  Zyxel Employee
    Zyxel Certified Network Engineer Level 1 - Switch Zyxel Certified Network Administrator - Switch Zyxel Certified Network Administrator - Nebula Zyxel Certified Sales Associate
    Answer ✓

    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.

    Zyxel Melen


  • Nikriaz
    Nikriaz Posts: 7  Freshman Member
    First Comment Friend Collector
    Answer ✓

    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.