Open VPN connection with a Windows 10 PC and a Grandstream GWN7000 acting as an Open VPN server?

IN the formulation of your question you are limiting who can respond to those who have what you have..

Versus open the question up to those familiar with openVPN and address the issue you are facing.
1) which issue are you running into?
2) did you configure the openVPN server on the grandstream?
3) did you install openVPN client on the Windows 10?
When attempting to connect, what errors are reported on the client side log? What errors show up on the grandstream?
Make sure the ip assigned from the openVPN server is not the same as the LAN ip in the win10 system.

Thanks for your comment.  My question was purposuly vague as I really had no starting point other than throwing darts at a dartboard.  I finally found sample Windows Open VPN configuration file on Grandstreams website which I am attaching. "GWN7000_openvpn_client_template_Windows.ovpn"
GWN7000_openvpn_client_template_Win.ovpn

I edited the sample file and plugged in the values I thought were appropriate and seems to make headway with trial and error.  I am attaching that file as well "GWN7000_openvpn_client_template_Windows - Copy.ovpn"
GWN7000_openvpn_client_template_Win.ovpn

Here is the output of the Windows Open VPN client now

Wed Sep 11 20:09:06 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 25 2019
Wed Sep 11 20:09:06 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Sep 11 20:09:06 2019 library versions: OpenSSL 1.1.0j 20 Nov 2018, LZO 2.10
Wed Sep 11 20:09:06 2019 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Sep 11 20:09:06 2019 Need hold release from management interface, waiting...
Wed Sep 11 20:09:07 2019 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Sep 11 20:09:07 2019 MANAGEMENT: CMD 'state on'
Wed Sep 11 20:09:07 2019 MANAGEMENT: CMD 'log all on'
Wed Sep 11 20:09:07 2019 MANAGEMENT: CMD 'echo all on'
Wed Sep 11 20:09:07 2019 MANAGEMENT: CMD 'bytecount 5'
Wed Sep 11 20:09:07 2019 MANAGEMENT: CMD 'hold off'
Wed Sep 11 20:09:07 2019 MANAGEMENT: CMD 'hold release'
Wed Sep 11 20:09:07 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]72.141.242.109:1194
Wed Sep 11 20:09:07 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Sep 11 20:09:07 2019 UDP link local: (not bound)
Wed Sep 11 20:09:07 2019 UDP link remote: [AF_INET]72.141.242.109:1194
Wed Sep 11 20:09:07 2019 MANAGEMENT: >STATE:1568246947,WAIT,,,,,,
Wed Sep 11 20:10:07 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Sep 11 20:10:07 2019 TLS Error: TLS handshake failed
Wed Sep 11 20:10:07 2019 SIGUSR1[soft,tls-error] received, process restarting
Wed Sep 11 20:10:07 2019 MANAGEMENT: >STATE:1568247007,RECONNECTING,tls-error,,,,,
Wed Sep 11 20:10:07 2019 Restart pause, 5 second(s)
Wed Sep 11 20:10:12 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]72.141.242.109:1194
Wed Sep 11 20:10:12 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Sep 11 20:10:12 2019 UDP link local: (not bound)
Wed Sep 11 20:10:12 2019 UDP link remote: [AF_INET]72.141.242.109:1194
Wed Sep 11 20:10:12 2019 MANAGEMENT: >STATE:1568247012,WAIT,,,,,,
Wed Sep 11 20:11:12 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Sep 11 20:11:12 2019 TLS Error: TLS handshake failed
Wed Sep 11 20:11:12 2019 SIGUSR1[soft,tls-error] received, process restarting
Wed Sep 11 20:11:12 2019 MANAGEMENT: >STATE:1568247072,RECONNECTING,tls-error,,,,,
Wed Sep 11 20:11:12 2019 Restart pause, 5 second(s)
Wed Sep 11 20:11:17 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]72.141.242.109:1194
Wed Sep 11 20:11:17 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Sep 11 20:11:17 2019 UDP link local: (not bound)
Wed Sep 11 20:11:17 2019 UDP link remote: [AF_INET]72.141.242.109:1194
Wed Sep 11 20:11:17 2019 MANAGEMENT: >STATE:1568247077,WAIT,,,,,,
Wed Sep 11 20:12:17 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Sep 11 20:12:17 2019 TLS Error: TLS handshake failed
Wed Sep 11 20:12:17 2019 SIGUSR1[soft,tls-error] received, process restarting
Wed Sep 11 20:12:17 2019 MANAGEMENT: >STATE:1568247137,RECONNECTING,tls-error,,,,,
Wed Sep 11 20:12:17 2019 Restart pause, 5 second(s)
Wed Sep 11 20:12:22 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]72.141.242.109:1194
Wed Sep 11 20:12:22 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Sep 11 20:12:22 2019 UDP link local: (not bound)
Wed Sep 11 20:12:22 2019 UDP link remote: [AF_INET]72.141.242.109:1194
Wed Sep 11 20:12:22 2019 MANAGEMENT: >STATE:1568247142,WAIT,,,,,,
Wed Sep 11 20:13:22 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Sep 11 20:13:22 2019 TLS Error: TLS handshake failed
Wed Sep 11 20:13:22 2019 SIGUSR1[soft,tls-error] received, process restarting
Wed Sep 11 20:13:22 2019 MANAGEMENT: >STATE:1568247202,RECONNECTING,tls-error,,,,,
Wed Sep 11 20:13:22 2019 Restart pause, 5 second(s)
Wed Sep 11 20:13:27 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]72.141.242.109:1194
Wed Sep 11 20:13:27 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Sep 11 20:13:27 2019 UDP link local: (not bound)
Wed Sep 11 20:13:27 2019 UDP link remote: [AF_INET]72.141.242.109:1194
Wed Sep 11 20:13:27 2019 MANAGEMENT: >STATE:1568247207,WAIT,,,,,,

