sudo openvpn --config client.conf
2023-07-26 17:02:18 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.
2023-07-26 17:02:18 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
2023-07-26 17:02:18 WARNING: file '/mnt/vpn/client1.key' is group or others accessible
2023-07-26 17:02:18 OpenVPN 2.6.3 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
2023-07-26 17:02:18 library versions: OpenSSL 3.0.8 7 Feb 2023, LZO 2.10
2023-07-26 17:02:18 DCO version: N/A
2023-07-26 17:02:18 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.1.1:1194
2023-07-26 17:02:18 UDPv4 link local: (not bound)
2023-07-26 17:02:18 UDPv4 link remote: [AF_INET]192.168.1.1:1194
2023-07-26 17:03:18 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Note that firewall is disabled in the server
my /etc/openvpn/server.conf
#change with your port
port 1194
#You can use udp or tcp
proto udp4
# "dev tun" will create a routed IP tunnel.
dev tun
topology subnet
#Certificate Configuration
#ca certificate
ca /etc/easy-rsa/pki/ca.crt
#Server Certificate
cert /etc/easy-rsa/pki/issued/server.crt
#Server Key and keep this is secret
#askpass /etc/easy-rsa/pki/private/server.pass
key /etc/easy-rsa/pki/private/server.key
#See the size a dh key in /etc/openvpn/keys/
#dh /etc/easy-rsa/empty
dh none
tls-server
#Internal IP will get when already connect
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
#server-ipv6 2001:0db8:ee00:abcd::/64
#tun-ipv6
#push tun-ipv6
#ifconfig-ipv6 2001:0db8:ee00:abcd::1 2001:0db8:ee00:abcd::2
#push "route-ipv6 2001:0db8:ee00:ee00::2/64"
#push "route-ipv6 2000::/3"
#this line will redirect all traffic through our OpenVPN
push "redirect-gateway def1"
push "route 192.168.0.0 255.255.255.0"
#Provide DNS servers to the client, you can use goolge DNS
push "dhcp-option DNS 1.1.1.1"
#push "dhcp-option DNS 8.8.4.4"
#Enable multiple client to connect with same key
duplicate-cn
cipher AES-256-CBC
keepalive 20 60
script-security 3
comp-lzo
persist-key
persist-tun
daemon
#openvpn status log
#status /var/log/openvpn/openvpn-status.log
#enable log
#log-append /var/log/openvpn/openvpn.log
#Log Level
verb 3
my client.conf
client
remote 192.168.1.1 1194
ca "/mnt/vpn/ca.crt"
cert "/mnt/vpn/client1.crt"
key "/mnt/vpn/client1.key"
comp-lzo yes
cipher AES-256-CBC
dev tun
proto udp
nobind
auth-nocache
script-security 2
persist-key
remote-cert-tls server
Can you connect to port 1194 on the server? It’s a UDP connection, so I would be inclined to use:
sudo nmap -sU -p 1194 192.168.1.1
That address looks like it might be a router or default gateway address; if it is, you’ll want to make sure that it’s forwarding for UDP on that port to the VPN server’s address. If it is directly the VPN server’s address, then something else is blocking the port (you’ve said a couple times that the firewall is disabled, but how the VPN server is set up will make a difference as well - if you’re using, for example, a Docker image, then you need to make sure the port is exposed as well).
If the nmap command comes back saying the port is closed, then that would explain the timeout. If it’s open/filtered (as mine is on my test system), then something’s listening - on the server, you can run:
That proved first because MicroOS is a hell to install packages.
Running nmap from the computer form where I am ssh into the homeserver that is running openvpn I get
sudo nmap -sU -p 1194 192.168.1.1
[sudo] Passwort für root:
Starting Nmap 7.92 ( https://nmap.org ) at 2023-07-26 17:11 CST
Nmap scan report for 192.168.1.1
Host is up (0.0016s latency).
PORT STATE SERVICE
1194/udp open|filtered openvpn
Later respond from the server, since the connection is misteliously slow.
That’s very strange indeed. The nmap and lsof outputs look like I would expect.
Where is MicroOS in this setup? Just looking to get a firm picture of how things are set up.
Are you seeing any other performance issues with connecting to the server? Something like ssh, or using scp to copy a large file to the server?
I would also probably run Wireshark on the client and capture the traffic to see if there’s anything unexpected on the network connection - if there’s lots of retransmissions or errors in the traffic related to openvpn, that might be indicative of something else going on.
open|filtered for UDP scan means there was no response from the target to the probe packet, so nmap simply does not know whether port is opened or closed. So this output does not prove anything and it is still uknown whether the server can receive packets on this port from the client.
I would simply capture traffic on both sides. Or try TCP for a start.
sudo /home/linuxbrew/.linuxbrew/bin/nmap -sU -p 1194 192.168.1.1
Starting Nmap 7.94 ( https://nmap.org ) at 2023-07-27 04:22 UTC
Nmap scan report for homeserver (192.168.1.1)
Host is up.
PORT STATE SERVICE
1194/udp open|filtered openvpn
Yes, of course I do. It means that the port is not definitively closed. Given that he’s not running a firewall and it’s on the local network, that means there is something listening on the port.
A response for a closed port would look like this:
PORT STATE SERVICE
1194/udp closed openvpn
I tested this myself on my own network. While you are technically correct that it doesn’t guarantee that there’s a listener, in this particular instance, it’s a positive sign.
I’ve not spent 3 decades troubleshooting network issues without learning a few things along the way, including the differences between TCP and UDP - or how to narrow a problem down.
Yes, changing to TCP is a good option, or doing a capture. Had the port explicitly shown as closed, that would have indicated a different path.
That is why I would do a packet trace next - as well as the other things I suggested (copy large file to/from the server with scp, check for performance issues with SSH).
If you’re not familiar with using Wireshark for network diagnosis, that’s OK - you can start a capture and then just look for lots of errors in the trace itself while connecting to the network. From what you describe, it’s possible that you’ll see lots of retransmissions.
As @arvidjaar suggested, you might also change to using TCP - that will give you a more reliable connection (TCP is guaranteed delivery, UDP is not). I personally prefer using TCP for a VPN connection because it is easier to diagnose if there are issues.
I do think this is no connection error and the tests done also point that way.
I would call this a protocol error and I suggest to try to connect adding “–verb 5” and “–verb 7”
Would not surprise me if it has to do with:
DEPRECATED OPTION: --cipher set to ‘AES-256-CBC’ but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations
Can you try:
removing cipher AES-256-CBC from your client,conf file, what kind of logging do you get running with that?
keep your client.conf as is but add --data-ciphers AES-256-CBC
If TCP solves it, then it sounds like it’s probably something network related - I would go beyond using tcpdump and use Wireshark (you can use tcpdump to grab the pcap file and use Wireshark to view it) so you can see what’s going on on the network.
It does seem strange that the responses from your server are coming from a different IP address - what happens if you connect the client to 192.168.1.65 instead?
