OpenVPN TLS handshake hangs at P_CONTROL_HARD_RESET_SERVER_V2 (not received)

Question

I have a UDP OpenVPN server (running in TAP mode though that shouldn't matter). The connection successfully starts and passes TLS-AUTH (HMAC) however it gets stuck there. I see the following logs repeated in my server log:

Sun Jan 14 13:34:10 2018 us=104130 <CLIENT>:59975 UDPv4 READ [54] from [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0
Sun Jan 14 13:34:10 2018 us=104252 <CLIENT>:59975 UDPv4 WRITE [66] to [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #1 ] [ 0 ] pid=0 DATA len=0
Sun Jan 14 13:34:12 2018 us=524356 <CLIENT>:59975 UDPv4 WRITE [54] to [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
Sun Jan 14 13:34:12 2018 us=650416 <CLIENT>:59975 UDPv4 READ [54] from [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
....

but on the client I have:

2018-01-14 13:34:56 us=989963 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
2018-01-14 13:35:00 us=476619 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #3 ] [ ] pid=0 DATA len=0
2018-01-14 13:35:08 us=911249 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #4 ] [ ] pid=0 DATA len=0
2018-01-14 13:35:24 us=86742 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #5 ] [ ] pid=0 DATA len=0

What's going on here? It's not that there's a firewall blocking this, I can properly communicate over this port using other services (ran a netcat server, bidirectional communication works properly).

Answer 1

This conversation on the openvpn mailing list pushed me in the right direction.

It looks like you have a one-way link. The client can talk to the server but the server can't talk with the client. So there's some kind of blockage or misdirection happening in the server -> client direction.
Client firewall maybe?

(emphasis mine)

The solution for me was to add the line local 192.168.1.X to my server config file. Per the OpenVPN docs:

--local host

Local host name or IP address. If specified, OpenVPN will bind to this address only. If unspecified, OpenVPN will bind to all interfaces.

This, obviously, is a networking issue however it's a the issues are treatable without fixing the underlying issue. The problem for me was how I was configuring my bridge interfaces and my tap out interface. I messed it up in such a way that OpenVPN was trying to route it's response packets back out over an interface which couldn't route it to the destination and so by specifying the specific interface to bind to it will only send it out of the interface with the IP given. I was also able to bypass this issue (and no longer need the local config flag) by fixing my bridge-start script so that it didn't end up creating multiple tap interfaces (all of the extra bridges were unroutable blackholes). Note that even though you're using a local address it will still work properly outside your internal network/over NAT.