Can't connect using client 2.3.11

[paxlo]

After upgrade 2.3.10 -> 2.3.11 client on Fedora 23 can't connect to ovpn server on Mikrotik RouterOS 6.35.2

Downgraded client (2.3.10 or 2.3.8) works fine!

Client config:

proto tcp-client
remote MIKROTIK_IP 64447
dev tap
nobind
persist-key
client
ping 10
verb 6
cipher AES-256-CBC
auth SHA1
auth-user-pass ./user
route-delay 2
route 172.20.4.0 255.255.255.192 10.20.4.1
resolv-retry infinite
<pkcs12>
...
PRIVATE CERTIFICATE
...
</pkcs12>

Server config:

/ip pool
add name=ovpn-pool ranges=10.20.4.10-10.20.4.62

/ppp profile
add local-address=10.20.4.1 name=ovpn remote-address=ovpn-pool use-encryption=required

/ppp secret
add name=user password=password profile=ovpn service=ovpn

/interface ovpn-server server
set auth=sha1 certificate=main.crt_0 cipher=aes256 default-profile=ovpn enabled=yes mode=ethernet netmask=26 port=64447 require-client-certificate=yes

Connection resetting and trying to reconnect with the following log:

Fri May 20 17:01:44 2016 us=197903 Control Channel MTU parms [ L:1591 D:1210 EF:40 EB:0 ET:0 EL:3 ]
Fri May 20 17:01:44 2016 us=197927 Socket Buffers: R=[87380->87380] S=[16384->16384]
Fri May 20 17:01:44 2016 us=236183 Data Channel MTU parms [ L:1591 D:1450 EF:59 EB:12 ET:32 EL:3 ]
Fri May 20 17:01:44 2016 us=236222 Local Options String: 'V4,dev-type tap,link-mtu 1591,tun-mtu 1532,proto TCPv4_CLIENT,cipher AES-256-CBC,auth SHA1,keysize 25
Fri May 20 17:01:44 2016 us=236229 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1591,tun-mtu 1532,proto TCPv4_SERVER,cipher AES-256-CBC,auth SHA1,
Fri May 20 17:01:44 2016 us=236247 Local Options hash (VER=V4): 'b60e7885'
Fri May 20 17:01:44 2016 us=236255 Expected Remote Options hash (VER=V4): 'fbeb66e6'
Fri May 20 17:01:44 2016 us=236265 Attempting to establish TCP connection with [AF_INET]MIKROTIK_IP:64447 [nonblock]
Fri May 20 17:01:45 2016 us=236365 TCP connection established with [AF_INET]MIKROTIK_IP:64447
Fri May 20 17:01:45 2016 us=236401 TCPv4_CLIENT link local: [undef]
Fri May 20 17:01:45 2016 us=236422 TCPv4_CLIENT link remote: [AF_INET]MIKROTIK_IP:64447
Fri May 20 17:01:45 2016 us=236469 TCPv4_CLIENT WRITE [14] to [AF_INET]MIKROTIK_IP:64447: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri May 20 17:01:45 2016 us=236527 TCPv4_CLIENT READ [14] from [AF_INET]MIKROTIK_IP:64447: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0
Fri May 20 17:01:45 2016 us=236539 TLS: Initial packet from [AF_INET]MIKROTIK_IP:64447, sid=0484618d a6d5f03a
Fri May 20 17:01:45 2016 us=236551 TCPv4_CLIENT WRITE [26] to [AF_INET]MIKROTIK_IP:64447: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ 0 ] pid=0 DATA len=0
Fri May 20 17:01:45 2016 us=240144 TCPv4_CLIENT READ [22] from [AF_INET]MIKROTIK_IP:64447: P_ACK_V1 kid=0 [ 0 ]
Fri May 20 17:01:45 2016 us=240190 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri May 20 17:01:45 2016 us=240226 TCPv4_CLIENT WRITE [257] to [AF_INET]MIKROTIK_IP:64447: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=243
Fri May 20 17:01:45 2016 us=274522 TCPv4_CLIENT READ [22] from [AF_INET]MIKROTIK_IP:64447: P_ACK_V1 kid=0 [ 1 ]
Fri May 20 17:01:45 2016 us=276843 Connection reset, restarting [0]
Fri May 20 17:01:45 2016 us=276911 TCP/UDP: Closing socket
Fri May 20 17:01:45 2016 us=276946 SIGUSR1[soft,connection-reset] received, process restarting
Fri May 20 17:01:45 2016 us=276962 Restart pause, 5 second(s)

