My client1.ovpn don't work on my computer, but OK on mobil

[xlarge]

It used to be "piece of cake" (easy) to install a new client1.ovpn file, but this time I had several problems. On my android mobil it demanded a newer ovenovp - which worked OK, but on my computer the same solution failed. I have checked the new client1 file against the old and there is some small differences: The two lines about chipers!

I enclose these (client0 is the old) and also the popup with red warnings and the client1.log and a small popup about "not started" when i start Openvpn Gui (which seems to start anyway).

I have installed the new openvpn on my computer.

Hope this forum can help me.

 

[RMerlin]

I can't understand that language, but it seems like a permission issue. Uninstall then reinstall OpenVPN on your PC, making sure to also install the services as well (otherwise, you would need to run OpenVPN GUI as an administrator).

 

[xlarge]

Thanks RMerling, I give it a try (later this evening as the clock is dinner-time here in Norway).

 

[eibgrad]

What I can see from those logs is that in the case of Windows, it appears you used the OpenVPN Connect app, and it was unable to add the routes once the connection was established. That usually means you didn't run the OpenVPN Connect app w/ administrative privileges. Adding routes is a privileged operation.

Also, I don't recommend using the well-known port 1194 for the server port. Better to use a more obscure port (e.g., 21455). Otherwise hackers will likely hammer port 1194 hoping to get in via brute force.

 

[RMerlin]

Also, I don't recommend using the well-known port 1194 for the server port. Better to use a more obscure port (e.g., 21455). Otherwise hackers will likely hammer port 1194 hoping to get in via brute force.

And to add to this, this is even worse than just getting hammered. I had a customer who would randomly be unable to connect over OpenVPN, and I couldn't figure out why. Until I noticed the server had a limit of like 100 concurrent connections, and bots were taking all 100 slots up. OpenVPN considered "active client" anything that connected to the port, even before it authenticated... I had to move them to a different port to resolve the issue. But that one sure was a headscratcher for me to figure out.

 

[xlarge]

Thanks, now I have uninstalled and reinstalled openvpn on my computer. Managed to establish openvpn contact and able to watch my webcamera remote, but the client1.log show som problems with "cipher" and "BF-CBC" (I don't know what this is). Here is the first lines of the log:

2022-06-18 09:56:41 Note: Treating option '--ncp-ciphers' as '--data-ciphers' (renamed in OpenVPN 2.5).
2022-06-18 09:56:41 --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2022-06-18 09:56:41 OpenVPN 2.5.5 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec 15 2021
2022-06-18 09:56:41 Windows version 10.0 (Windows 10 or greater) 64bit
2022-06-18 09:56:41 library versions: OpenSSL 1.1.1l 24 Aug 2021, LZO 2.10
2022-06-18 09:56:44 TCP/UDP: Preserving recently used remote address: [AF_INET]91.xxx.xx.xxx:1xxxx
2022-06-18 09:56:44 UDP link local: (not bound)
2022-06-18 09:56:44 UDP link remote: [AF_INET]91.xxx.xx.xxx:1xxxx
2022-06-18 09:56:45 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541', remote='link-mtu 1557'

The last line also show a problem.

What can fix these problems?

 

[ColinTaylor]

What can fix these problems?

They're not "problems", they're just informational messages. Ignore them.

 

[xlarge]

Hi Colin, Sorry but not so easy. On my iphone the connection fail because of ciphers and on my computer video from my webcamera remote has stop and miss parts. The last one seems to have something with last line link-mtu which should be consistent and lower than 1500. I don't know how and where to change it.

 

[ColinTaylor]

As I said, they're normal informational messages. What error message are you getting on the client or the server that causes the connection to fail?

 

[xlarge]

On my ipad this message (popup): Authenticantion Failed. Data channel cipher negotiation failed (no shared cipher).
On the computer: client1.log:
Note: Treating option '--ncp-ciphers' as '--data-ciphers' (renamed in OpenVPN 2.5).
2022-06-18 18:11:37 --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
also
WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541', remote='link-mtu 1557'
and below
IPv4 MTU set to 1500 on interface 24 using service

I begin to think that my asus router wrt-merlin last update not use the same Openvpn 2.5.5 and I should go back to Openvpn 2.4.12 on my computer to avoid the cipher-problem or use cipher AES-256-GCM mentioned here https://forums.openvpn.net/viewtopic.php?f=33&t=29440

And the https://serverfault.com/questions/9...u-are-used-inconsistently-warnings-in-openvpn show a solution for link-mtu which just now destroy videos from my webcamera.

 

[RMerlin]

The cipher warning simply indicates that the legacy cipher is not configured. This will only affect people using a very old (like 2.2 or 2.3) OpenVPN client, since anything newer will use the cipher negotiation mechanism (NCP). I do not set it in the exported client file because it's a deprecated setting.

Asuswrt-Merlin always uses the latest OpenVPN release available at the time. 386.5_2 uses OpenVPN 2.5.6, and 386.7 will use 2.5.7. The exported config is formatted so it can be used by both 2.4.x and 2.5.x clients, hence it may generate a few additional warnings with 2.5. This is intended, as exporting a config file specific to 2.5 would break backward compatibility with 2.4 clients.

 

[xlarge]

Thank you very much, RMerlin.
Recommend you me to remove the line
ncp-ciphers CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
from the client1.ovpn?

From my last post: On my ipad this message (popup): Authenticantion Failed. Data channel cipher negotiation failed (no shared cipher). Will removing the line ncp-ciphers fix also this problem (it is a problem as it stop opening the connection).

 

[RMerlin]

Recommend you me to remove the line
ncp-ciphers CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
from the client1.ovpn?

No, do not remove this line. This is what selects the cipher to use since 2.4, instead of the old deprecated --cipher parameter.

 

[xlarge]

Thanks, RMerlin.

I still have not solved the mtu-problem.
Here is part of the client1.ovpn:
dev tun
proto udp
tun-mtu 1500
mssfix 1410
And here is the client1.log korresponding lines:
WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1410', remote='link-mtu 1557'
IPv4 MTU set to 1500 on interface 2 using service

I have used ping:
ping -f 192.168.1.1 -1 1500 - result no good
ping -f 192.168.1.1 -1 1470 - result OK

Comments? Suggestions?

 

[ColinTaylor]

I still have not solved the mtu-problem.

For the third time, this is not a problem. Ignore it.

 

[xlarge]

Hi Colin.
I just fixed openvpn on my ipad. Uninstalled and reinstalled openvpn connect worked.
OK. Thanks. Bye for now