OpenVPN versions and ciphers problem connecting to Tomato router at home

I’m trying to VPN into my home router running Tomato from my SFOS xperia 10 II. I generated an OpenVPN config + certificates and keys on the router. The ovpn file warns that it’s for openvpn versions 2.4.0 or newer. OpenVPN on SFOS reports its version as 2.5.5, so good.(?) But when I try to connect, I get the following error logged:

2023-12-29 21:40:32 --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.
Options error: --status fails with ‘status’: Permission denied (errno=13)
Options error: Please correct these errors.
Use --help for more information.

I can use the exact generated config, keys, and certificates files from Tomato on a lubuntu 20.04 laptop running OpenVPN 2.4.12 to VPN into my home router. I can also connect my SFOS phone to NordVPN using OpenVPN with a .ovpn configuration download from that service. So I know that the phone can connect over openvpn to something, and I know that the client files from my Tomato router will work on some hardware running some OS.

The router is using data ciphers:


These are the default I get when I tell Tomato to go generate a client config, and I haven’t added, deleted or changed anything, mainly because I’m not familiar at all with the subject.

So what’s going wrong? Is the error saying that my SFOS OpenVPN version is too new, and I need to update the router and/or enable another cipher on the router end? Or do I need to add something to the .ovpn configuration on the SFOS phone end? I’m reading all the words in the error log, but I’m not putting them together into an actionable solution.

And BTW, I have tried putting all the keys and certs inline in the .ovpn file, but the error remains the same.

Brief googling seems to hint that all the data cipher stuff should just be warnings.

I’d look at the --status permission denied part, it apparently can’t access a status file, maybe a path is wrong there.

1 Like

If the router does not generate the config for the client as needed, maybe do it yourself. The structure of OpenVPN config files is quite simple and it’s plain text.

1 Like

Ok. Those were the clues I needed. Cipher was a wild goose chase, the warnings weren’t dealbreakers.

The status option was the culprit. I was confused by the option --status status in the .ovpn file, but the second ‘status’ is the name of the status file. The filename is obviously not fully qualified here, so where it lands and who owns it would be implementation dependent. That would explain why things might work fine in one OS and not another.

I started troubleshooting, but before getting too far I tried just commenting out the offending line. Apparently it’s not necessary, at least for my purpose, so problem solved enough for now.

Now to make sure house hasn’t burned down in my absense…