The VPN connection failed because the connection attempt timed out

lattimro · 11-19-2021, 11:25 AM

First time in my life I am trying to setup a VPN and connection timeout.
- both server and client services are running on the same machine respectively openvpn-server@server and openvpn@client
- I am not using wireless, I am using wired and it is up
- the firewall is not blocking the port

Quote:

There are lots of people talking the talk about VPN tunnels but very few people actually walking the walk unfortunately.

Code:

● openvpn@client.service - OpenVPN connection to client
     Loaded: loaded (/lib/systemd/system/openvpn@.service; disabled; vendor preset: enabled)
     Active: active (running) since Fri 2021-11-19 17:30:10 EST; 1s ago
       Docs: man:openvpn(8)
             https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
             https://community.openvpn.net/openvpn/wiki/HOWTO
   Main PID: 17451 (openvpn)
     Status: "Pre-connection initialization successful"
      Tasks: 1 (limit: 4494)
     Memory: 1.0M
        CPU: 56ms
     CGroup: /system.slice/system-openvpn.slice/openvpn@client.service
             └─17451 /usr/sbin/openvpn --daemon ovpn-client --status /run/openvpn/client.status 10 --cd /etc/openvpn --script-security >

Nov 19 17:30:10 zika ovpn-client[17451]: OpenVPN 2.5.1 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [A>
Nov 19 17:30:10 zika ovpn-client[17451]: library versions: OpenSSL 1.1.1l  24 Aug 2021, LZO 2.10
Nov 19 17:30:10 zika ovpn-client[17451]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Nov 19 17:30:10 zika ovpn-client[17451]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authenticati>
Nov 19 17:30:10 zika ovpn-client[17451]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Nov 19 17:30:10 zika ovpn-client[17451]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authenticati>
Nov 19 17:30:10 zika ovpn-client[17451]: TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.1.1:1194
Nov 19 17:30:10 zika ovpn-client[17451]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Nov 19 17:30:10 zika ovpn-client[17451]: UDP link local: (not bound)
Nov 19 17:30:10 zika ovpn-client[17451]: UDP link remote: [AF_INET]192.168.1.1:1194
lines 1-24/24 (END)

netstat -tulpn|g open

Code:

 
udp        0      0 192.168.1.4:1194        0.0.0.0:*                           16198/openvpn       
udp        0      0 0.0.0.0:37412           0.0.0.0:*                           17451/openvpn

wpeckham · 11-19-2021, 12:06 PM

The first thing to check is that each VPN endpoint can ping the other (or telnet to an open port if ping packets are dropped).
If there is not open network from one VPN endpoint to the other, you will never get to the authentication negotiation steps to construct the tunnel.
Once you are certain that you have a network connection, you need to verify that both ends agree on the port for the connection and the VPN protocol to use.
Even if following steps fail, at that point you should be able to get past that connection failure.

lattimro · 11-19-2021, 12:23 PM

Quote:

Originally Posted by wpeckham

The first thing to check is that each VPN endpoint can ping the other (or telnet to an open port if ping packets are dropped).
If there is not open network from one VPN endpoint to the other, you will never get to the authentication negotiation steps to construct the tunnel.
Once you are certain that you have a network connection, you need to verify that both ends agree on the port for the connection and the VPN protocol to use.
Even if following steps fail, at that point you should be able to get past that connection failure.

Thanks so much, first of all both ends are on the same machine I do not understand how to check. The ping and DNS work.

wpeckham · 11-19-2021, 02:43 PM

Quote:

Originally Posted by lattimro

Thanks so much, first of all both ends are on the same machine I do not understand how to check. The ping and DNS work.

Confusion here: why would you need a VPN to secure traffic WITHIN a machine? That is not really a use for which the technology is designed, but I do see you mentioned that earlier.

So, you can ping each form the other. Is the OpenVPN server configured and running? If it is not, then the client would have nothing to which it could connect. If it Is running, examine the output of

Code:

ss -lp

and see if it is listening properly, and on what port. You will need to ensure that it IS listening, and that the client will attempt to connect at that address and port.

lattimro · 11-19-2021, 03:29 PM

Quote:

Originally Posted by wpeckham

Confusion here: why would you need a VPN to secure traffic WITHIN a machine? That is not really a use for which the technology is designed, but I do see you mentioned that earlier.

So, you can ping each form the other. Is the OpenVPN server configured and running? If it is not, then the client would have nothing to which it could connect. If it Is running, examine the output of

Code:

ss -lp

and see if it is listening properly, and on what port. You will need to ensure that it IS listening, and that the client will attempt to connect at that address and port.

I could be wrong but I thought I will first test my connection locally and then deploy the server.
Yes, is running, please see OP. Thanks!

The client was listening on udp instead tcp and I corrected that but now connection refused ..

michaelk · 11-19-2021, 04:36 PM

Quote:

Attempting to establish TCP connection with [AF_INET]xxx.xxx.xxx.xxxx:YYYY [nonblock]

If you are testing a local connection then your source address would be your LAN address i.e. 192.168.1.4 or 127.0.0.1. Otherwise more information is need to how you configured the server/client. If your using your public IP address then you would need to forward port 1194 through your router and local firewall. You would also need to change your ovpn configuration file to use the public or private IP address/port.

What guide did you use to configure the server / client?

lattimro · 11-19-2021, 05:28 PM

Quote:

Originally Posted by michaelk

If you are testing a local connection then your source address would be your LAN address i.e. 192.168.1.4 or 127.0.0.1. Otherwise more information is need to how you configured the server/client. If your using your public IP address then you would need to forward port 1194 through your router and local firewall. You would also need to change your ovpn configuration file to use the public or private IP address/port.

What guide did you use to configure the server / client?

https://www.cyberciti.biz/faq/ubuntu...-in-5-minutes/

Correct, after some testing I noticed the router is blocking (obviously) the traffic and I configured the server from public IP to private IP, and modified the OP. accordingly.
@ michaelk Thanks a lot for wake me up! However now with the OpenVPN server running what is the next step?

PHP Code:



They did not mentioned about forwarding the port 1149 in the router

therefore is it any use of this local OpenVPN server?

michaelk · 11-20-2021, 07:44 AM

Quote:

therefore is it any use of this local OpenVPN server?

It allows to connect to your LAN remotely and if using a public wifi will give you the same protection as using a VPN service. Its usability depends on your internet speed.

wpeckham · 11-20-2021, 08:25 AM

The only way the router should be involved is if you use the external addresses for the nodes, or move a node to a different routed subnet that goes through the router. For one node to another on the SAME MACHINE you should be using the local non-routable ip addresses for the nodes. There is no reason for the traffic to travel outside of that one machine if this is just testing.

Normally, a VPN is used to encrypt and protect traffic traveling from one node or network to a different node or network. The encryption is of value to protect the data from being intercepted, captured and used, by a bad player along the route. It also makes the remote node or network appear to be relatively local to the client. Secure and simplified communications as if on a local network is the main point.

Within a single machine, or on a secured network, a VPN within the network is almost pointless EXCEPT AS AN EDUCATIONAL EXPERIMENT! For that it hs significant value! I presume that the OP is using this as an opportunity to learn how to configure OpenVPN and use it to establish a connection, tunnel, and traffic.

lattimro: As long as you use the local IP addressing of the nodes you should not need to manage the router. Once you want to attempt a VPN connection from outside of your local subnet (such as from a Internet cafe/Starbucks, motel, or other external location then the ports for the VPN need to be open and routed from your external device to your VPN server within your network. Without that routing, the packets have no way to "find" your internal server. For that connection you will need your client to use your servers EXTERNAL address and port.

Is that clear, or have we adequately confused things? ;-) I remember when I learned this stuff (back before they invented hair, yup I am OLD!) I found it confusing at first.

lattimro · 11-20-2021, 11:09 AM

Thanks folks, definitely my reading sources are trivial enough to add every time more confusions and the only way is to experiment as you mentioned. Nowhere I read (the link provided in the OP) that they mentioned VPN tunnel that you have to forward the port XXXX (1194) in your router. In their tutorial they are using an external (public IP) and this was what I initially did when the connection timeout. I thought if I will setup my OpenVPN server I would be able to remotely access my LAN (w/o opening the port in the router, which would not be an issue but integrity). So to my understanding:
- without forwarding the port, VPN is useless (other than testing).
- to have VPN tunnel the server need to open the port to the public address which opens a can of worms,

This command:

Code:

Can the Linux desktop client connect to the OpenVPN server machine? First you need to run a simple test to see if the OpenVPN server port (UDP 1194) accepts connections:
$ nc -vu 104.20.187.5 1194
Connection to 104.20.187.5 1194 port [udp/openvpn] succeeded!

I can change to any IP and the outpuut does not change.
- for experimental local VPN, the server is listening but how to use/connect and create a tunnel? I supposed the tunnel is created automatically when the client connects to the server. But then why I do not see ESTABLISHED? Is there any way to see that? I can ping the ends OK , but not see the traffic between.
For ssh for instance, one can see ESTABLISHED and then you remotely connect to the machine but for VPN how to check the traffic is routed to VPN tunnel? I am totally lost in this!

I am sure still missing some knowledge because this technology is available for almost 30 years and vulnerability was the main point but to me now opening a port defeat that goal.
@ wpeckham your post is clear enough just I want to double check I understand correctly.

michaelk · 11-20-2021, 12:32 PM

OpenVPN is very secure and although opening a port through the router does have some risk in this case it is very low. The posted guide has a few errors and using nc in this case does not really test the connection.

lattimro · 11-21-2021, 07:55 AM

Quote:

Originally Posted by michaelk

OpenVPN is very secure and although opening a port through the router does have some risk in this case it is very low. The posted guide has a few errors and using nc in this case does not really test the connection.

lots of 'em:

Code:

Next, copy desktop.ovpn as follows:
$ sudo cp desktop.ovpn /etc/openvpn/client.conf

Test connectivity from the CLI:
$ sudo openvpn --client --config /etc/openvpn/desktop.conf

It should had been:

Code:

$ sudo openvpn --client --config /etc/openvpn/client.conf

lattimro · 11-21-2021, 07:58 AM

please help:

Code:

openvpn --client --config /etc/openvpn/client.conf
2021-11-21 08:56:00 Unrecognized option or missing or extra parameter(s) in /etc/openvpn/client.conf:13: block-outside-dns (2.5.1)
2021-11-21 08:56:00 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
2021-11-21 08:56:00 OpenVPN 2.5.1 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 17 2021

Code:

 journalctl -r --identifier openvpn
-- Journal begins at Tue 2021-07-13 07:17:33 EDT, ends at Sun 2021-11-21 09:31:10 EST. --
Nov 21 09:31:10 zika openvpn[39882]: Use --help for more information.
Nov 21 09:31:10 zika openvpn[39882]: Options error: In [CMD-LINE]:1: Error opening configuration file: client.conf
Nov 21 09:31:05 zika openvpn[39877]: Use --help for more information.
Nov 21 09:31:05 zika openvpn[39877]: Options error: In [CMD-LINE]:1: Error opening configuration file: client.conf
Nov 21 09:30:59 zika openvpn[39873]: Use --help for more information.
Nov 21 09:30:59 zika openvpn[39873]: Options error: In [CMD-LINE]:1: Error opening configuration file: client.conf
Nov 21 09:30:54 zika openvpn[39661]: Use --help for more information.
Nov 21 09:30:54 zika openvpn[39661]: Options error: In [CMD-LINE]:1: Error opening configuration file: client.conf

This:

Code:

dig TXT +short o-o.myaddr.l.google.com @ns1.google.com #Must return public IP address of OpenVPN server

returns my public IP address. But must return public IP address of OpenVPN server. How can I find that IP?

wpeckham · 11-21-2021, 10:43 AM

If you have all three nodes (host, OpenVPN server guest, OpenVPN client guest) behind one external connection to a single ISP then they will all have the same external address. Exception is in an enterprise business ISP connection where you have multiple external addresses in a block. If you have that you would have to tell us.

Each of those three nodes should have a unique non-routable internal address. (Not 127.0.0.1, that is the internal loopback address for the node that can only talk to itself.) In IPV4 those addresses are from the 10.0.0.0/8 subnet, the 192.168.0.0/16 subnet, or the 172.16.0.0/16 subnet. Look for the address of the OpenVPN server node. That is what you would use as its address INSIDE your network. From outside your network you would use the EXTERNAL address given by your ISP and the port you forwarded to the OpenVPN Server in your gateway device/router.

I hope that helps.

lattimro · 11-21-2021, 11:51 AM

I reconfigured the server with the external IP (back to the square one) and now something works better:

they said

Quote:

If the ping succeeds, congratulations! You now have a functioning VPN.

ping 10.8.0.1

Code:

PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=0.143 ms
64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=0.120 ms
64 bytes from 10.8.0.1: icmp_seq=3 ttl=64 time=0.132 ms
^C
--- 10.8.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2057ms
rtt min/avg/max/mdev = 0.120/0.131/0.143/0.009 ms

openvpn --client --config /etc/openvpn/client.conf

Code:

2021-11-21 12:47:31 Unrecognized option or missing or extra parameter(s) in /etc/openvpn/client.conf:13: block-outside-dns (2.5.1)
2021-11-21 12:47:31 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
2021-11-21 12:47:31 OpenVPN 2.5.1 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 17 2021
2021-11-21 12:47:31 library versions: OpenSSL 1.1.1l  24 Aug 2021, LZO 2.10
2021-11-21 12:47:31 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2021-11-21 12:47:31 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2021-11-21 12:47:31 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2021-11-21 12:47:31 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2021-11-21 12:47:31 TCP/UDP: Preserving recently used remote address: [AF_INET]104.247.234.133:1194
2021-11-21 12:47:31 Socket Buffers: R=[212992->212992] S=[212992->212992]
2021-11-21 12:47:31 UDP link local: (not bound)
2021-11-21 12:47:31 UDP link remote: [AF_INET]104.247.234.133:1194

and

journalctl -r --identifier openvpn

Code:

-- Journal begins at Wed 2021-07-14 21:50:20 EDT, ends at Sun 2021-11-21 12:40:22 EST. --
Nov 21 12:39:19 zika openvpn[16473]: Initialization Sequence Completed
Nov 21 12:39:19 zika openvpn[16473]: IFCONFIG POOL LIST
Nov 21 12:39:19 zika openvpn[16473]: IFCONFIG POOL IPv4: base=10.8.0.2 size=252
Nov 21 12:39:19 zika openvpn[16473]: MULTI: multi_init called, r=256 v=256
Nov 21 12:39:19 zika openvpn[16473]: UID set to nobody
Nov 21 12:39:19 zika openvpn[16473]: GID set to nogroup
Nov 21 12:39:19 zika openvpn[16473]: UDPv4 link remote: [AF_UNSPEC]
Nov 21 12:39:19 zika openvpn[16473]: UDPv4 link local (bound): [AF_INET]192.168.1.4:1194
Nov 21 12:39:19 zika openvpn[16473]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Nov 21 12:39:19 zika openvpn[16473]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Nov 21 12:39:19 zika openvpn[16473]: net_addr_v4_add: 10.8.0.1/24 dev tun0
Nov 21 12:39:19 zika openvpn[16473]: net_iface_up: set tun0 up
Nov 21 12:39:19 zika openvpn[16473]: net_iface_mtu_set: mtu 1500 for tun0
Nov 21 12:39:19 zika openvpn[16473]: TUN/TAP device tun0 opened
Nov 21 12:39:19 zika openvpn[16473]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Nov 21 12:39:19 zika openvpn[16473]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Nov 21 12:39:19 zika openvpn[16473]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Nov 21 12:39:19 zika openvpn[16473]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Nov 21 12:39:19 zika openvpn[16473]: CRL: loaded 1 CRLs from file crl.pem
Nov 21 12:39:19 zika openvpn[16473]: Diffie-Hellman initialized with 2048 bit key
Nov 21 12:39:19 zika openvpn[16473]: NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be awar>
Nov 21 12:39:19 zika openvpn[16473]: net_route_v4_best_gw result: via 192.168.1.1 dev enp4s0
Nov 21 12:39:19 zika openvpn[16473]: net_route_v4_best_gw query: dst 0.0.0.0
Nov 21 12:39:19 zika openvpn[16473]: library versions: OpenSSL 1.1.1l  24 Aug 2021, LZO 2.10
Nov 21 12:39:19 zika openvpn[16473]: OpenVPN 2.5.1 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD]>
Nov 21 12:39:19 zika openvpn[16473]: iphers-fallback 'AES-256-CBC' to silence this warning.
Nov 21 12:39:19 zika openvpn[16473]: DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-12>
Nov 21 12:39:19 zika openvpn[15877]: SIGTERM[hard,] received, process exiting
Nov 21 12:39:19 zika openvpn[15877]: Linux can't del IP from iface tun0
Nov 21 12:39:19 zika openvpn[15877]: sitnl_send: rtnl: generic error (-1): Operation not permitted
Nov 21 12:39:19 zika openvpn[15877]: net_addr_v4_del: 10.8.0.1 dev tun0
Nov 21 12:39:19 zika openvpn[15877]: Closing TUN/TAP interface
Nov 21 12:39:17 zika openvpn[15877]: event_wait : Interrupted system call (code=4)