The VPN connection failed because the connection attempt timed out

lattimro · 11-21-2021, 12:05 PM

Quote:

Originally Posted by wpeckham

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.

my host is also 192.168.1.4
My expectation was because I used again external IP (ISP) to be 104 but is not. The VPN server run on local host on the same IP: 192.168.1.4:1194 and the virtual server on 10.8.0.0/24

this is server.conf:

Quote:

local 192.168.1.4
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 1.0.0.1"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify

client.conf:

Code:

client
dev tun
proto udp
remote                1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3

lattimro · 11-21-2021, 12:13 PM

Quote:

Originally Posted by wpeckham

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.)

I hope that helps.

The VPN server because is running on the localhost has the same IP: 192.168.1.4 don't know if that make sense. The client has the same 192.168.1.4

route:

Code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         ControlPanel.Ho 0.0.0.0         UG    100    0        0 enp4s0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp4s0
192.168.1.0     0.0.0.0         255.255.255.0   U     100    0        0 enp4s0

btw I think 169.254.0.0 coming from AVAHI

wpeckham · 11-21-2021, 02:35 PM

I see now.
The guests do not have their own unique IP addresses, so you must be using some kind of NAT or shared networking instead of bridged. That presents extra issues that would not otherwise exist. I am unsure how your would expose the port on teh guest to listen effectively on the IP address of the host. I am not sure I can provide any other help than "I would not have done it that way", which is not very helpful.

lattimro · 11-21-2021, 04:57 PM

Quote:

Originally Posted by wpeckham

I see now.
The guests do not have their own unique IP addresses, so you must be using some kind of NAT or shared networking instead of bridged.

some guests have their own unique address, the only guest who has not is the localhost where the server run.

Quote:

Originally Posted by wpeckham

That presents extra issues that would not otherwise exist. I am unsure how your would expose the port on teh guest to listen effectively on the IP address of the host.

I exposed the the VPN server (localhost) 192.168.1.4:1194 (not the guest) to the client (guest)

some confusion

Quote:

Originally Posted by wpeckham

I am not sure I can provide any other help than "I would not have done it that way", which is not very helpful.

I would not done it that way if other ways were have been available but so far I am following this and the one in OP.

new stuff: I forwarded the port in the router and VPN works, I mean no timeout. Now the challenge is how to check and use the tunnel?
The test will be to show my public IP other than this:

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

Code:

"104..."

I assume should be 10.8.0.1 if my understanding is good but I am getting this:

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

Code:

;; connection timed out; no servers could be reached

Thank you

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

connected

michaelk · 11-21-2021, 05:30 PM

I missed your last post that you are connected. But can you actually ping the server through its 10.8.0.0 address.

169.254.0.0 is a backup to assign an IP address just in case no dhcp servers are found. As far as I know it should not effect anything openvpn.

I have never tried using the same PC as client and server so not sure what will happen. I use VirtualBox virtual machines for test beds.

I should of warned you earlier to obfuscate your public IP address. Its already out to the public now but I would do it anyway.

Since your public IP is in your client.conf for remote that is what openvpn client will use as the server address. Did you permanently set net.ipv4.ip_forward in your sysctl.conf or just via /proc. You need to set it in sysctl.conf for it to be configured at boot time. You might have to add some iptable rules to forward traffic through the tun interface.

sundialsvcs · 11-21-2021, 06:05 PM

Always remember that VPN clients communicate with one another, and with the server, only through the virtual network that is created and then managed by the server. Once you have "joined" the virtual private network, your public IP does not matter.

Clients communicate, from their public IPs, with the server at its public IP, but only in order to connect to it. (They customarily use the "UDP" protocol to do so.) However, once they have done so, they are able to enjoy "TCP/IP" communication among themselves in their little private world.

Since "10.8.x.x" packets might easily appear on a local network, each local network's router must know to forward them to the local OpenVPN server process "as a gateway" – unless the router has OpenVPN support of its own.

computersavvy · 11-21-2021, 06:07 PM

I see this repeatedly in what you post.

Code:

DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-12>

My first inclination would be to fix that.

If it cannot negotiate a suitable cipher then it can never connect.