Select allOpen in new window

One error I see deals with TLs meaning the connection is not agreed to.

I think you should use TCP and not udp for the tunnel.
When posting in an open forum you shoukd masquerade public Ios.

It seems you are using certificate based authentication, did you generate a certificate for the client system?

Thanks for the tip, I made up the public IP address I posted.

Yes all the certificates were generated from the GWN7000.  There are step by step instuctions in the following link http://www.grandstream.com/sites/default/files/Resources/GWN7000_VPN_Guide.pdf

Ok, on the server which protocol is the openVPN using TCP or UDP?  The example you followed uses TCP, the  client setting that you currently have has proto UDP, meaning it tries to connect to a UDP based openVPN server.

On the client you either named the certificates incorrectly, or used incorrect certificates.
The certificates on the client have to be
CA has to point to the Public portion of the windstream's Certifciate Authority certificate. NO key (never transfer the windstream certificate key to a client) as that will allow the party who posses both to sign certificates that can then be used to connect to your windstream.... i.e. consider the CA certificate key like the money plates.

cert refers to the client certificate that was signed by the CA on the windstream
key is the client side certificates KEY.
these two work in combination. The client presents the certificate to the remote windstream during the inittial connection negotiation.
then each side uses the public part of the certificate to encrypt the data they send. The receiving side uses the KEY to decrypt the data and then using the others Public Certificate to encrypt the response.

Based on the names I think your client has the wrong set of certificates/keys combination... which likely explains why the TLS connection fails.

its like you are hosting an event an I am a guest, but at the check in, I was given your badge and all your paperwork for the event.

Also, you are not specifying a cipher on the client.
The default BF-CBC SHA1 is not as secure.

In short the two have to be in a way mirror of each other.

You may want to have TLS authentication as well.
Deals with establishes a connection, but then have to have a valid username/password to authenticate/authorize the system with the windstream.

i.e. certificate authentication first, then prompts the user for login.  This way you can disable the user to prevent access.

In the no login mode, the only option you have is to revoke/terminate the client certificate though not sure you would be able to do that to prevent the client from connecting

This is a two factor meaning more secure

Thanks for the responses.  I changed the server protocol to TCP so they now match.  The TLS errors seem to be generic default erros as I chnged the target IP 72.141.242.107 and the port to1188 (72.141.242.107:1188) and recieved the same errors.  This tells me the Open VPN client on my Windows 10 PC is throwing the same error when I attmept to connect to the proper public IP and port of the Open VPN server and when I attmept to connect to the wrong public IP and the wrong port.

Tue Sep 17 18:36:51 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Sep 17 18:36:51 2019 TLS Error: TLS handshake failed

you can not randomly change port, you would need to configure the outside facing firewall/router to forward the port....

You can use mxtoolbox.com more port scan and see whether the port is accessible that you define for use by openVPN.

once it is seen as open, try it again from the client side.

I changed the port and IP just to see what error messages I would receive and they are the same as when I have the correct public Ip and correct port.

try to confirm that the port on the outside actually reaches the service running.

what does the log on the grandstream indicate related to openvpn connection?