Firmware Version: OpenWrt omnia 15.05 r47055 / LuCI 96366054565006474c39e02dca00c9d45dcb9e15 branch (git-18.328.59464-9636605)
Kernel Version: 4.4.167-4a7a81f8db0ad743e54c68e1845c60b6-1`
After not having used OpenVPN for a month or two, I wanted to connect to my Turris Omnia but bumped into several issues that eventually lead me to losing the overview to the point where I deemed a re-flash of the router necessary. I used the latest medkit as provided in the instructions.
After re-flashing the router, I followed the wizard as provided in Foris to set up my router to connect to the internet and install OpenVPN. After installation, I generated the CA, created a new client and attempted to connect via an Ubuntu laptop. The laptop gave feedback that the connection was created, but when wanting to ping any IP address or visit any website, none of the attempts succeeded. I’ve tried 10.111.111.1 (the IP address of the turris through the VPN connection) , 22.214.171.124 (IP of google.com) or google.com. I see the following error return:
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
I have analyzed the turris with a two friends of mine. One of them has OpenVPN still operational, the other seems to have the same issue, although we haven’t looked into it in detail.
Our current guess would be that the issue relates to routing issues on the Turris Omnia itself. Note that if I say “operational turris” I mean the Turris Omnia that has OpenVPN operational, and if I say “broken turris” I mean the Turris Omnia that has the issue as described above.
- The operational Turris has the vpn_turris interface that can be found in LuCi’s “Interfaces” list (which uses the “physical” interface tun_turris). the broken Turris does not.
- The operational Turris has vpn_turris in the list of active IPv4 Routes (LuCi and then routes). The broken Turris does not.
I have tried to provide better proof that routing is the issue, but fail to prove anything because I am operating well outside of my expertise, and trying to troubleshoot this via Foris is nearly impossible because the feedback is unreliable and it seems as though things break relatively easy.
Based on my experience, I would say that the reason the routing is going wrong must be because some of the parts needed to get OpenVPN operational are not properly deployed as part of OpenVPN installation and are not a part of the factory setup either. Additionally, the issue might cascade further when the OpenVPN installation itself fails due to missing dependencies or any assumed preconditions, explaining why we struggled so much in trying to grasp what is actually happening.
I understand that my report is pretty descriptive, but I struggle to figure out what information I can add to this post to provide the appropriate logging to debug this issue. If anyone needs any information to help me understand and resolve the issue at hand, let me know. Today I will be online for a large portion of the evening, so I’d be more than happy to provide diagnostics and/or additional information.
Also: I understood that the forums are not actively monitored for issues: does Turris have some kind of system where I can file bugs? If not: who should I email for this issue? Thanks for your help!