lattimro · 11-22-2021, 07:22 AM

Quote:

Originally Posted by computersavvy

I see this repeatedly in what you post.

Code:

DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-12>

My first inclination would be to fix that.

If it cannot negotiate a suitable cipher then it can never connect.

I don't know if I can fix that but I can silence it

Code:

2021-11-22 08:26:49 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-22 08:26:49 library versions: OpenSSL 1.1.1l  24 Aug 2021, LZO 2.10
2021-11-22 08:26:49 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2021-11-22 08:26:49 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2021-11-22 08:26:49 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2021-11-22 08:26:49 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2021-11-22 08:26:49 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.1.4:1194
2021-11-22 08:26:49 Socket Buffers: R=[212992->212992] S=[212992->212992]
2021-11-22 08:26:49 UDP link local: (not bound)
2021-11-22 08:26:49 UDP link remote: [AF_INET]192.168.1.4:1194
2021-11-22 08:26:49 TLS: Initial packet from [AF_INET]192.168.1.4:1194, sid=dd3f0730 a8482051
2021-11-22 08:26:49 VERIFY OK: depth=1, CN=ChangeMe
2021-11-22 08:26:49 VERIFY KU OK
2021-11-22 08:26:49 Validating certificate extended key usage
2021-11-22 08:26:49 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2021-11-22 08:26:49 VERIFY EKU OK
2021-11-22 08:26:49 VERIFY OK: depth=0, CN=server
2021-11-22 08:26:49 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
2021-11-22 08:26:49 [server] Peer Connection Initiated with [AF_INET]192.168.1.4:1194
2021-11-22 08:26:50 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 1.1.1.1,dhcp-option DNS 1.0.0.1,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'
2021-11-22 08:26:50 OPTIONS IMPORT: timers and/or timeouts modified
2021-11-22 08:26:50 OPTIONS IMPORT: --ifconfig/up options modified
2021-11-22 08:26:50 OPTIONS IMPORT: route options modified
2021-11-22 08:26:50 OPTIONS IMPORT: route-related options modified
2021-11-22 08:26:50 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2021-11-22 08:26:50 OPTIONS IMPORT: peer-id set
2021-11-22 08:26:50 OPTIONS IMPORT: adjusting link_mtu to 1624
2021-11-22 08:26:50 OPTIONS IMPORT: data channel crypto options modified
2021-11-22 08:26:50 Data Channel: using negotiated cipher 'AES-256-GCM'
2021-11-22 08:26:50 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-11-22 08:26:50 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-11-22 08:26:50 net_route_v4_best_gw query: dst 0.0.0.0
2021-11-22 08:26:50 net_route_v4_best_gw result: via 192.168.1.1 dev enp4s0
2021-11-22 08:26:50 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=enp4s0 HWADDR=64:51:06:a3:5d:8d
2021-11-22 08:26:50 TUN/TAP device tun1 opened
2021-11-22 08:26:50 net_iface_mtu_set: mtu 1500 for tun1
2021-11-22 08:26:50 net_iface_up: set tun1 up
2021-11-22 08:26:50 net_addr_v4_add: 10.8.0.2/24 dev tun1
2021-11-22 08:26:50 net_route_v4_add: 192.168.1.4/32 via 192.168.1.1 dev enp4s0 table 0 metric -1
2021-11-22 08:26:50 net_route_v4_add: 0.0.0.0/1 via 10.8.0.1 dev [NULL] table 0 metric -1
2021-11-22 08:26:50 net_route_v4_add: 128.0.0.0/1 via 10.8.0.1 dev [NULL] table 0 metric -1
2021-11-22 08:26:50 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2021-11-22 08:26:50 Initialization Sequence Completed

sundialsvcs · 11-22-2021, 08:12 AM

You should be able to resolve router problems with OpenVPN fairly easily using a tool like tcpdump or (much better ...) wireshark.

• Make sure that the OpenVPN server is always assigned a predictable internal IP-address based on its MAC number.

• Next, be sure that the firewalls permit UDP traffic to-and-from the appropriate port number.

• Next, make sure that all such UDP traffic for this port, when sent to the router's public IP-address, is forwarded to the OpenVPN server.

