NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
RBR20 not receiving VPN connection
Hello everyone, i'm trying to setup a vpn connection to access the network when I'm outside home. I followed the instructions provided in different posts: i configured and activated a dns (noip s...
- I have tried to change to tcp, but without success. The openvpn client starts as before, and the connection to the orb is never made.
So I have set up port forwarding, dmz, bridge mode but it looks that the ports are always closed: at least, trying from services on internet to check the status, it appears that none of the changes I make are working.
I’m starting to suspect that my ISP is blocking all ports, since I am using not a “regular” service but a wireless one (through telephone networks) because there was no coverage in my area for other tecnologies..
The computer is a Windows 7 laptop, I have tried with the hotspot from a cell phone
Cell phone Hot Spot is how I test my OpenVPN setup. Could you verify that the client.ovpn file looks like this:
client
dev tap
proto udp
dev-node NETGEAR-VPN
remote *******.mynetgear.com 12974
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
cipher AES-128-CBC
comp-lzo
verb 0
sndbuf 393216
rcvbuf 393216
route-method exe
Another wrinkle in OpenVPN lies with the client software used to make the connection. There are two types of VPN connection:
- tun (an abbreviation for tunnel) which typically uses port 12973, and
- tap (an abbreviation for network tap) which typically uses port 12974.
https://en.wikipedia.org/wiki/TUN/TAP#:~:text=TAP%2C%20namely%20network%20TAP%2C%20simulates,attaches%20itself%20to%20the%20device. Internet search will turn up numerous articles explaining the circumstances which would favor using one method over the other.
My RBR50 Orbi creates a client.ovpn file for Windows connections defining the connection as tap on port 12974. I have used this configuration with successfully with OpenVPN Connect. I have also manually changed the connection to use tun on port 12973.
(As an aside, please note that the Windows configuration is the only version that defaults to tap. Apple and Android do not support a tap connection so the "smart-phone" configuration is set for tun and the "non-windows" configuration is set for tun.)
Perhaps if there is a way to get a more detailed OpenVPN log something may reveal itself.
Hi,
the openvpn config file looks exactly as the one posted above, with the exception of the remote address since I'm using NoIp services so I have something like ****.ddns.net.
However the update from the orbi is successful.
As of today, I have tried:
- Setting the ISP router to bridge mode
- Setting the ISP router to its normal mode but using port forwarding to the ORBI router IP
- Setting the DMZ on the IS router for the ORBI IP
- Changing the port from the ORBI router for the service (trying to see if something changes).
here is a longer log from the openVPN client, please consider that he port is different because I was trying to see if this was the issue (i replaced my external ip with xxx)
Fri Sep 9 09:02:29 2022 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
Fri Sep 9 09:02:29 2022 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
Fri Sep 9 09:02:29 2022 OpenVPN 2.5.7 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on May 27 2022
Fri Sep 9 09:02:29 2022 Windows version 6.1 (Windows 7) 64bit
Fri Sep 9 09:02:29 2022 library versions: OpenSSL 1.1.1o 3 May 2022, LZO 2.10
Fri Sep 9 09:02:30 2022 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Fri Sep 9 09:02:30 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xxx.x.xx:1194
Fri Sep 9 09:02:30 2022 UDP link local: (not bound)
Fri Sep 9 09:02:30 2022 UDP link remote: [AF_INET]xx.xxx.x.xx:1194
Fri Sep 9 09:03:30 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Sep 9 09:03:30 2022 TLS Error: TLS handshake failed
Fri Sep 9 09:03:30 2022 SIGUSR1[soft,tls-error] received, process restarting
Fri Sep 9 09:03:35 2022 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Fri Sep 9 09:03:35 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xxx.x.xx:1194
Fri Sep 9 09:03:35 2022 UDP link local: (not bound)
Fri Sep 9 09:03:35 2022 UDP link remote: [AF_INET]xx.xxx.x.xx:1194
Fri Sep 9 09:04:35 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Sep 9 09:04:35 2022 TLS Error: TLS handshake failed
Fri Sep 9 09:04:35 2022 SIGUSR1[soft,tls-error] received, process restartingfrom this point onward, it just keep repeating and trying to connect without success
thanks
Sorry for the delay. Just spent far too long trying to adjust log verbosity on OpenVPN 2.5.7. and finally realized that it does no good to place:
verb 4
in the client.ovpn file if farther down in the file there is a line reading
verb 0
Stupid. Stupid. Stupid. (Also have learned that verb 4 is waaaay too much information.)
In my log file, where you have:
Fri Sep 9 09:03:30 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Sep 9 09:03:30 2022 TLS Error: TLS handshake failedMy log file continues with:
2022-09-09 14:34:02 us=109000 TLS: Initial packet from [AF_INET]172.249.###.###:12974, sid=4bbca948 5e08609c
2022-09-09 14:34:02 us=203000 VERIFY OK: depth=1, C=TW, ST=TW, L=Taipei, O=netgear, OU=netgear, CN=netgear CA, name=EasyRSA, emailAddress=mail@netgear
2022-09-09 14:34:02 us=203000 VERIFY OK: depth=0, C=TW, ST=TW, L=Taipei, O=netgear, OU=netgear, CN=server, name=EasyRSA, emailAddress=mail@netgear
2022-09-09 14:34:02 us=421000 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, peer certificate: 1024 bit RSA, signature: RSA-SHA256
2022-09-09 14:34:02 us=421000 [server] Peer Connection Initiated with [AF_INET]172.249.112.236:12974Indicating the TLS handshake has succeeded.
All I can think of is the nature of UDP. There is no "handshake" as with TCP/IP. The only way a program knows that a UDP packet has been received is if the remote system sends something back. In this case, the first thing that OpenVPN sends is that TLS handshake.... and it does not get a response.
This would appear to indicate that something is blocking the connection to the router port.
UDP is preferred over TCP/IP because it is more efficient (less overhead). In this case, it might be worth experimenting by:
- Changing the option from UDP to TCP
- Generating a new Windows config file
- Trying OpenVPN with the new config file.