OpenVPN 2.6.10 not connecting to OpenVPN server and not sending any network traffic

[VeeDub]

Hello,

I'm trying to configure a Mikrotik router as an OpenVPN server.

Connecting from Windows 10 using OpenVPN 2.6.10-I001 x64 client.

I used this YouTube video as a guide: https://www.youtube.com/watch?v=pv10...hannel=NETVN82

The video was good, in that it was easy to follow and it covered the exact scenario that I have.

The issue seems to be that the video is a couple of years old and some of the settings in the openvpn.ovpn file appeared to have changed since the video was made.

I've tried to update the config file, but it seems that I haven't done so correctly as the Mikrotik OpenVPN server is not listing any connection attempts from the client and when I perform a packet trace on the client PC there is no traffic being sent to the OpenVPN server.

So I have stuffed up somewhere.

Here is the openvpn.ovpn

client
dev tun
proto udp
remote xx.xx.xx.xx
port 1194
nobind
persist-key
persist-tun
remote-cert-tls server
ca CA.crt
cert ZEN.crt
key ZEN.key
verb 4
mute 10
auth null
cipher AES-256-GCM
data-ciphers AES-256-GCM
auth-user-pass secret
auth-nocache​

Note: I have substituted the public IP address of the OpenVPN server with xx.xx.xx.xx

I have tried proto tcp as well as proto udp.

I have previously used OpenVPN with Untangle and in that implementation, OpenVPN uses UDP. I'm happy to use TCP if that is going to be easier to deploy.

Here is the log from the client