• Finally, make sure that all traffic carrying a 10.8.x.x destination IP-address is forwarded to the OpenVPN server "as a gateway."

The last two rules are critical for ensuring that traffic is successfully sent to the OpenVPN server within the network. The first rule handles "inbound," the second, "outbound."

Some hardware routers do (or, can ...) support OpenVPN directly, in which case these admonitions might not apply.

If OpenVPN connections are "timing out," then you know that you have a routing problem somewhere.

lattimro · 11-22-2021, 08:17 AM

Quote:

Originally Posted by michaelk

I missed your last post that you are connected. But can you actually ping the server through its 10.8.0.0 address.

169.254.0.0 is a backup to assign an IP address just in case no dhcp servers are found. As far as I know it should not effect anything openvpn.

I have never tried using the same PC as client and server so not sure what will happen. I use VirtualBox virtual machines for test beds.

I should of warned you earlier to obfuscate your public IP address. Its already out to the public now but I would do it anyway.

Since your public IP is in your client.conf for remote that is what openvpn client will use as the server address. Did you permanently set net.ipv4.ip_forward in your sysctl.conf or just via /proc. You need to set it in sysctl.conf for it to be configured at boot time. You might have to add some iptable rules to forward traffic through the tun interface.

Thanks so much guys, I started to understand a bit how practically works, NO, I did not forward the traffic that is another lesson to learn, so far so good I am glad I can create the tunnel. I do not want to start the client at the boot time only the server if that make sense. Also did not touch iptables yet.
I will next time create the tunnel manually and I will have more flexibility I would think.

So far still get an error and I do not know why:

journalctl -r --identifier openvpn

Code:

- Journal begins at Thu 2021-07-22 07:47:53 EDT, ends at Mon 2021-11-22 08:57:23 EST. --
Nov 22 08:57:23 zika openvpn[66262]: Use --help for more information.
Nov 22 08:57:23 zika openvpn[66262]: Options error: In [CMD-LINE]:1: Error opening configuration file: client.conf
Nov 22 08:57:18 zika openvpn[66259]: Use --help for more information.
Nov 22 08:57:18 zika openvpn[66259]: Options error: In [CMD-LINE]:1: Error opening configuration file: client.conf
Nov 22 08:57:12 zika openvpn[66195]: Use --help for more information.

I think I found where this is coming from:

Code:

