USG FLEX 500 VPN Server EAP-MSChapv2 vs EAP-TLS/PEAP on Radius

custom01

Hello,

i've got some trouble setting up remote user connection with certificate instead of user/password, and i don't find much documentation about this on Zyxel networks.

I've setup VPN gateway & tunnel for remote user connection with radius authentification EAP-MSChapv2 successfully, but when i'm trying to change Windows Built-in VPN configuration to use EAP-TLS / PEAP instead of EAP-MSChapv2, connection is never establishing and timed out.

Is it a Zyxel product limitation ? I see on firewall GUI that only MSChapv2 is supported, but i'm wondering if it's also for AAA Radius auth or only USG built-in auth. I saw few doc on AP and 802.11x using EAP-TLS with NXC, but not for USG FLEX itself. (non H version)

The thing is when i switch to EAP-TLS / PEAP the auth is forwarded to my radius server, and Access-Accept is anwsered, like MSChap, but connection never establishing.

On client log i've got an 1931 error, and USG Log doesn't displaying Auth Fail message.

Picture when i'm using EAP-MSChapv2 vs PEAP/EAP-TLS VPN profiles :

On first &second picture, the radius server sent an Access-Accept packet, but USG don't display [AUTH] Recv:[AUTH] when EAP-TLS / PEAP are used.

Thanks for your replies, and every information that could be usefull.

Best Regards.

Zyxel_Melen

Hi @custom01

Could you please help check your client's log? Based on the EAP-TLS process, this seems to indicate that the negotiation between the client and the Radius server is stuck.

custom01

Hello,

RasClient log event when i'm using MSChapv2 vs EAP-TLS configuration on Windows client :

20221
20222
20223
20224
20291
20225 -> conn Established

20221
20222
20223
20224
20291
20227 -> error 1931

In my original post, the firewall seems to not forwarding EAP Success to client, which waiting to start handshake, the radius server is sending Access-Accept in both case.

Could you please confirm that

[AUTH] Recv: AUTH

is related to firewall receiving Access-Accept packet from Radius, else it will be Auth Fail ?

Zyxel_Melen

Hi @custom01,

This is more likely an issue on the client and Radius server. I have searched for some posts related to "IPSec VPN error 1931" on Microsoft and I think you can take this post a look:

Windows VPN doesn't connect, error 1931. Wireshark shows no connection - Microsoft Community

Nikriaz

@custom01 Did you find a solution? I use older USG (not FLEX) but the problem is precisely the same. "Allowed Auth Method: mschapv2" looks suspicious.

Very common problem in this scenario (EAP-MSCHAP works while EAP-TLS does not) is MTU size. Auth packet is larger because of certificate inside and it's larger than interface MTU. then auth packets get truncated instead of being fragmented. Common solution is to set lower Framed-MTU attribute in NPS to to fix NPS→Client direction and set lower MTU on the Client to fix Client → NPS. Unfortunately, it's not possible to explicitly set MTU in USG AAA Server Radius client settings. Perhaps USG is not capable to redirect larger EAP-TLS packets and that is why mentioned this "Allowed Auth Method: mschapv2".

@Zyxel_Melen Your link is irrelevant.

Nikriaz

I did further research and found a problem. The problem is indeed a packet size. USG device has hardcoded Framed-MTU=1400. This incorrect value because it's translated into packet size of 1514 during fragmentation what is larger than standard Ethernet packet size of 1500 and hence auth flow cannot be reassembled. This causes auth timeout error that we observe.

This is unfixable unless Zyxel has some hidden or undocumented way to change Framed-MTU value. The current, hardcoded 1400 is only suitable to handle small auth EAP packet which is only MSCHAPv2. That's what they mean "Allowed Auth Method: mschapv2" in the GUI! But in fact, there is not much differences between MSCHAPv2 and TLS in terms of proxying auth requests and only fragmentation algorithm an issue. This is certainly a bug (is seemingly lasting for decades) but Zyxel decided just to mention a limitation in the GUI. Unbelievable.