openl2tp.org

A number of feature enhancements have been proposed. This topic is to record them. Users are invited to suggest and discuss other enhancements under this topic.

• add network namespace support. Recent kernels allow interfaces to be associated with a network namespace. Traffic cannot pass between namespaces and the address space is independent. This allows arbitrary L2TP sessions to be grouped together, completely independent of other users on the same system. This usage is often referred to as a "walled garden". The currently unused priv_group_id session parameter will be used to identify the network namespace to which the session's interface will be assigned.
  
• add L2TP tunnel routing, forwarding data from one tunnel into another. This will be implemented by enhancements to the kernel driver to allow two L2TP sessions to be linked together. Data will then flow out of one into the other, with no involvement from userspace apart from asking the kernel to link two sessions together.
  
• add RFC3817 support. This is an extension to the L2TP control protocol to allow PPPoE service discovery control packets to be carried inside L2TP control messages to a remote PPPoE server. This is useful when the PPPoE server is not located near the PPPoE clients. Once the client finds the server, an L2TP session is created to carry the PPP traffic to the server in the usual way. It will be necessary to add a new interface to openl2tpd for extracting PPPoE service disovery frames and stuffing them into L2TP control messages.

Hi James,



Sounds interesting. I've been trying to follow the recent work on namespaces but I'm left confused about how it is going to work with tunnel devices such as L2TP and GRE. Is it possible for tunnel drivers to have their virtual devices in different namespaces to which they sends/receives the tunnel packets? What little documentation I've found on the namespaces suggests rather more isolation.

Which namespace would the pppd's themselves be running under? If they were in the private namespaces they wouldn't be able to talk to the RADIUS server, etc.

Currently we fake up separate namespaces on our LNSs with a fwmark based routing policy, multiple routing tables, stateless firewall rules, a few kernel patches (to preserve the fwmark when generating ICMP and checking RP filter) and a fairly extensive patch to Quagga. It would be really nice to be able do away with all that and have the kernel handle it properly.

I don't think configuring the namespace in the openl2tp session parameters is going to meet our requirements. As I imagine is the case with many other ISPs our incoming sessions all come from the same pool of LTS at the wholesale provider and until we've authenticated the PPP sessions we are unable to identify which namespace the session belongs in. Is it feasible to switch namespace from the pppd after RADIUS authentication?

Ben.

Are you aware there is currently already one kernel based open-source package that can do this?

The only catch is which kernel it is based in. FreeBSD has a package called 'mpd' which despite being advertised as a multilink PPP daemon actually goes far beyond this and can act as an access concentrator and tunnel switch. It has support for physical devices such as modems but also has PPPoE and L2TP client and server support and can apparently connect any input device directly through to any output.

I've been looking at mpd because it can initially terminate sessions in its local PPP implementation to obtain the username from the peer, and it can then look up the username and decide to switch the session through to another L2TP session. At this point its own PPP implementation stops, all the session traffic is forwarded verbatim and the PPP on the LNS restarts the negotiation. This is a nice feature but unfortunately limited in that it can only look up the username in its own local config, it doesn't yet query the RADIUS server to find out where the session should be forwarded to. It would be great to see a feature like that in openl2tp.

My understanding is that any interface and application process may be associated with a given net namespace. So each pppd process (and its pppN net device) could be assigned to a given namespace. I think there is also the ability to configure links between namespaces, which would be how processes in different namespace could reach a common RADIUS server, for example.

I assume it is possible to change the namespace of a given process after it has been instantiated, though I haven't looked at this scenario in detail.

/james

Yes, I've seen mpd. Unfortunately it uses netgraph so won't work on Linux.

Adding the ability to do as you describe above is something we want to do.

/james