"Cipher aes-128-cbc not supported" but VPN supports it

Installing and Using OpenWrt
1

I have some old TP-Link TL-WR841N/ND revision 11 routers that I really want to reuse as VPN routers and really don't need much from them, would be crazy to throw them away. I found some older versions that include openvpn for this router (LEDE 17.01.6 r3979 and 17.01.7 r4030) but I'm having some issues connecting to my VPN provider with it (all config files are known good and tested on other routers so seems unlikely there's an issue here but I'm getting "Cipher aes-128-cbc not supported" message in system logs)

I can connect fine from other newer routers using this exact same config file and using aes-128-cbc so aes-128-cbc certainly is supported although I've noticed it gives this in a loop even when not connected to internet so maybe there's a strange setting that needs changing in these old versions?

From system logs:

Fri Dec  3 21:18:16 2021 daemon.notice openvpn(VPNclient)[10693]: OpenVPN 2.4.4 mips-openwrt-linux-gnu [SSL (mbed TLS)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Fri Dec  3 21:18:16 2021 daemon.notice openvpn(VPNclient)[10693]: library versions: mbed TLS 2.7.10, LZO 2.10
Fri Dec  3 21:18:16 2021 daemon.err openvpn(VPNclient)[10693]: Cipher aes-128-cbc not supported
Fri Dec  3 21:18:16 2021 daemon.notice openvpn(VPNclient)[10693]: Exiting due to fatal error

I followed "OpenVPN Client for HH5A v1.1j.pdf" guide (except steps for installing openvpn of course as it's already installed) which guides through step by step for LEDE 17 and seems to be well regarded as a reliable setup 'how to' across any LEDE 17 device, everything seemed to go fine (although now I've upgraded to 17.01.7 r4030 I've just noticed on final step where press save and apply on OpenVPN instances page it highlights the line with empty box under the VPNclient3 entry (line with apply button on it) and states "Invalid" - not sure why as every step has been followed and no mention of needing to do anything with this box).

login info was added to userpass.txt and saved in /etc/openvpn with WinSCP along with my PIA-us-texas.ovpn PIA VPN file, openvpn file for 1st VPN was changed to option config '/etc/openvpn/PIA-us-texas.ovpn' and saved in /etc/config as well of course

Below is shortened PIA-us-texas.ovpn file if there are any extra settings needed/anything specifically needs removing or changing...

client
dev tun
proto udp
remote us-texas.privacy.network 1198
resolv-retry infinite
nobind
persist-key
persist-tun

<ca>
-----BEGIN CERTIFICATE-----
MIIFqz...RiU (shortened)
-----END CERTIFICATE-----
</ca>

cipher aes-128-cbc
auth sha1
tls-client
remote-cert-tls server
auth-user-pass /etc/openvpn/userpass.txt
comp-lzo no
verb 1
reneg-sec 0

Note: I removed X509 section from this file as my other routers refused to connect with it in, have also tried with below version straight from PIA (only changed auth-user-pass line) but same results

client
dev tun
proto udp
remote us-texas.privacy.network 1198
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-128-cbc
auth sha1
tls-client
remote-cert-tls server

auth-user-pass /etc/openvpn/userpass.txt

compress
verb 1
reneg-sec 0
<crl-verify>
-----BEGIN X509 CRL-----
MIIC...A== (shortened)
-----END X509 CRL-----
</crl-verify>

<ca>
-----BEGIN CERTIFICATE-----
MIIF...RiU (shortened)
-----END CERTIFICATE-----
</ca>

disable-occ

If this is a simple config error would really appreciate knowing what went wrong and needs to be changed for this to work. I've followed everything in the guide exactly as stated so seems very odd, only sections skipped were openvpn install as it is already installed and the 'Modem-router Owners' section as this device has no modem.

thanks

2

Unfortunately, both the device, and the firmware, are no longer supported for OpenWRT.

3

hi, I realise it's not going to get any new features etc and they did well to fit Luci and openvpn within 4MB but that should not stop it working, I have routers with older Luci (eg my GL.iNet GL-AR300M, apparently back in December 2018 they were shipping with 17.01.4 and I've owned it a lot longer than that without updating it so will be even older, works perfectly with same OVPN file I copied here).

Starting to think there is something missing from that guide that's somehow needed, not sure what though. Does anyone else have a basic step by step guide I can try so impossible for any needed step to be missed and I'll reset router and retry?

thanks

4

If your client doesn't support at least one of the ciphers that the server is configured to use, connection is not possible. Most services are refusing to use old ciphers or even connect to old versions of OpenVPN client.

1 Like
5

Hi,
I actually just worked out what the problem was and was a ridiculous reason, spent ages messing about on something I can't understand why it couldn't handle since older versions can.

Was as simple as changing to capital letters, the connect settings can be exactly the same as I listed above except must be:

cipher AES-128-CBC
auth SHA1

instead of

cipher aes-128-cbc
auth sha1

Absolutely crazy, unfortunately the (admitedly rather optimistic looking) 12mbps speeds mentioned here for AES-128-CBC on a V8 do look to be wildly out vs real world (on my V11 which has higher clock speed and same manufacturer for soc, usually get faster the newer they get!), struggling to get much past 4mbps to 6mbps range and usually hovering around the low end of that range. I'll retry at different time of day but usually get very close to my internet max speed with this VPN location/config on faster hardware... Only really need 7-8mbps so hoped would handle that OK but not looking great so far. That said my GL.iNet GL-AR300M uses a 650mhz Qualcomm Atheros QCA9531 and can easily achieve 8-10mbps and this TL-WR841N rev11 uses a 650mhz Qualcomm Atheros QCA9533 - they should be able to manage very similar speeds. Maybe I need to try out some older builds and see which gives closer to what it should be able to handle.

Edit: maybe more of an issue with the 3 different speed test sites I tried (and 5 different servers between them), just tried a file download and is peaking at just over 1MB/s so not bad. Needs testing with a proper workload when it's not nearly 2AM, time for bed.

This is also where they handily suggested using caps:

Hopefully this saves someone else a few hours of going round in circles because it stupidly doesn't like lower case letters all of a sudden...

6

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.