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.

[novaflash]

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:

Code: Select all

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

[novaflash]

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:

Code: Select all

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:

Code: Select all

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.

[novaflash]

Weird. Okay. Glad it works now.