2024-03-22 11:01:17 us=453000 Current Parameter Settings:
2024-03-22 11:01:17 us=453000   config = 'openvpn.ovpn'
2024-03-22 11:01:17 us=453000   mode = 0
2024-03-22 11:01:17 us=453000 NOTE: --mute triggered...
2024-03-22 11:01:17 us=453000 302 variation(s) on previous 10 message(s) suppressed by --mute
2024-03-22 11:01:17 us=453000 OpenVPN 2.6.10 [git:v2.6.10/ba0f62fb950c56a0] Windows [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Mar 20 2024
2024-03-22 11:01:17 us=453000 Windows version 10.0 (Windows 10 or greater), amd64 executable
2024-03-22 11:01:17 us=453000 library versions: OpenSSL 3.2.1 30 Jan 2024, LZO 2.10
2024-03-22 11:01:17 us=453000 DCO version: 1.0.1
2024-03-22 11:01:17 us=453000 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
2024-03-22 11:01:17 us=453000 Need hold release from management interface, waiting...
2024-03-22 11:01:17 us=671000 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:17745
2024-03-22 11:01:17 us=781000 MANAGEMENT: CMD 'state on'
2024-03-22 11:01:17 us=781000 MANAGEMENT: CMD 'log on all'
2024-03-22 11:01:17 us=812000 MANAGEMENT: CMD 'echo on all'
2024-03-22 11:01:17 us=828000 NOTE: --mute triggered...
2024-03-22 11:01:23 us=937000 5 variation(s) on previous 10 message(s) suppressed by --mute
2024-03-22 11:01:23 us=937000 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
2024-03-22 11:01:23 us=937000 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
2024-03-22 11:01:23 us=937000 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:1194
2024-03-22 11:01:23 us=953000 ovpn-dco device [OpenVPN Data Channel Offload] opened
2024-03-22 11:01:23 us=953000 UDP link local: (not bound)
2024-03-22 11:01:23 us=953000 UDP link remote: [AF_INET]xx.xx.xx.xx:1194
2024-03-22 11:01:23 us=953000 MANAGEMENT: >STATE:1711065683,WAIT,,,,,,
2024-03-22 11:02:23 us=734000 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2024-03-22 11:02:23 us=734000 TLS Error: TLS handshake failed
2024-03-22 11:02:23 us=734000 Closing DCO interface
2024-03-22 11:02:23 us=734000 SIGUSR1[soft,tls-error] received, process restarting
2024-03-22 11:02:23 us=734000 MANAGEMENT: >STATE:1711065743,RECONNECTING,tls-error,,,,,
2024-03-22 11:02:23 us=734000 Restart pause, 1 second(s)
2024-03-22 11:02:24 us=750000 Re-using SSL/TLS context
2024-03-22 11:02:24 us=750000 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
2024-03-22 11:02:24 us=750000 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
2024-03-22 11:02:24 us=750000 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:1194
2024-03-22 11:02:24 us=750000 ovpn-dco device [OpenVPN Data Channel Offload] opened
2024-03-22 11:02:24 us=750000 UDP link local: (not bound)
2024-03-22 11:02:24 us=750000 UDP link remote: [AF_INET]xx.xx.xx.xx:1194
2024-03-22 11:02:24 us=750000 MANAGEMENT: >STATE:1711065744,WAIT,,,,,,
2024-03-22 11:02:27 us=750000 Closing DCO interface
2024-03-22 11:02:27 us=750000 SIGTERM[hard,] received, process exiting
2024-03-22 11:02:27 us=750000 MANAGEMENT: >STATE:1711065747,EXITING,SIGTERM,,,,,
​

Would appreciate suggestions on what to try next.

I was searching around on what is now apparently the old forums, if there is a post that has the configuration that I need, if you can provide a link to that then I will probably be able to follow that.

I have a feeling that I am probably fairly close to a working config as the YouTube video was good. It is just that some important detail has changed and I'm not familiar enough with OpenVPN to be able to identify what it is.

Thanks

VW

[openvpn_inc]

Hi VW,

The error says that the client is simply not reaching the server. Perhaps the --remote or the --port (or --proto, as you tried) settings are wrong?

It might also be an issue with Mikrotik. Have you looked for a forum for them?

Regards and good luck, rob0

[VeeDub]

Hello rob0,

The issue is definitely with the OpenVPN client.

I have performed a packet trace when OpenVPN is trying to connect and it isn't sending any network traffic to the OpenVPN server.

The remote is configured to public IP address of the OpenVPN server, which the client PC can ping

Port should be 1194

Proto I've tried both tcp and udp.

The issue is not those settings, even if the settings are wrong, the client should still be sending network traffic.

The issue at the moment is that the client is not sending _any_ network traffic.

Thanks

VW

[Pippin]

Hi,

According the client log you posted it seems to send traffic.
As @rob0 (@openvpn_inc) already stated, it seems the traffic is not reaching the server.
Check the interface being captured.

You should see encrypted traffic on the outgoing interface and unencrypted traffic on the tun interface.
This diagram might help:
HowPacketsFlow

[VeeDub]

Hello,

When the OpenVPN client is trying to connect to the OpenVPN server.

Is it normal for the OpenVPN network adapters to have a status of unplugged?

I took this screenshot while the OpenVPN client was trying to connect.

I have also performed packet capture on each interface while trying to connect and there is no traffic being captured.

It does seem that the OpenVPN client is somehow broken on this PC.



Suggested next steps?

Either that or the openvpn.ovpn configuration has a setting that is effectively killing the client.

[VeeDub]

Hello,

This computer has Hyper-V role installed and thus a Hyper-V virtual switch could that be the issue?

[VeeDub]

Hello,

I have installed the client on another PC which has has W10 freshly installed with all Windows Updates and same behaviour.

A packet trace on any OpenVPN adapter captures NIL traffic.

So there must be an issue with the openvpn.ovpn file.

There is a lot of documentation, but I am having trouble finding an example of an openvpn.ovpn file that I could compare to my current config.

Thanks

VW

[VeeDub]

Hello,

I used an Untangle OpenVPN configuration file as a template. Basically just seemed to change the order of many of the entries and now the packet trace is capturing packets.

I'll work on troubleshooting from here.

[openvpn_inc]

Hello,

When the OpenVPN client is trying to connect to the OpenVPN server.

Is it normal for the OpenVPN network adapters to have a status of unplugged?

I took this screenshot while the OpenVPN client was trying to connect.

Hi VW,

That should be normal, yes. The status would change to connected only after the tunnel is successfully established.

Regards, rob0