I've been using a GL-AR300M16 for some time and it is especially useful for connecting a bunch of bridged devices over a routed VPN network.
Because I was looking for a bit more horse power to increase download speeds, I was planning to add a Slate 7.
After unboxing it It upgraded to 4.7.3. I uploaded the ovpn files that work on the GL-AR300M16 (4.3.27) to vpn.azure.com (and to a local OpenVPN service), but the status does not change from 'connecting' and the public network is dropped while connecting it.
I double checked to see if it was not the provider that was out, and put the GL-AR300M16 back, and that one connects flawlessly.
I also tried resetting it (reset button and web interface), to no avail.
The log does not provide more information than att'd screenshot.
The OpenVPN issues that I am having are different. The first one that I have where the slate cannot connect to a local OpenVPN server seems to stem from a OpenVPN client that has a more recent version on the Slate as compared to GL-AR300M16. Having struggled with this myself, this is a pain in the *rse when updating the OpenVPN client.
Thu Jun 12 13:53:57 2025 daemon.warn ovpnclient[6665]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Thu Jun 12 13:53:57 2025 daemon.warn ovpnclient[6665]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Thu Jun 12 13:53:57 2025 daemon.notice ovpnclient[6665]: TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:1194
Thu Jun 12 13:53:57 2025 daemon.notice ovpnclient[6665]: Attempting to establish TCP connection with [AF_INET]xx.xx.xx.xx:1194
Thu Jun 12 13:53:57 2025 daemon.notice ovpnclient[6665]: TCP connection established with [AF_INET]xx.xx.xx.xx:1194
Thu Jun 12 13:53:57 2025 daemon.notice ovpnclient[6665]: TCPv4_CLIENT link local: (not bound)
Thu Jun 12 13:53:57 2025 daemon.notice ovpnclient[6665]: TCPv4_CLIENT link remote: [AF_INET]xx.xx.xx.xx:1194
Thu Jun 12 13:53:57 2025 daemon.warn ovpnclient[6665]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Jun 12 13:53:57 2025 daemon.err ovpnclient[6665]: VERIFY ERROR: depth=0, error=CA signature digest algorithm too weak: C=TW, ST=Taiwan, L=Taipei, O=Synology Inc., OU=FTP Team, CN=synology.com, [email protected], serial=5492715301283262
Thu Jun 12 13:53:57 2025 daemon.err ovpnclient[6665]: OpenSSL: error:0A000086:SSL routines::certificate verify failed:
Thu Jun 12 13:53:57 2025 daemon.err ovpnclient[6665]: TLS_ERROR: BIO read tls_read_plaintext error
Thu Jun 12 13:53:57 2025 daemon.err ovpnclient[6665]: TLS Error: TLS object -> incoming plaintext read error
Thu Jun 12 13:53:57 2025 daemon.err ovpnclient[6665]: TLS Error: TLS handshake failed
Thu Jun 12 13:53:57 2025 daemon.err ovpnclient[6665]: Fatal TLS error (check_tls_errors_co), restarting
Thu Jun 12 13:53:57 2025 daemon.notice ovpnclient[6665]: SIGHUP[soft,tls-error] received, process restarting
Thu Jun 12 13:53:57 2025 daemon.warn ovpnclient[6665]: 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.
Thu Jun 12 13:53:57 2025 daemon.warn ovpnclient[6665]: 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.
Thu Jun 12 13:53:57 2025 daemon.notice ovpnclient[6665]: OpenVPN 2.6.12 aarch64-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] [DCO]
Thu Jun 12 13:53:57 2025 daemon.notice ovpnclient[6665]: library versions: OpenSSL 3.0.13 30 Jan 2024, LZO 2.10
Thu Jun 12 13:53:57 2025 daemon.notice ovpnclient[6665]: DCO version: N/A
Thu Jun 12 14:39:39 2025 daemon.info glc: (ovpnclient.c:1758) ===>cmd = cp -a '/tmp/etc/openvpn/profiles/51495/cert' '/tmp/etc/openvpn/profiles/51495/auth' '/etc/openvpn/profiles/51495'
Thu Jun 12 14:39:47 2025 daemon.notice netifd: Interface 'ovpnclient' is setting up now
You mean the Azure one, I'm afraid I cannot do that: that would be a serious breach of security. I can run any test you want me to on the file either on the target using SSH or on a Linux (Debian) system (haven't used Windows in ages).
You can erase all information about keys, authentication, etc., and leave the variable name.
We just would like to check whether the content in the profile is compatible.
The R&D have found the relevant reasons, and the key issue log:
Thu Jun 12 13:53:57 2025 daemon.err ovpnclient[6665]: VERIFY ERROR: depth=0, error=CA signature digest algorithm too weak: C=TW, ST=Taiwan, L=Taipei, O=Synology Inc., OU=FTP Team, CN=synology.com, [email protected], serial=5492715301283262
The server uses SHA1, which cannot meet the default security requirements of higher version OpenVPN. Recommended to upgrade the server root certificate.
Workaround:
ovpn client profile add the following field to allow SHA1 CA: tls-cipher "DEFAULT:@SECLEVEL=0"
@bruce I can confirm that your workaround solves the problem with the Synology OpenVPN. That still leaves the problem with the VPN connection to Azure that does not work on the Slate7.
For the synology VPN connection; your suggestion worked just fine @bruce:
adding did the trick.
tls-cipher "DEFAULT:@SECLEVEL=0"
For the Azure VPN, I'll post the anonymised ovpn file because the solution was staring me right in the face.
This is the ovpn file:
$ cat ~/VPN-Azure-anonymous.ovpn
# For more information, please refer to documentation: https://learn.microsoft.com/en-us/azure/vpn-gateway/point-to-site-vpn-client-certificate-windows-openvpn-client
client
remote wan.some-uuid-like-hostname.vpn.azure.com 443
verify-x509-name wan.some-uuid-like-hostname.vpn.azure.com name
remote-cert-tls server
# For OpenVPN 2.6, please uncomment below
#disable-dco
dev tun
proto tcp
resolv-retry infinite
nobind
auth SHA256
cipher AES-256-GCM
persist-key
persist-tun
tls-timeout 30
tls-version-min 1.2
tls-cipher "DEFAULT:@SECLEVEL=0"
key-direction 1
# For OpenVPN Connect Client 3.x, please comment out the log option below
log openvpn.log
verb 3
# For OpenVPN Connect Client 3.x, to prevent periodic client reconnects due to no traffic being sent to the client, please uncomment below
#ping-restart 0
# P2S CA root certificate
<ca>
-----BEGIN CERTIFICATE-----
<snip>
-----END CERTIFICATE-----
</ca>
# Pre Shared Key
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
<snip>
-----END OpenVPN Static key V1-----
</tls-auth>
# P2S client certificate
# Please fill this field with a PEM formatted client certificate
# Alternatively, configure 'cert PATH_TO_CLIENT_CERT' to use input from a PEM certificate file.
<cert>
-----BEGIN CERTIFICATE-----
<snip>
-----END CERTIFICATE-----
</cert>
# P2S client certificate private key
# Please fill this field with a PEM formatted private key of the client certificate.
# Alternatively, configure 'key PATH_TO_CLIENT_KEY' to use input from a PEM key file.
<key>
-----BEGIN PRIVATE KEY-----
<snip>
-----END PRIVATE KEY-----
</key>
You see, I already added the same tls-cipher, but that did not do anything. Ultimately, I commented out disable-dco and that made the BE3600 connect.
So the OpenVPN between AR300 and BE3600 behaves differently. No surprise there, I've hit similar issues with minor OpenVPN upgrades in our products too...
If I look in the (working) AR300 ovpn configuration exported from the device; that option is missing; so it must have been filtered out during import, while with the BE3600 is probably is not filtered out?
Come to think of it, I imported the exported ovpn too; maybe it's a combination of the suggestion of @bruce and the disable-dco :-/
The mainly issue probably is the server certificate provided by the server is generated using SHA1, it is too weak. When the VPN connection is handshaking, there is error occurred during certificate verification.
Kindly notice, please consider improving the server's algorithm.