I tried different tun-mtu & link-mtu, but to no effect.

Full log in attachment

[Gert Döring]

Looks like the Mikrotik server is only offering weak TLS crypto, which is one of the major changes 2.3.10 -> 2.3.11: remove weak ciphers from what we expect.

Try connecting with

--tls-cipher "DEFAULT:!EXP:!LOW"

in your client config, or even

--tls-cipher DEFAULT

(which permits OpenSSL's default ciphers, which includes about everything, including non-secure export ciphers, low-security ciphers, etc. - definitely not recommended, but can help troubleshooting)

A server log would be helpful in tracking this further. The client log just shows that the server does not want to talk to you.

[paxlo]

syzzer, thanks! --tls-cipher DEFAULT was helpful. Now, connection works fine!

Mikrotik debug with max loglevel:

echo: ovpn,info TCP connection established from CLIENT_IP
packet rcvd P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 sid=f94bdb21c97878bb pid=0 DATA len=0
packet sent P_ACK kid=0 sid=c0dfe229f9dfcbd [0 sid=f94bdb21c97878bb] DATA len=0
packet rcvd P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 sid=f94bdb21c97878bb [0 sid=c0dfe229f9dfcbd] pid=0 DATA len=0
packet rcvd P_CONTROL kid=0 sid=f94bdb21c97878bb pid=1 DATA len=243
packet sent P_ACK kid=0 sid=c0dfe229f9dfcbd [1 sid=f94bdb21c97878bb] DATA len=0
packet sent P_CONTROL kid=0 sid=c0dfe229f9dfcbd pid=1 DATA len=7
echo: ovpn,debug <CLIENT_IP>: disconnected <TLS failed>
packet sent P_CONTROL_HARD_RESET_SERVER_V2 kid=0 sid=e3af253b168819d pid=0 DATA len=0
packet rcvd P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 sid=2162edacbde3bb4 pid=0 DATA len=0
packet sent P_ACK kid=0 sid=e3af253b168819d [0 sid=2162edacbde3bb4] DATA len=0
packet rcvd P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 sid=2162edacbde3bb4 [0 sid=e3af253b168819d] pid=0 DATA len=0
packet rcvd P_CONTROL kid=0 sid=2162edacbde3bb4 pid=1 DATA len=243
packet sent P_ACK kid=0 sid=e3af253b168819d [1 sid=2162edacbde3bb4] DATA len=0
packet sent P_CONTROL kid=0 sid=e3af253b168819d pid=1 DATA len=7
echo: ovpn,debug <CLIENT_IP>: disconnected <TLS failed>     

[Gert Döring]

I'm not syzzer :-) - but glad to hear it works.

@paxlo: since it works now, can you share the part of the (working) client log that shows what cipher is negotiated? Something like

Mon May 9 21:18:59 2016 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

... and then syzzer can recommend what you want (DEFAULT is too insecure, really) to make it work without accepting all the weakest ciphers...

[paxlo]

Working client log:

Control Channel: TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 2048 bit RSA

Comparing --show-tls for 2.3.10 and 2.3.11 version, i saw that TLS-RSA-WITH-AES-256-GCM-SHA384 is no supported in 2.3.11.

I wrote to mikrotik support, that they have added support for current ciphers.

[Steffan Karger]

Yes, cron2's analysis is right. Between 2.3.10 and 2.3.11, we changed the default --tls-cipher value from

   tls-cipher DEFAULT

to

   tls-cipher DEFAULT:!EXP:!LOW:!MEDIUM:!PSK:!SRP:!kRSA

The suite you're using now (TLS-RSA-WITH-AES-256-GCM-SHA384) is part of the kRSA group. Just removing that last ':!kRSA' from the option should make it work again for you. Note however that this means that your connection is not forward secure (meaning, if an attacker ever gets hold of your RSA keys, that attacker can decrypt all past communication where that key was used).

Mikrotik should enable forward-secure cipher suites. Once they do, please remove the 'tls-cipher' option from your config again. We will likely update the default value in the future, to protect our users even better.

I'm closing this now, because a solution is available, and the 'bug' is in Mikrotik router's lack of support for forward secure ciphers, not in OpenVPN.

[Gert Döring]

thanks for the explanation that !kRSA is the cause here - so, it's documented, workaround exists, and Mikrotik should really add the DHE/ECDH ciphers (diffie-hellman).

[paxlo]

Support wrote me:

We have released RouterOS v6.36rc16 which contains a fix for this problem.