Project

General

Profile

Bug #7905

OpenVPN Authentication Against Backend Stalls All Server Traffic

Added by Chris Linstruth 3 months ago. Updated about 2 months ago.

Status:
Confirmed
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 2 months 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 2 months 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.

#3 Updated by Jim Thompson about 2 months ago

  • Assignee set to Jim Pingle

#4 Updated by Jim Pingle about 2 months ago

  • Status changed from New to Confirmed
  • Target version changed from 2.4.2 to 2.4.3

I was finally able to confirm the problem, I'm looking at that auth_script plugin now, but it will require some significant changes to the auth script and it doesn't compile out of the box on FreeBSD. Probably going to need more time to analyze this than we have for 2.4.2 given the nature of how it operates and what is required, so bumping it forward for now.

Also available in: Atom PDF