Open VPN no longer working - even after factory reset to 3.11.1

Software SW bugs discussion
1

Firmware Version: OpenWrt omnia 15.05 r47055 / LuCI 96366054565006474c39e02dca00c9d45dcb9e15 branch (git-18.328.59464-9636605)
Kernel Version: 4.4.167-4a7a81f8db0ad743e54c68e1845c60b6-1`

Hey everyone,

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) , 8.8.8.8 (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!

Kind regards,

FraX

2

The developers are monitoring their code repo at Turris · GitLab and its mirror at GitHub - CZ-NIC/turris-os: Mirror of https://gitlab.nic.cz/turris/openwrt. You could file a bug at either space.

There should be more than just one line in the log about the attempted VPN connectivity, to start with.
Is this from the system log? OpenVPN can be configured to write to its own log facility, which is neater for debugging. Also its verbosity level can be raised for more details.

3

That’s wrong. As you can see from our repositories on Github you should fill bug report into Gitlab. I’d suggest reading first this article for Error reporting, where you can find all the details together with the email address, where you can report bugs.

4

I stand corrected. Perhaps pin an error reporting link somewhere central in the forum with a banner?

5

I uploaded a bunch of logs in a zip to here

To explain the sequence:

  • I updated the verbosity of the openvpn configuration file to 7
  • I executed the following command:

sudo openvpn --log openvpn.log --config turris.conf

I then created the log files *after.timeout

  • My friends suggested some additional logging but that needed some packages I didn’t have installed (or so I believed) so I repeated the same test with the same logging, but now with *after.timeut.2
  • I then went to the turris and generated some logfiles as well, of which the names are all pretty self-explanatory and start with turris.*
  • I then read the error reporting link posted above and added opkg list installed dump and dmesg

Note that:

  1. The uploaded logs are only available for 30 days.
  2. If the conversation here doesn’t provide any solace in the next day or two, I will mail the developers with this issue, repeating the information provided here.

In the meanwhile, we also checked our friends Turris that seemingly had the same issue, but that turned out to be a false alarm. The analysis did enforce the idea of it being related to vpn_turris interfaces and active IPv4 routes, as he to has these defined and I don’t.

++Addition++
Almost forgot to mention but we also tried an mtr 8.8.8.8 but that literally returned nothing, which is why the tracepath was added.

++Addition 2++
To clarify: 10.111.111.1 would be the Turris Omnia, 10.111.111.5 would be my computer’s IP in the VPN network.

6

We managed to find the fix:

  1. Login to Turris using SSH
  2. Execute the following command:
    /sbin/ifconfig tun_turris 10.111.111.1 pointopoint 10.111.111.2 mtu 1500
  3. Execute the following command
    route add -net 10.111.111.0 netmask 255.255.255.0 gw 10.111.111.2

Then execute the openvpn command as executed earlier:

sudo openvpn --log openvpn.log --config turris.conf

And the openvpn will work.

The original log contained the following part:

2019-01-05 17:45:19 warning openvpn(server_turris)[12264]: Could not determine IPv4/IPv6 protocol. Using AF_INET6

One of the differences between me and my friends is that I - after the factory reset - did not enable IPv6. Will update once we figured out whether or not enabling this would fix the issue at hand.

++ Update ++
I just checked and enabling IPv6 for WAN seems to do the trick. Note that this does not require an external IPv6 connection / address to be available.

1 Like
7

OpenVPN provides a hook for setting routing/gateway parameters. Such can be exposed via LuCI and usually do not require intervention via ssh.

8

I just wanted to let everyone know that for some reason, the fix I posted doesn’t seem to work (anymore?). Haven’t had time to analyse it though but once I can, I will

9

Here OpenVPN stopped working also. Cant seem to reset it but useally flashing a medkit works. This problem occurs every few months, useally an update is to blame.

Havent had the time to flash yet, but ive deinstalled ALL optional packages. Luci is fast and wireless is stable. Im thinking of not doing anything further untill the next update.

10

FYI, I had the same problem.
I just upgraded to 4.0.6 by following instructions here:


and the problem went away.
Please note that migration procedure is not fully tested yet, but worked smoothly for me.