Project

General

Profile

Bug #7905

OpenVPN Authentication Against Backend Stalls All Server Traffic

Added by Chris Linstruth 18 days ago. Updated 7 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
OpenVPN
Target version:
Start date:
10/01/2017
Due date:
% Done:

0%

Affected Version:
2.4
Affected Architecture:
All

Description

When authenticating an OpenVPN Remote Access server against an authentication backend such as RADIUS, all traffic on the server is halted while that authentication is processed. If this takes time, such as RADIUS to a MFA service such as Duo, this delay can be significant even under normal circumstances.

Test procedure:

Created and tested a RADIUS Authentication backend with a 30-second authentication timeout

Created an SSL/TLS + User Auth OpenVPN Server backed by the RADIUS server

Created two different user certificates and corresponding RADIUS accounts

Successfully logged in using the first account and started a ping

Changed the RADIUS server IP address so the request would "hang" for the configured 30 seconds

Attempted to log in to the second account

While that was timing out I changed the RADIUS server back to the proper IP address to see if Viscosity (the first client) recovered automatically. It did time out and reconnect successfully.

  1. 5 seconds apart
    $ ping -i 5 172.25.228.1
    PING 172.25.228.1 (172.25.228.1): 56 data bytes
    64 bytes from 172.25.228.1: icmp_seq=0 ttl=63 time=4.658 ms
    64 bytes from 172.25.228.1: icmp_seq=1 ttl=63 time=5.461 ms
    64 bytes from 172.25.228.1: icmp_seq=2 ttl=63 time=4.718 ms
    64 bytes from 172.25.228.1: icmp_seq=3 ttl=63 time=4.881 ms
    64 bytes from 172.25.228.1: icmp_seq=4 ttl=63 time=2.311 ms
    64 bytes from 172.25.228.1: icmp_seq=5 ttl=63 time=4.756 ms
    64 bytes from 172.25.228.1: icmp_seq=6 ttl=63 time=4.851 ms
    64 bytes from 172.25.228.1: icmp_seq=7 ttl=63 time=5.014 ms
    64 bytes from 172.25.228.1: icmp_seq=8 ttl=63 time=4.892 ms
    64 bytes from 172.25.228.1: icmp_seq=9 ttl=63 time=2.622 ms
    Request timeout for icmp_seq 10
    Request timeout for icmp_seq 11
    Request timeout for icmp_seq 12
    Request timeout for icmp_seq 13
    Request timeout for icmp_seq 14
    Request timeout for icmp_seq 15
    Request timeout for icmp_seq 16
    Request timeout for icmp_seq 17
    Request timeout for icmp_seq 18
    Request timeout for icmp_seq 19
    Request timeout for icmp_seq 20
    Request timeout for icmp_seq 21
    64 bytes from 172.25.228.1: icmp_seq=22 ttl=63 time=2.731 ms
    64 bytes from 172.25.228.1: icmp_seq=23 ttl=63 time=4.933 ms
    64 bytes from 172.25.228.1: icmp_seq=24 ttl=63 time=5.390 ms
    64 bytes from 172.25.228.1: icmp_seq=25 ttl=63 time=5.429 ms
    64 bytes from 172.25.228.1: icmp_seq=26 ttl=63 time=5.014 ms
    64 bytes from 172.25.228.1: icmp_seq=27 ttl=63 time=5.074 ms

Same behavior on 2.3.4_1 and most-recent 2.4.0-RC. I did not test 2.4.1 since it uses the same OpenVPN package as 2.4.0.

History

#1 Updated by Jim Pingle 18 days ago

  • Affected Architecture set to All

Looks like it's a known issue with the nature of auth-user-pass-verify that OpenVPN does not plan to address: https://community.openvpn.net/openvpn/ticket/222

But there is a workaround:
http://engineering.freeagent.com/2017/05/22/external-authentication-scripts-in-openvpn-the-right-way/
https://github.com/fac/auth-script-openvpn

Looks like that would need to be converted into a FreeBSD port or added to the OpenVPN port and then the OpenVPN code and auth script would have to be adapted to use it instead, assuming it can do everything we need it to do.

#2 Updated by Jim Pingle 7 days ago

  • Target version changed from 2.4.1 to 2.4.2

Moving target to 2.4.2 as we need 2.4.1 sooner than anticipated.

Also available in: Atom PDF