OpenConnect-GUI: A record packet with illegal version was received.

[Niels Peen]

Hi guys,

Any idea what would cause the “illegal version” error? I’m assuming it’s
referring to the SSL/TLS version. This server (ocserv) works fine for other
users of OpenConnect-GUI and also for this particular user if he uses
OpenConnect on Android instead of Windows. (Also OpenVPN on the
same computer works without issues.)

2014-11-02 17:54 POST https://XXXXX/
2014-11-02 17:54 Attempting to connect to server 123.123.123.123:443
2014-11-02 17:54 SSL negotiation with XXXXX
2014-11-02 17:54 SSL connection failure: A record packet with illegal version was received.
2014-11-02 17:54 Failed to open HTTPS connection to XXXXXX
2014-11-02 17:54 Authentication error; cannot obtain cookie
2014-11-02 17:54 Disconnected

Thanks,
Niels

[Nikos Mavrogiannopoulos]

Post by Niels Peen
Hi guys,
Any idea what would cause the “illegal version” error? I’m assuming it’s
referring to the SSL/TLS version. This server (ocserv) works fine for other
users of OpenConnect-GUI and also for this particular user if he uses
OpenConnect on Android instead of Windows. (Also OpenVPN on the
same computer works without issues.)
2014-11-02 17:54 POST https://XXXXX/
2014-11-02 17:54 Attempting to connect to server 123.123.123.123:443
2014-11-02 17:54 SSL negotiation with XXXXX
2014-11-02 17:54 SSL connection failure: A record packet with illegal version was received.

The cases that this can happen is when there are no commonly supported
protocols, or the peer doesn't correctly set the TLS record versions.
That's almost impossible to occur between two gnutls peers. Could that
again be related to a firewall that modifies the packets sent/received?

regards,
Nikos

[Niels Peen]

Post by Nikos Mavrogiannopoulos

Post by Niels Peen
2014-11-02 17:54 POST https://XXXXX/
2014-11-02 17:54 Attempting to connect to server 123.123.123.123:443
2014-11-02 17:54 SSL negotiation with XXXXX
2014-11-02 17:54 SSL connection failure: A record packet with illegal version was received.

The cases that this can happen is when there are no commonly supported
protocols, or the peer doesn't correctly set the TLS record versions.
That's almost impossible to occur between two gnutls peers. Could that
again be related to a firewall that modifies the packets sent/received?

Possible. The user turned off their firewall (ESET), but I’m not convinced
that turning it off completely restores normal behaviour.

Niels

[Nikos Mavrogiannopoulos]

Post by Nikos Mavrogiannopoulos
The cases that this can happen is when there are no commonly supported
protocols, or the peer doesn't correctly set the TLS record versions.
That's almost impossible to occur between two gnutls peers. Could that
again be related to a firewall that modifies the packets sent/received?

Possible. The user turned off their firewall (ESET), but I'm not convinced
that turning it off completely restores normal behaviour.

You mean he still cannot connect even after turning it off? If he gets
the same error, could he be in a corporate firewall that tries to
perform man-in-the-middle? Having a wireshark transcript of his
sessions would help identify the issue.

regards,
Nikos