Skip to content

Instantly share code, notes, and snippets.

@dangowrt
Last active December 29, 2023 07:05
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 2 You must be signed in to fork a gist
  • Save dangowrt/e65dfde190fb1fcaf05f to your computer and use it in GitHub Desktop.
Save dangowrt/e65dfde190fb1fcaf05f to your computer and use it in GitHub Desktop.
cjdns exit tunnel broker brainstorming

#Clearnet-Exit tunnel broker brainstorming

For now: https://github.com/BerlinMeshnet/visp ie. a bunch of Ruby scripts setting up cjdns to setup IP tunnels.

##What we need is similar to an open tunnel broker.

Tunnel brokers may offer multiple tunneling protocols, such as IP Tunnels, L2TP pseudo-wires, IP-over-GRE, ... to clients, carrying different types (IPv4-behind-NAT, public-IPv4, IPv6-single-address, IPv6-routed-prefix, ...) of services and may possibly restricted traffic types (e.g. DNS-and-outgoing-TCP-to-common-ports-only)

The Tunnel broker should have a way to tell interested clients which services it offers and maybe some additional information, such as the geographic position where packages will show up in ARPA/Clearnet.

It doesn't need to (and imho shouldn't) be integrated in cjdroute, but rather be a small independent service running on the vISP's Exit servers allowing interested clients to request/lease L2TP tunnel parameters (tunnel_id, remote_tunnel_id, session_id, peer_session_id). A simple CGI script would do.

##Existing implementations of TSP:

https://github.com/citc/CITC-IPv6-Tunnel-Broker

https://github.com/vr0/tsps

TSP is way to complex. We don't need SASL and all that.

##L2TPv3

Throwing Ethernet pseudo-wires over cjdns is easy to comprehend and works great :)

So I'd like to use Ethernet-over-L2TPv3-over-IP6/cjdns.

Proper (i.e. native in C via netlink) netifd integration of L2TPv3 tunnels on OpenWrt would be nice to have :)

For now there is l2tpv3.sh

Advantages of L2TPv3 over classic IP tunnels:

  • addressing and routing is provisioned via DHCP, RA, ND, ... just like on real Ethernet
  • Easy-to-deploy as a distributed hotspot, roaming just like in batman-adv (at least in theory)
  • standard protocol supported by many OS and network device vendors (Cisco, Aruba, Microsoft, Apple, ...)

L2TPv3 pseudo-wires over cjdns lead to https://patchwork.ozlabs.org/patch/466774/ which was applied as https://dev.openwrt.org/changeset/45593 and will hopefully be brought back into my original format by https://patchwork.ozlabs.org/patch/467247/

L2TPv3 pseudo-wires can end up in a bridge on the Exit server, ebtables can be used there to achieve client isolation. OpenVSwitch might perform much better than "simple" Linux bridges, especially if the number of ports is getting higher...

Setting up l2tp tunnels on the Exit node is quite simple:

#!/bin/sh
local="fc12:3456:7890:1234:5678:9012:3456:7890"
bridge="br-exit"

brctl delif $bridge $1
ip l2tp del session tunnel_id $2 session_id $4
ip l2tp del tunnel tunnel_id $2
ip l2tp add tunnel tunnel_id $2 peer_tunnel_id $3 remote $6 local $local encap ip
ip l2tp add session tunnel_id $2 session_id $4 peer_session_id $5 name $1
brctl addif $bridge $1
ip link set $1 up

The client setup is just as simple. Simply invent a new interface name, say "testvpn", add it into the LAN interface and change proto to 'dhcp'. netifd will take care to have it automatically end up in the LAN bridge once it comes up. Now setup the L2TP pseudo-wire:

# add l2tp tunnel
ip l2tp add tun=nel tunnel_id 1000 peer_tunnel_id 2000 remote fc12:3456:7890:1234:5678:9012:3456:7890 local fc98:7654:3210:9876:5432:1098:7654:3210 encap ip
ip l2tp add session tunnel_id 1000 session_id 4000 peer_session_id 3000 name testvpn
ip link set mtu 1280 dev testvpn
ip link set testvpn up

One the client we might want to offer both, clearnet and cjdns, on the Ethernet ports. This can be done by bridging the Ethernet ports with the L2TPv3 pseudo-wire and setup cjdns to send beasons on that bridge interface. To prevent feed-back loops and similar havoc, ebtables needs to be used to prevent cjdns beacons leaking into the l2tp-over-cjdns tunnel:

ebtables --init-table
ebtables -P FORWARD ACCEPT
ebtables -P INPUT ACCEPT
ebtables -P OUTPUT ACCEPT
ebtables -A INPUT --in-if testvpn --log-level info --log-prefix "dropped cjdns beacon" -p 0xfc00 -j DROP
ebtables -A OUTPUT --out-if testvpn -p 0xfc00 -j DROP
ebtables -A FORWARD --out-if testvpn -p 0xfc00 -j DROP
ebtables -A FORWARD --in-if testvpn -p 0xfc00 -j DROP

So what is missing is:

  • a database for leases
  • some sort of heartbeat, so dead tunnels get removed
  • more ebtables magic :p
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment