Is a TCP port needed or can I open only 1194 for UDP

john.watson

My reading of the docs says that an OpenVPN client can contact the openvpnas server using UDP or TCP, but if I close the TCP ports on the server I cannot connect. In my client, I have tried setting the option VPN protocol to UDP rather than adaptive, no difference: unless 443 is open for TCP, I cannot get through.

Am I missing something stupid here?

Thank you for any insight.

The Johan

Try downloading a user-locked profile or auto-login profile from the web interface of the Access Server, and loading it into your OpenVPN Connect client, and use that to connect.

Normally the client is configured for server-locked profile which is a universal type profile which allows any valid user to authenticate and connect. But that requires access to the web services to negotiate for a VPN profile before the VPN tunnel can actually start. If you make the web services unavailable, that will fail. Loading a user-locked or autologin-profile will limit your ability to connect to just that specific user but it won't need the web services then to get a VPN profile. It then already has one.

john.watson

Thank you for replying.

I am using a user-locked profile (at least, that is what the openvpnas tells me I can download). When I create a user, I don't actually see anywhere to choose the type of profile, is there some way to check whether I really do have a user-locked profile? Or some place in the admin GUI where I choose which type to create?

Update: looking at the client.ovpn file that comes down, it is a user-locked profile.I see this:

# Note: this configuration is user-locked to the username below
# OVPN_ACCESS_SERVER_USERNAME=johnwatson

The Johan

By default the OpenVPN Connect client installer file comes prebundled with a server-locked profile. There is no option setting to change this.

john.watson

I know I am using a user-locked profile. However, running a port scan tells me that 1194 is closed:

C:\Windows\System32\drivers\etc>nmap -sU -p1194 -A x.x.x.x
Starting Nmap 7.70 ( https://nmap.org ) at 2019-12-03 15:30 GMT Standard Time
Nmap scan report for xxxx.compute-1.amazonaws.com (x.x.x.x)
Host is up (0.097s latency).

PORT     STATE  SERVICE VERSION
1194/udp closed openvpn

Does this suggest that my server-side openvpnas config is the problem? Perhaps it simply isn't listening for UDP at all? Within the admin GUI, I have specified to listen on all interfaces and run in multi-daemon mode. Is that how one would usually do it?

Again, thank you for any insight.

Update: corrected silly mistake in the copy paste above.

john.watson

After a restart of the openvpnas service, my nmap says 1194 UDP is open|filtered. ie, nmap has no idea because it gets nothing back). However, the openvpnas.log does show that it is being hit frion my PC:

2019-12-03T15:42:26+0000 [stdout#info] [OVPN 2] OUT: 'Tue Dec  3 15:42:26 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]86.159.30.98:60742 (via [AF_INET]172.31.133.102%ens5)'

so I guess the port must be open.

And (wonder of wonders!) I can now get a connection over UDP even though I have disabled all TCP access. So perhaps the hassles were all resolved by bouncing the openvpnas service.

The Johan

Weird. Okay. Glad it works now.