openvpn v2.4.5 is incompatible to our current tunnel-gateways #580
Labels
Milestone
Comments
pmelange
changed the title
pmelange
referenced
this issue
Jul 31, 2018
Patch mbedtls to allow 1024 bits RSA for bbb-vpn and VPN03 compatibility fixes #489
|
Update: I have found one of the problems... The hotplug script in firmware-packages/defaults/freifunk-berlin-openvpn-files/openvpn/60-ffopenvpn declared variables with the "local" declaration. I have made commit a87f7e53259e1f588f7747a16557c895a3fe7ce8 with the needed changes. Now OpenVPN starts at boot time and there is not longer an error when running "/etc/init.d/openvpn restart". That, at least, is step 1 of the problem. But the rest of the problems from the description persist. If it helps, there are errors in /tmp/ffvpn-up.log |
pmelange
referenced
this issue
in freifunk-berlin/firmware-packages
Aug 1, 2018
|
I think the problem comes from here:
and a result is (check a search-engine for openvpn lzo "Invalid argument (code=22)")
probably related to some deprecation of the comp-lzo setting in openvpn have you tried to build a version w/o the mbedtls-1024 patch? Did that work? |
|
I have built the master branch without the 1024 patch with the same results. I also removed vpnbypass with and without the 1024 patch. Same results. Here is the logfile. It doesn't look different from before Here is the results from tcpdump while pinging 8.8.8.8 from a client. There are checksum errors. |
|
Perhaps 087680a ? |
|
I'm building now with these changes removed, but with the 1024 patch and vpnbypass in. I'll let you know tomorrow. |
|
With the changes in 087680a removed, I still have the same problems. |
|
Please check against one of the VPN03 servers. |
|
With the changes in 087680a removed, and with the 1024 patch and vpnbypass in, configured to use vpn03 (with the correct certs, keys, ...), I still have the same problems. |
|
I just tried out openwrt 18.06.0 with openvpn (mbedtls). I'm also getting these "code=22" errors. |
|
With 17.01.5 I don't get these errors. EDIT: Changed version number to be correct |
|
https://community.openvpn.net/openvpn/ticket/952 might explain what is going on. In Hedy 1.0.1 we use openvpn 2.4.4 On server vpn03f.berlin.freifunk.net we use 2.3.12 It would be really great if someone with more experience with openvpn took a look at this. |
|
freifunk-gw01.in-berlin.de : Version: 2.4.0-6+deb9u2 "comp-lzo no" is set |
SvenRoederer
changed the title
|
I have created a ticket with openwrt: @SvenRoederer, could you post the server config for freifunk-gw01.in-berlin.de? |
|
@lynxis As per your request, I have posted a ticket with openwrt. |
|
as mentioned 11 months ago, the config-files are here: https://github.com/freifunk-berlin/puppet-files/blob/tunnel-berlin/files/tunnel-berlin |
|
Thank to help from the openwrt issue tracker, I new have a configuration on the client side which successfully makes a vpn connection to freifunk-gw01.in-berlin.de. I haven't tried any vpn03 servers. The needed extra option is: I have tried this both with and without I don't have access to the server. But it would be good to know if, in the end, compression is turned off. @SvenRoederer, could you check this on the server side? According to the man page, it should be possible to give the I won't have time to make the changes to the firmware before early September. If someone else wants to make these changes, that would be great. |
|
Sorry, I wrote too soon. The |
|
As you can see from the sever-configs, we want no compression at all. So compression of data on the client side but no decompression on the server-side will fail logically. according to the openvpn-ticket referenced above, one solution would be to enable lzo on both sides of the tunnel. but this requires a change on all clients. |
|
Having compression on the client->server and no compression on the server->client (and visa-versa) is a totally valid configuration. The reason that it didn't work with the freifunk firmware, like I wrote above, is because of 087680a. It is also possible to have the server push no compression to the clients after they connect. The thing that is a problem is that I still can't figure out a way to have the clients do no compression. Simply leaving out the compress option will not work. I have tried various versions of the compress option, but I still haven't found one that works. So, my suggestion is that we re-enable the This will be my last post until some time early Sept. If someone else wants to take over this issue, that would be great. https://community.openvpn.net/openvpn/wiki/DeprecatedOptions |
|
If commit 087680a introduced the problem I'm in favour of reverting this commit or parts of the commit. |
|
I just installed the openwrt-18.06-1 openVPN package (including liblzo and libmbedtls) on top of a recent SAm0815_experimental build (c48602e). And I saw the same errors as our package with the disabled options of 087680a. |
|
@SvenRoederer I installed the packages from 18.06.1 on our firmware, like you did. When I added Yes, the problem is still that compression is on. After all my research, it doesn't look like it is possible to have an option like 'none' 'disabled' '0' 'noop' or anything othen than 'lzo' 'lz4' and 'lz4-v2'. It would be worth trying to push the setting from the server with Since Not having the 'compress' option in the configuration sets up the header to a certain format which is not compatible with our setup (server and client) which have a special header with compression info. The different headers, as far as I can tell, is the reason for the code=22 errors. |
|
I hacked the openvpn init script to allow for See https://bugs.openwrt.org/index.php?do=details&task_id=1762 I'm not sure what to do next. Maybe we need to explicitly put Anybody have any other ideas? |
|
As mentioned in my last post (#580 (comment)) I had no luck with using the original 18.06-openwrt package of openvpn. So I don't believe in enabling lzo-support will fix this. |
|
What is the problem? |
|
I have created branch openvpn245. I have also installed it on my rb750gr3. @SvenRoederer , @bobster-galore , @booo I have added your ssh keys to the router. It is reachable via the backbone. The host is ptest3.olsr I will be gone until Sat evening. Until then, have fun. And if anyone wants to merge the changes on the openvpn245 branches in firmware and firmware-packages, then that would be really cool. |
|
Oh, and I haven't done migration yet. I can do it on Sunday. |
This was referenced Sep 16, 2018
|
There are now two PR's ready for someone to take a look at and (hopefully) merge. I saw that @SvenRoederer pushed a commit to the master branch to reeable compiling with liblzo support. I believe the PR that I created is complete and with better comments. Also, I find it better to have the compile option commented out (readability and understandability) then just simply deleting the compile options. I would recommend deleting that commit and merging the openvpn245 branch. I |
|
The system has been running for 5 days now. @SvenRoederer @booo @bobster-galore is there any reason to keep the box running? If nobody objects, I would unplug the router tomorrow evening. |
|
I had no idea what to test. Let it go unplugged! |
|
How do we fix this for 1.1.0? |
|
There are 2 PR's ready to fix this issue. They need a review and hopefully to be merged. |
|
have same issues. use last build. |
|
add |
|
A new commit has been added to openwrt-18-06 |
|
Even the description here has changed...
|
pmelange
referenced
this issue
in openwrt/openwrt
Dec 12, 2018
This option is deprecated but needs to be kept for backward compatibility. [0] [0] https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#a--comp-lzo Signed-off-by: Martin Schiller <ms@dev.tdt.de> Signed-off-by: Hans Dedecker <dedeckeh@gmail.com> [PKG_RELEASE increase] (cherry picked from commit 3850b41)
|
in the OpenVPN-wiki the change of the removal is dated to 20.Oct 2018 (https://community.openvpn.net/openvpn/wiki/DeprecatedOptions?sfp_email=&sfph_mail=&action=diff&version=13&old_version=11&sfp_email=&sfph_mail=) |
|
The lates commit to 2.4.5 is "Latest commit 27a2e01 on Feb 28". Since 18.06 is still using 2.4.5 then we might be in luck. |
|
My recommendation is the following:
We can also set up the community-tunnel openvpn service like this on all the remaining vpn03 servers. |
|
this I had done on the in-berlin gateway once |
|
I have built locally and tested this issue with commit openwrt/openwrt@d5afaa4 integrated. Now OpenVpn 2.4.5 works. Shall we close this issue? If we want to create a new setup on the server side and client side for 1.1.x or possibly 1.2.x, then I think it should go in a new issue. |
|
let's close this here. changes to the tunnel-setup should go into the tunnel-repo or better on the mailinglist |
SvenRoederer
added a commit
that referenced
this issue
Jun 18, 2020
2b6a4e1 olsrd: bump to latest version c78adaf Merge pull request #580 from PolynomialDivision/fix/olsrd
SvenRoederer
added a commit
to SvenRoederer/freifunk-berlin-firmware
that referenced
this issue
Jun 22, 2020
2b6a4e1 olsrd: bump to latest version c78adaf Merge pull request freifunk-berlin#580 from PolynomialDivision/fix/olsrd
SvenRoederer
added a commit
to SvenRoederer/freifunk-berlin-firmware
that referenced
this issue
Jun 22, 2020
2b6a4e1 olsrd: bump to latest version c78adaf Merge pull request freifunk-berlin#580 from PolynomialDivision/fix/olsrd
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is happening on freshly installed and configured (through the wizard) tunnel-berlin images in "master" and "SAm0815_experimental". This is possibly also an issue in other builds/branches, although I haven't tested them.
The text was updated successfully, but these errors were encountered: