Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

L2TP support #752

Closed
NeoRaider opened this issue May 4, 2016 · 23 comments

Comments

@NeoRaider
Copy link
Member

@NeoRaider NeoRaider commented May 4, 2016

Some communities are already experimenting with L2TP to connect Gluon nodes. It would be great to have this in the official Gluon repo.

@NeoRaider NeoRaider added this to the next milestone May 4, 2016
@MPW1412

This comment has been minimized.

Copy link
Contributor

@MPW1412 MPW1412 commented May 4, 2016

Yeah, that sounds great.

I think the most advanced repo for the tunneldigger is the FFRL repository: https://github.com/ffrl/tunneldigger

The patch for fixing the broker selection by usage is already merged (https://github.com/ffrl/tunneldigger/commit/5d34ae6a1e1cecc2b5cfb72fb02bf3e6b78a763e).

Questions to me are:

  • The tunneldigger brings its own mechanism to limit the used bandwith. Shall we use that in future? The client communicates its wished maximum bandwith to the server which then throttles the connection to that limit.
  • The tunneldigger has support for auto negotiated MTU, but as far as I know, no community uses it, because Batman can't handle different MTU sizes. Maybe you know more about that problem? Auto MTU negociation would be great.
  • There's no way to block nodes like on fastd, as there is no authentication process. That might become a problem in the future.
  • No ipv6 support at all. The upstream maintainer wlanslovenija signaled good will to merge patches to enable ipv6 support, but there's no working implementation so far. (L2TP works with ipv6, but the tunneldigger and its negotiation process don't.)

The client (l2tp_client.c) is badly structured and needs refractoring. We plan to start that tonight.

@NeoRaider

This comment has been minimized.

Copy link
Member Author

@NeoRaider NeoRaider commented May 4, 2016

  • A similar feature for limiting the bandwidth on the remote side is planned for fastd, but for now using the simple-tc package for both tunnel solutions may be easier. I'm not sure...
  • Yes, batman-adv is unable to deal with different MTUs in a forwarding path (and compat 15 would not be able to re-fragment on middle nodes without reassembling a packet...), so in Gluon, we've patched batman-adv to always fragment to fit an MTU of 1280...
    Having different tunnel MTUs (that are at least 1280) doesn't hurt either though (it just doesn't help), so we can just enable the auto negotiation and will actually be able to use the higher MTU as soon as we have a layer 3 routing protocol
  • Missing IPv6 support is indeed an issue to be solved.

If we have enough space to fit both fastd and tunneldigger on our nodes, we could even change the expert mode package that lets the user choose between "security" and "performance" to switch from fastd to L2TP instead of switching fastd to methd "null".

@Adorfer

This comment has been minimized.

Copy link
Contributor

@Adorfer Adorfer commented May 4, 2016

@MPW1412

The tunneldigger has support for auto negotiated MTU,

Due to current batman-v15 refragmentation issues i susppose we are splitting to 1280 anyways, correct?

There's no way to block nodes like on fastd,

I assume that blocking nodes can be done on the node-id, since it's invoced to the wrapper-scripts.
(where you set up your bandwith-stuff depending on nodes too...)

@lcb01a

This comment has been minimized.

Copy link
Contributor

@lcb01a lcb01a commented May 4, 2016

Yes, batman-adv is unable to deal with different MTUs in a forwarding path (and compat 15 would not be able to re-fragment on middle nodes without reassembling a packet...), so in Gluon, we've patched batman-adv to always fragment to fit an MTU of 1280... Having different tunnel MTUs (that are at least 1280) doesn't hurt either though (it just doesn't help), so we can just enable the auto negotiation and will actually be able to use the higher MTU as soon as we have a layer 3 routing protocol

If batman always uses 1280 when fragmenting a frame then we could just stick with a statically asigned MTU.
Tunneldigger currently changes the MTU dynamically after the initial interface has been setup. So we will have to make sure that a changing MTU is no problem for either Batman or later on Babel.
On the gateways / supernodes this could be achieved with several bridge interfaces to cover the different MTU values. Tunneldigger offers a hook which trigers a script when the MTU changes, this script then attaches the interface to the correct bridge.

Missing IPv6 support is indeed an issue to be solved.

Missing IPv6 support is also on the agenda of wlan slovenia: https://dev.wlan-si.net/ticket/1187
It would be great if you could help out wlan slovenija as well by contributing 👍

I will prepare a merge of the tunneldigger gluon packages into the main repository. 😄

@christf

This comment has been minimized.

Copy link
Member

@christf christf commented May 4, 2016

having a security and a performance mode would be great. But couln't fastd reach similar performance resulting in reduced complexity in the image build?

@wusel42

This comment has been minimized.

Copy link

@wusel42 wusel42 commented May 5, 2016

Tunneldigger gains it's speed advantage by using a tunneling method supported by the kernel; in fastd, each packet causes a context-switch (kernel-context -> user-context), whereas L2TP stays within the kernel-context. Unless fastd is moved into kernel-space, I don't see how it could compete with in-kernel methods like GRE, L2TP, IPIP, ... And the issue is exhibited mostly on low-end embedded CPUs; the (x86) CPU in a Futro has no issue doing OpenVPN at 50 MBit/sec, but even an RPi v2 cannot keep up beyond about 25 MBit/sec.

@petabyteboy

This comment has been minimized.

Copy link
Contributor

@petabyteboy petabyteboy commented May 5, 2016

The FFRL tunneldigger doesn't include any usable respondd data providers.

@lcb01a

This comment has been minimized.

Copy link
Contributor

@lcb01a lcb01a commented May 7, 2016

The FFRL tunneldigger doesn't include any usable respondd data providers.

For 2015.1.2 it is working, but since the switch to C it would be great if someone else could take care of that. My C skills are a bit rusty.
Please provide a pull-request to the original FFRL Gluon package repository:
https://github.com/ffrl/ffrl-packages

I will glady implement this into the pull request to the Gluon main repository

@petabyteboy

This comment has been minimized.

Copy link
Contributor

@petabyteboy petabyteboy commented May 8, 2016

I don't have any C skills that could be rusty 😁
I just wanted to mention that this is something that has to be done before the package is part of gluon.

@jplitza

This comment has been minimized.

Copy link
Member

@jplitza jplitza commented May 11, 2016

FTR: fastd currently reports in the nodeinfo part its version and whether it's enabled, and in the statistics part which neighbours it is connected to for how long.

The 2015.1-style announce code in the ffrl repo reports whether tunneldigger is enabled in the nodeinfo part (can be copied 1:1 from the fastd module) and… nothing (o_O?) in the statistics part.

So presumably, those who insist on a respondd provider are missing the list of connected neighbours?

@petabyteboy

This comment has been minimized.

Copy link
Contributor

@petabyteboy petabyteboy commented May 13, 2016

Yup that's the thing missing.

@PowerPan

This comment has been minimized.

Copy link
Contributor

@PowerPan PowerPan commented Jun 17, 2016

Any News?

@Wlanfr3ak

This comment has been minimized.

Copy link

@Wlanfr3ak Wlanfr3ak commented Jun 24, 2016

Anything new about this Issue ?

@Adorfer

This comment has been minimized.

Copy link
Contributor

@Adorfer Adorfer commented Oct 19, 2016

Any chance for native L2TP? is it just the Respondd missing

@rotanid

This comment has been minimized.

Copy link
Member

@rotanid rotanid commented Oct 19, 2016

perhaps also "No ipv6 support at all"? for me that's a no-go...
and no one volunteered to do the necessary changes or improvements, so THAT is the real problem i guess ;)

@A-Kasper

This comment has been minimized.

Copy link
Contributor

@A-Kasper A-Kasper commented Nov 15, 2016

I would also like to see the l2tp support added to gluon

https://github.com/ffrl/tunneldigger
https://github.com/ffrl/ffrl-packages
https://github.com/ffrl/ffrl-tunneldigger-docs

@rotanid the missing IPv6 is not a problem, more a "nice to have". There aren't any ipv6 only isps in germany by now. tunneldigger is much better, also on dslight connections. It would be nice to connect to vpn servers via ipv6, yes.. but ipv4 still exists and works fine. so this should not stop us from implementing l2tp. the tunnel itself is layer2, so IPv6 connections from clients through the tunnel shouldnt be affected...

@rotanid

This comment has been minimized.

Copy link
Member

@rotanid rotanid commented Nov 16, 2016

for reference: ffrl/ffrl-packages#8

@Adorfer

This comment has been minimized.

Copy link
Contributor

@Adorfer Adorfer commented Nov 16, 2016

What really lacks for the moment (as far as i am aware): respondd support for L2TP. It looks like there is missing a lot of data which can only be "indirectly" (e.g. by knowing the MAC of the L2TP servers)

@lcb01a

This comment has been minimized.

Copy link
Contributor

@lcb01a lcb01a commented Nov 25, 2016

I've created a pushrequest for this issue: #947

@lcb01a

This comment has been minimized.

Copy link
Contributor

@lcb01a lcb01a commented Dec 13, 2016

New PR for this issue is: #978

@NeoRaider NeoRaider modified the milestones: 2016.3, next Dec 18, 2016
@NeoRaider

This comment has been minimized.

Copy link
Member Author

@NeoRaider NeoRaider commented Mar 10, 2017

Support has been merged thanks to the work of @lcb01a :)

@NeoRaider NeoRaider closed this Mar 10, 2017
@A-Kasper

This comment has been minimized.

Copy link
Contributor

@A-Kasper A-Kasper commented Mar 10, 2017

@mitar

This comment has been minimized.

Copy link

@mitar mitar commented May 21, 2017

IPv6 support for Tunneldigger was selected as one of this years GSoC projects. So work on https://dev.wlan-si.net/ticket/1187 will start soon.

Some comments for things mentioned above:

The tunneldigger brings its own mechanism to limit the used bandwith. Shall we use that in future? The client communicates its wished maximum bandwith to the server which then throttles the connection to that limit.

Server helping limiting is the only way you can limit bandwidth well in both directions. You cannot do that only on the node. Server has to participate.

There's no way to block nodes like on fastd, as there is no authentication process. That might become a problem in the future.

We think that for authentication, authorization, and encryption one can use IPSec. But we could discuss such feature and see. How would you identify nodes to be blocked?

BTW, the best way to reach us it to open issues on our Trac, or talk to us on our chat.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.