L2TP Client: Debian: Difference between revisions

(8 intermediate revisions by 3 users not shown)

Line 1:

<indicator name="L2TP">[[File:Menu-L2TP.svg|link=:Category:Incoming L2TP|30px|Back up to the Incoming L2TP Category]]</indicator>

[[Category:Incoming L2TP]]

Also see this blog post by a customer using Debian and our L2TP service: https://www.ashbysoft.com/posts/debian-aaisp-l2tp/

== Standalone A&A L2TP router on Debian Linux ==

Line 6:

Line 9:

===Introduction===

⚫

I recently moved [https://libreboot.org/ libreboot.org] hosting to a much faster network than what it had before, but the new ISP doesn't assign static IPv4 or IPv6 subnets on the line, and it has all kinds of restrictions, though speed, uptime and latency are all excellent. I decided therefore to set up a tunnel connection using a&a's [https://www.aa.net.uk/broadband/l2tp-service/ L2TP tunnel service]. It's just like a regular VPN service, but specifically intended for people like me who need fixed IPs to host servers on. It's really very good, and my old hosting was done via one of their handline (VDSL) connections, but I decided I needed something faster via their L2TP service instead.

⚫

I recently moved [https://libreboot.org/ ]libreboot.org hosting to a much faster network than what it had before, but the new ISP doesn't assign static IPv4 or IPv6 subnets on the line, and it has all kinds of restrictions, though speed, uptime and latency are all excellent. I decided therefore to set up a tunnel connection using a&a's [https://www.aa.net.uk/broadband/l2tp-service/ L2TP tunnel service]. It's just like a regular VPN service, but specifically intended for people like me who need fixed IPs to host servers on. It's really very good, and my old hosting was done via one of their handline (VDSL) connections, but I decided I needed something faster via their L2TP service instead.

I was toying with OpenBSD as a router but decided to shelve that project for a while, and go with something I'm very familiar with - Debian Linux!

Line 46:

Line 48:

Essentially, I like my main network to be "invisible". Just plug in and set an IP (from the public subnet) and you're good to go. This assumes you have good physical security and/or you trust the people that have access to it.

You should not connect anything insecure directly to this main network. For example, your playstation or proprietary ~~shitware~~ Windows PC or something like that, should be heavily firewalled behind e.g. OpenWRT router.

You should not connect anything insecure directly to this main network. For example, your playstation or proprietary Windows PC or something like that, should be heavily firewalled behind e.g. OpenWRT router.

This type of network is useful to me because I run lots of servers via a&a, so I need great flexibility. This is just a very simple setup that *works*.

Line 52:

Line 54:

===Traffic shaping / QoS===

You might configure <tt>codel</tt> which is nice for QoS but that's beyond the scope of this article.

You might configure <tt>codel</tt> or (better) <tt>cake</tt> which is nice for QoS but that's beyond the scope of this article. See: https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm for some tips.

===Debian packages to install===

apt-get install ppp pppoe xl2tpd iproute2 tcpdump net-tools resolvconf

Line 65:

Line 66:

===Network configuration===

In the network configuration below, my normal router was a thinkpad connected to wifi, sharing that over ethernet. It was just a test setup. On that DHCP server on the thinkpad, the subnet was `10.42.0.0/24`, but normally you might use e.g. `192.168.0.0/24`.

In the network configuration below, my normal router was a thinkpad connected to wifi, sharing that over ethernet. It was just a test setup. On that DHCP server on the thinkpad, the subnet was <tt>10.42.0.0/24</tt>, but normally you might use e.g. <tt>192.168.0.0/24</tt>.

You MUST NOT use DHCP on this connection. You have to set a static IP, so that you can set a custom route, going to `90.155.53.19` *via* what would otherwise be the `gateway` line; in this case I'd normally set `gateway 10.42.0.1` in the example below, but instead i set `up /sbin/ip route add 90.155.53.19/32 via 10.42.0.1 dev enp14s0`. This makes all traffic on IPv4 route through the L2TP instead of directly through the main upstream, in this case virgin media.

You MUST NOT use DHCP on this connection. You have to set a static IP, so that you can set a custom route, going to <tt>90.155.53.19</tt> *via* what would otherwise be the <tt>gateway</tt> line; in this case I'd normally set <tt>gateway 10.42.0.1</tt> in the example below, but instead i set <tt>up /sbin/ip route add 90.155.53.19/32 via 10.42.0.1 dev enp14s0</tt>. This makes all traffic on IPv4 route through the L2TP instead of directly through the main upstream, in this case virgin media.

'''And do the same for any other IP addresses that l2tp.aa.net.uk resolves to. Note that IPs may be added with or without warning.'''

The fact that I used Virgin Media on this line is irrelevant. You can use L2TP on any ISP. Adapt the config below to your needs, accordingly:

Line 73:

Line 76:

===/etc/network/interfaces===

source /etc/network/interfaces.d/*

Line 129:

Line 132:

NOTE: We shall re-edit this file later. For now though, our purpose is only to get online.

NOTE: IP address `90.155.53.19` is what `l2tp.aa.net.uk` resolves to, and it shall be used directly for our purposes, due to absent name resolution during initialisation of this network.

NOTE: IP address <tt>90.155.53.19</tt> is what <tt>l2tp.aa.net.uk</tt> resolves to, and it shall be used directly for our purposes, due to absent name resolution during initialisation of this network.

===Enabling IP forwarding===

Line 140:

Line 143:

#net.ipv4.ip_forward=1

And this line (NOTE: disables stateless address autoconfiguration)

Line 149:

Line 152:

sysctl -p

This will reload `/etc/sysctl.conf` - applying our changes.

This will reload <tt>/etc/sysctl.conf</tt> - applying our changes.

===L2TP===

Line 155:

Line 158:

It may seem counter-intuitive above, that we've configured PPP as though we're on a hardline, but this is important for the next step. A&A provides L2TP without authentication, but then you authenticate via PPP routed through L2TP.

Debian kernels should already have the correct modules, but otherwise you must ensure that the `CONFIG_PPPOL2TP` and `CONFIG_L2TP` options are enabled in your kernel configuration.

Debian kernels should already have the correct modules, but otherwise you must ensure that the <tt>CONFIG_PPPOL2TP</tt> and <tt>CONFIG_L2TP</tt> options are enabled in your kernel configuration.

It should be noted that A&A L2TP service is (as of this day) currently without IPSEC or other encryption such as wireguard. This is less than ideal, but you will likely be doing a lot of encrypted things online anyway (lots of websites are https-aware nowadays).

You will not be able to use DNS until the L2TP is up, so we will use A&A's IP address for `l2tp.aa.net.uk`, which is `90.155.53.19`.

You will not be able to use DNS until the L2TP is up, so we will use A&A's IP address for <tt>l2tp.aa.net.uk</tt>, which is <tt>90.155.53.19</tt>.

===/etc/xl2tpd/xl2tpd.conf===

Place the following contents:

[lac aaisp]

lns = 90.155.53.19

Line 177:

Line 179:

Create this file, and place the following contents:

NOTE: the `name` and `password` entries are your A&A login details for L2TP.

NOTE: the <tt>name</tt> and <tt>password</tt> entries are your A&A login details for L2TP.

+ipv6

ipv6cp-use-ipaddr

Line 190:

Line 192:

===PPP IF Up/Down scripts===

PPPoE and L2TP are managed by `pppd`, which executes if up/down scripts when interfaces go up or down. We shall manipulate this accordingly:

PPPoE and L2TP are managed by <tt>pppd</tt>, which executes if up/down scripts when interfaces go up or down. We shall manipulate this accordingly:

===/etc/ppp/ipv6-up.d/0000-defaultroute===

Line 219:

Line 221:

The routes must be deleted, when the line goes down:

#!/bin/bash

/bin/logger $1 is down

Line 316:

Line 318:

This L2TP routing setup is a bit hacky, and this guide could use some refinement.

The `@reboot` line is probably redundant, since this will just run every minute anyway. I really wouldn't worry about it.

The <tt>@reboot</tt> line is probably redundant, since this will just run every minute anyway. I really wouldn't worry about it.

The last line that says "reboot" will run at boot time, for each and every boot. It will also run again, once every minute. If the L2TP is online, running the command is harmless and will simply exit.

Line 330:

Line 332:

ListenAddress 10.0.0.42

You can find useful logs in `/var/log/messages`.

You can find useful logs in <tt>/var/log/messages</tt>.

==Testing==