systemctl status openvpn-server@client.service
● openvpn-server@client.service - OpenVPN service for client
     Loaded: loaded (/lib/systemd/system/openvpn-server@.service; enabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Mon 2021-11-22 10:21:13 EST; 3s ago
       Docs: man:openvpn(8)
             https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
             https://community.openvpn.net/openvpn/wiki/HOWTO
    Process: 75450 ExecStart=/usr/sbin/openvpn --status /run/openvpn-server/status-client.log --status-version 2 --suppress-timestamps >
   Main PID: 75450 (code=exited, status=1/FAILURE)
        CPU: 60ms

Nov 22 10:21:13 zika systemd[1]: Failed to start OpenVPN service for client.

Code:

systemctl status openvpn-server@client.service
● openvpn-server@client.service - OpenVPN service for client
     Loaded: loaded (/lib/systemd/system/openvpn-server@.service; enabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Mon 2021-11-22 10:24:24 EST; 3s ago
       Docs: man:openvpn(8)
             https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
             https://community.openvpn.net/openvpn/wiki/HOWTO
    Process: 76193 ExecStart=/usr/sbin/openvpn --status /run/openvpn-server/status-client.log --status-version 2 --suppress-timestamps >
   Main PID: 76193 (code=exited, status=1/FAILURE)
        CPU: 88ms

Nov 22 10:24:24 zika systemd[1]: openvpn-server@client.service: Failed with result 'exit-code'.
Nov 22 10:24:24 zika systemd[1]: Failed to start OpenVPN service for client.

but the local client starts OK manually or by systemd

PHP Code:



openvpn@client.service

.

Code:

Nov 22 10:33:28 zika systemd[1]: Starting OpenVPN service for client...
Nov 22 10:33:28 zika openvpn[76773]: Options error: In [CMD-LINE]:1: Error opening configuration file: client.conf
Nov 22 10:33:28 zika openvpn[76773]: Use --help for more information.
Nov 22 10:33:28 zika systemd[1]: openvpn-server@client.service: Main process exited, code=exited, status=1/FAILURE
Nov 22 10:33:28 zika systemd[1]: openvpn-server@client.service: Failed with result 'exit-code'.
Nov 22 10:33:28 zika systemd[1]: Failed to start OpenVPN service for client.
Nov 22 10:33:34 zika systemd[1]: openvpn-server@client.service: Scheduled restart job, restart counter is at 2867.
Nov 22 10:33:34 zika systemd[1]: Stopped OpenVPN service for client.
Nov 22 10:33:34 zika systemd[1]: Starting OpenVPN service for client...
Nov 22 10:33:34 zika openvpn[76776]: Options error: In [CMD-LINE]:1: Error opening configuration file: client.conf
Nov 22 10:33:34 zika openvpn[76776]: Use --help for more information.
Nov 22 10:33:34 zika systemd[1]: openvpn-server@client.service: Main process exited, code=exited, status=1/FAILURE
Nov 22 10:33:34 zika systemd[1]: openvpn-server@client.service: Failed with result 'exit-code'.
Nov 22 10:33:34 zika systemd[1]: Failed to start OpenVPN service for client.
Nov 22 10:33:39 zika systemd[1]: openvpn-server@client.service: Scheduled restart job, restart counter is at 2868.

lattimro · 11-22-2021, 08:58 AM

[QUOTE=sundialsvcs;6303429]You should be able to resolve router problems with OpenVPN fairly easily using a tool like tcpdump or (much better ...) wireshark.[/CODE]

wireshark collects some traffic but for

Code:

tcpdump -v -i tun0 port 1194

there is no output

Quote:

• Make sure that the OpenVPN server is always assigned a predictable internal IP-address based on its MAC number.

what a predictable internal IP-address based on its MAC number is?

Quote:

• Next, be sure that the firewalls permit UDP traffic to-and-from the appropriate port number.

check

Quote:

• Next, make sure that all such UDP traffic for this port, when sent to the router's public IP-address, is forwarded to the OpenVPN server.

• Finally, make sure that all traffic carrying a 10.8.x.x destination IP-address is forwarded to the OpenVPN server "as a gateway."

The last two rules are critical for ensuring that traffic is successfully sent to the OpenVPN server within the network. The first rule handles "inbound," the second, "outbound."

not done yet, is not that done automatically by the install script? I have to check

Quote:

Some hardware routers do (or, can ...) support OpenVPN directly, in which case these admonitions might not apply.

If OpenVPN connections are "timing out," then you know that you have a routing problem somewhere.

is not timing out lately, we are making progress here

lattimro · 11-22-2021, 04:20 PM

this is one client with IP 192.168.1.17. I am still not sure it is connected. it creates a tun0 interface on 10.8.0.3. ping to 10.8.0.1 and 10.8.0.3 OK. But there are no ESTABLISHED between 10.8.0.1 and 10.8.0.3

Code:

16: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.0.3/24 brd 10.8.0.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::af1e:5a84:5ce:bad5/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

root@syeno:/etc/openvpn# netstat -punte

Code:

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name    
tcp        0      0 192.168.1.17:22         192.168.1.4:53164       ESTABLISHED 0          135604     5565/sshd: brad [pr 
tcp        0      0 192.168.1.17:22         192.168.1.4:53166       ESTABLISHED 0          135904     5673/sshd: brad [pr 
udp        0      0 192.168.1.17:68         192.168.1.1:67          ESTABLISHED 0          131204     643/NetworkManager

root@syeno:/etc/openvpn# route

Code:

 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.1        128.0.0.0       UG    0      0        0 tun0
default         ControlPanel.Ho 0.0.0.0         UG    600    0        0 wlp5s0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
128.0.0.0       10.8.0.1        128.0.0.0       UG    0      0        0 tun0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 wlp5s0
192.168.1.0     0.0.0.0         255.255.255.0   U     600    0        0 wlp5s0
zika.gattaca.ne 0.0.0.0         255.255.255.255 UH    0      0        0 wlp5s0

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

Code:

Mon Nov 22 17:10:50 2021 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021
Mon Nov 22 17:10:50 2021 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Mon Nov 22 17:10:50 2021 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Nov 22 17:10:50 2021 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Nov 22 17:10:50 2021 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Nov 22 17:10:50 2021 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Nov 22 17:10:50 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.1.4:1194
Mon Nov 22 17:10:50 2021 Socket Buffers: R=[212992->212992] S=[212992->212992]
Mon Nov 22 17:10:50 2021 UDP link local: (not bound)
Mon Nov 22 17:10:50 2021 UDP link remote: [AF_INET]192.168.1.4:1194
Mon Nov 22 17:10:50 2021 TLS: Initial packet from [AF_INET]192.168.1.4:1194, sid=52327f5d aecb9e10
Mon Nov 22 17:10:51 2021 VERIFY OK: depth=1, CN=ChangeMe
Mon Nov 22 17:10:51 2021 VERIFY KU OK
Mon Nov 22 17:10:51 2021 Validating certificate extended key usage
Mon Nov 22 17:10:51 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mon Nov 22 17:10:51 2021 VERIFY EKU OK
Mon Nov 22 17:10:51 2021 VERIFY OK: depth=0, CN=server
Mon Nov 22 17:10:51 2021 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
Mon Nov 22 17:10:51 2021 [server] Peer Connection Initiated with [AF_INET]192.168.1.4:1194
Mon Nov 22 17:10:52 2021 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Mon Nov 22 17:10:52 2021 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 1.1.1.1,dhcp-option DNS 1.0.0.1,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.3 255.255.255.0,peer-id 1,cipher AES-256-GCM'
Mon Nov 22 17:10:52 2021 OPTIONS IMPORT: timers and/or timeouts modified
Mon Nov 22 17:10:52 2021 OPTIONS IMPORT: --ifconfig/up options modified
Mon Nov 22 17:10:52 2021 OPTIONS IMPORT: route options modified
Mon Nov 22 17:10:52 2021 OPTIONS IMPORT: route-related options modified
Mon Nov 22 17:10:52 2021 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Nov 22 17:10:52 2021 OPTIONS IMPORT: peer-id set
Mon Nov 22 17:10:52 2021 OPTIONS IMPORT: adjusting link_mtu to 1624
Mon Nov 22 17:10:52 2021 OPTIONS IMPORT: data channel crypto options modified
Mon Nov 22 17:10:52 2021 Data Channel: using negotiated cipher 'AES-256-GCM'
Mon Nov 22 17:10:52 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Nov 22 17:10:52 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Nov 22 17:10:52 2021 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=wlp5s0 HWADDR=b4:82:fe:e4:de:a5
Mon Nov 22 17:10:52 2021 TUN/TAP device tun0 opened
Mon Nov 22 17:10:52 2021 TUN/TAP TX queue length set to 100
Mon Nov 22 17:10:52 2021 /sbin/ip link set dev tun0 up mtu 1500
Mon Nov 22 17:10:52 2021 /sbin/ip addr add dev tun0 10.8.0.3/24 broadcast 10.8.0.255
Mon Nov 22 17:10:52 2021 /sbin/ip route add 192.168.1.4/32 dev wlp5s0
Mon Nov 22 17:10:52 2021 /sbin/ip route add 0.0.0.0/1 via 10.8.0.1
Mon Nov 22 17:10:52 2021 /sbin/ip route add 128.0.0.0/1 via 10.8.0.1
Mon Nov 22 17:10:52 2021 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Nov 22 17:10:52 2021 Initialization Sequence Completed

and syslog:

Code:

Nov 22 17:10:50 zika openvpn[9396]: 192.168.1.17:51266 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Nov 22 17:10:50 zika openvpn[9396]: 192.168.1.17:51266 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Nov 22 17:10:50 zika openvpn[9396]: 192.168.1.17:51266 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Nov 22 17:10:50 zika openvpn[9396]: 192.168.1.17:51266 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Nov 22 17:10:50 zika openvpn[9396]: 192.168.1.17:51266 TLS: Initial packet from [AF_INET]192.168.1.17:51266, sid=94caba42 2ffd2fef
Nov 22 17:10:51 zika openvpn[9396]: 192.168.1.17:51266 VERIFY OK: depth=1, CN=ChangeMe
Nov 22 17:10:51 zika openvpn[9396]: 192.168.1.17:51266 VERIFY OK: depth=0, CN=syeno
Nov 22 17:10:51 zika openvpn[9396]: 192.168.1.17:51266 peer info: IV_VER=2.4.7
Nov 22 17:10:51 zika openvpn[9396]: 192.168.1.17:51266 peer info: IV_PLAT=linux
Nov 22 17:10:51 zika openvpn[9396]: 192.168.1.17:51266 peer info: IV_PROTO=2
Nov 22 17:10:51 zika openvpn[9396]: 192.168.1.17:51266 peer info: IV_NCP=2
Nov 22 17:10:51 zika openvpn[9396]: 192.168.1.17:51266 peer info: IV_LZ4=1
Nov 22 17:10:51 zika openvpn[9396]: 192.168.1.17:51266 peer info: IV_LZ4v2=1
Nov 22 17:10:51 zika openvpn[9396]: 192.168.1.17:51266 peer info: IV_LZO=1
Nov 22 17:10:51 zika openvpn[9396]: 192.168.1.17:51266 peer info: IV_COMP_STUB=1
Nov 22 17:10:51 zika openvpn[9396]: 192.168.1.17:51266 peer info: IV_COMP_STUBv2=1
Nov 22 17:10:51 zika openvpn[9396]: 192.168.1.17:51266 peer info: IV_TCPNL=1
Nov 22 17:10:51 zika openvpn[9396]: 192.168.1.17:51266 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
Nov 22 17:10:51 zika openvpn[9396]: 192.168.1.17:51266 [syeno] Peer Connection Initiated with [AF_INET]192.168.1.17:51266
Nov 22 17:10:51 zika openvpn[9396]: MULTI: new connection by client 'syeno' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
Nov 22 17:10:51 zika openvpn[9396]: MULTI_sva: pool returned IPv4=10.8.0.3, IPv6=(Not enabled)
Nov 22 17:10:51 zika openvpn[9396]: MULTI: Learn: 10.8.0.3 -> syeno/192.168.1.17:51266
Nov 22 17:10:51 zika openvpn[9396]: MULTI: primary virtual IP for syeno/192.168.1.17:51266: 10.8.0.3
Nov 22 17:10:51 zika openvpn[9396]: Data Channel: using negotiated cipher 'AES-256-GCM'
Nov 22 17:10:51 zika openvpn[9396]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Nov 22 17:10:51 zika openvpn[9396]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Nov 22 17:10:51 zika openvpn[9396]: syeno/192.168.1.17:51266 PUSH: Received control message: 'PUSH_REQUEST'
Nov 22 17:10:51 zika openvpn[9396]: syeno/192.168.1.17:51266 SENT CONTROL [syeno]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 1.1.1.1,dhcp-option DNS 1.0.0.1,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.3 255.255.255.0,peer-id 1,cipher AES-256-GCM' (status=1)

sundialsvcs · 11-22-2021, 07:08 PM

When you turn on your computer, it issues a so-called "DHCP" request asking to be assigned an internal IP-address ... 192.168.x.x ...

Ordinarily this is random and ordinarily you don't care, but when you are setting up an OpenVPN server (to be used by others), then you do want the IP address to be the same every time so that your routing rules can reference it.

You will set this up on the administrative control-panel of your router.

michaelk · 11-22-2021, 08:11 PM

Is the 192.168.1.17 a different physical or virtual machine from the server?

Now days most DHCP implementations will try to assign the same IP address so even though I don't have a reservation in my router all of my devices always have the same address.

Code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.1        128.0.0.0       UG    0      0        0 tun0
default         ControlPanel.Ho 0.0.0.0         UG    600    0        0 wlp5s0

Since the metric is lower for tun0 then wlp5s0 traffic should be routed through the openvpn tunnel. Since you can ping over the 10.8.0.0 I would guess its working. On the same PC it would be hard to tell.