VPN Connection stuck at "need hold release from management interface"

bens

Hello,

There is a user workstation experiencing issues connecting to the VPN.

Note that :

OpenVPN server is hosted on pfSense
A certificate-based authentication is configured between the client and the server.
OpenVPN client version : 2.7.4

Here is the client log

2026-07-28 12:55:36 DEPRECATED OPTION: --persist-key option ignored. Keys are now always persisted across restarts. 2026-07-28 12:55:36 OpenVPN 2.7.4 [git:v2.7.4/8e9e91f4caff9a80] Windows [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Apr 30 2026 2026-07-28 12:55:36 Windows version: 10.0.26100,amd64 2026-07-28 12:55:36 library versions: OpenSSL 3.6.2 7 Apr 2026, LZO 2.10 2026-07-28 12:55:36 DCO version: 2.8.2 2026-07-28 12:55:36 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:253

As well as the client configuration

##############################################
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server.     #
#                                            #
# This configuration can be used by multiple #
# clients, however each client should have   #
# its own cert and key files.                #
#                                            #
# On Windows, you might want to rename this  #
# file so it has a .ovpn extension           #
##############################################

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one.  On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap

# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
;proto tcp
;proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
;remote my-server-1 1194
;remote my-server-2 1194

# Try UDPv6 then UDPv4
<connection>
proto udp6
remote 2001:x:x:x:x:x:x:x 1194
connect-timeout 10
</connection>

<connection>
proto udp
remote 147.x.x.x 1194
connect-timeout 20
</connection>

# Try TCPv6 then TCPv4
<connection>
proto tcp6-client
remote 2001:x:x:x:x:x:x:x 1194
connect-timeout 10
</connection>

<connection>
proto tcp-client
remote 147.x.x.x 1194
</connection>

# Choose a random host from the remote
# list for load-balancing.  Otherwise
# try hosts in the order specified.
;remote-random

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
;nobind

# Downgrade privileges after initialization (non-Windows only)
;user nobody
;group nobody

# Try to preserve some state across restarts.
persist-key
persist-tun

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings

# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
ca ca.crt
;cert client.crt
;key client.key
cryptoapicert "SUBJ:xxxx.domain.fr"

# Verify server certificate by checking that the
# certificate has the correct key usage set.
# This is an important precaution to protect against
# a potential attack discussed here:
#  http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the keyUsage set to
#   digitalSignature, keyEncipherment
# and the extendedKeyUsage to
#   serverAuth
# EasyRSA can do this for you.
remote-cert-tls server

# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
# Note that v2.4 client/server will automatically
# negotiate AES-256-GCM in TLS mode.
# See also the data-ciphers option in the manpage
cipher AES-256-GCM

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
#compress lz4

# Set log file verbosity.
verb 3

# Silence repeating messages
;mute 20

The issue seems to be lying with the management interface of the user's workstation.
There are no server logs related to this connection. The client never reaches the server.

Thanks for your help.

Mohammad Montazeri

The log stops exactly where the daemon is deliberately waiting, so it is worth splitting this into two problems before you look any further at the profile or at pfSense.

--management-hold is not something your .ovpn sets, OpenVPN GUI adds it. The GUI starts openvpn.exe with a management socket on 127.0.0.1, connects to that socket, authenticates, subscribes to state and log output, and only then sends hold release. Address resolution and the first outgoing packet happen after that. So "need hold release from management interface" plus no server-side log means the GUI/daemon handshake never completed, and your certificates, the four <connection> blocks and the pfSense side have not been exercised at all yet. Nothing in what you posted is wrong for that stage.

Quickest way to confirm it: close the GUI, make sure no openvpn.exe survives, then from a Command Prompt in the config folder run

"C:\Program Files\OpenVPN\bin\openvpn.exe" --config yourprofile.ovpn

If that reaches TLS negotiation, the profile and the firewall side are fine and the fault is purely local to the GUI and management path. Run it as the affected user rather than as SYSTEM, since cryptoapicert has to reach that user's certificate store.

Things that produce this exact state on one workstation:

An orphaned openvpn.exe from an earlier session still holding the management port, so the GUI either attaches to the wrong instance or cannot connect at all. Check with tasklist /fi "imagename eq openvpn.exe" and netstat -ano | findstr 127.0.0.1:2534; the GUI allocates management ports from 25340 upwards, one per profile. Incidentally the pasted line reads 127.0.0.1:253, which looks truncated, so the real port number is worth confirming.
Endpoint protection filtering loopback. Several EDR and AV products intercept 127.0.0.1 TCP. The daemon listens happily, the GUI's connect attempt is dropped silently, and no component logs an error. Check the product's blocked-connection log, or test with its network filter temporarily off.
Mixed or partial installations: an older openvpn-gui.exe driving a 2.7.4 core, or two installations in different directories. Check openvpn-gui.exe --version, that only one OpenVPN entry exists in Programs and Features, and that OpenVPNServiceInteractive is running, since that service is what launches the daemon when the GUI is not elevated.
A management directive inside the profile or an included file, colliding with the port and password the GUI wants to use. Not visible in what you pasted, but worth grepping the whole set on that machine.

Two things would narrow this a lot: the full GUI log for that connection at verb 4, specifically whether anything at all appears after the MANAGEMENT line, and whether the fault follows the machine or the account. Does the same Windows user work on another workstation, and does a different user work on this one?