L2TP Client setup with Spitz

Hi There,

I’m trying to connect to a L2TP service from Andrews & Arnold in order to get a fixed IP over a 4G Connection.

I’ve got a Spitz device, and can create the tunnel following the vendors instructions here:

https://support.aa.net.uk/L2TP_Client:_OpenWRT

However, I’m struggling to route my lan traffic out of it.

I’m fairly sure this package will do what I need but I’m having problems installing it on the Spitz:

https://github.com/stangri/openwrt_packages/blob/master/vpn-policy-routing/files/README.md

Has anyone done anything similar and have any pointers?

Cheers,

Antony

@PirateBriggs
Hi,can you describe the specific problem? There is a problem with the installation, can you attach the log information, thank you

Sorry for the late reply, and it may not be directly applicable if you’re using the factory firmware, but I use l2tp to aa.net.uk on an x750 with vanilla openwrt here.

The relevant configuration in /etc/network/config was simply

config interface wan
	option proto l2tp
	option server l2tp.aa.net.uk
	option username xx321@a.1
	option password FooBarBaz69
	option ipv6 1
	option checkup_interval 60

config interface wan6
	option ifname @wan
	option proto dhcpv6

The wan6 stanza is needed instead of option ipv6 auto (which you might expect to work) because /lib/netifd/proto/l2tp.sh doesn’t implement the nice ipv6 auto behaviour that /lib/netifd/proto/ppp.sh does.

You’ll need xl2tpd installed and l2tp_ppp support in the kernel. I can’t remember if that’s installed/included out of the box in the defconfig or has to be added to .config I’m afraid.

@ChrisW
You can use this package to install, I have tested and installed without problems, I look forward to your feedback, thanks
vpn-policy-routing_0.2.1-3_all.zip (12.5 KB)

I’m slightly puzzled why the original poster needs anything as complicated as policy routing: it works fine to just set option metric 1 on the wwan interface and let the l2tp interface default to metric 0. Traffic then goes out over l2tp whenever that interface is up. Unless you have subnets you want to route differently, some directly over 4g/lte, some over l2tp?

Thanks for the replies Peeps.

@ChrisW I was surprised also - I found that there was some built-in routing policy magic in the x750 flavour of openwrt that was thrarting my efforts. I Didn’t think of re-purposing the wan interface as l2tp - I can see how that would work with the built-in mwan3 config. I’ll give it a go. I assume you’re connecting to the internet over something other than wan?

@wellnw - Thanks for the package. have you modified this in some way to work with the x750? I had managed to install this package from github however I wasn’t able to detect that the lte modem was my wan interface. even after hard-coding the interface name in the script, it wasn’t routing traffic out of the l2tp tunnel (i.e. from the LAN

I’m sure I could get this to work with vanilla OpenWrt - however I’ve picked up a x750 in the hope I wouldn’t need to :slight_smile: I’ve not had much luck configuring openwrt in the past - I have a r7800 acting as a glorified wifi ap as a testiment to that

Slightly off topic, but the background to this problem is that I live in the sticks and have a very slow but stable ADSL line to the house but have great LTE signal but I find the connection is less-stable. I bought the x750 to use the LTE as primary connection and fall back to the eth0 wan (adsl). The l2tp bridge was to give a consistent egress IP as I access some resources that are IP whtelisted. (and to give IPv6 a decent go)

@PirateBriggs
I compiled the package directly according to the link you gave without any modification. After compiling the ipk, I found that it can be installed directly without exceptions. As for using this package, I have not studied it here.Thank you.

Hi, yes you’re right: I’m using Vodafone 4G wwan exclusively on that router. I’ve attached my full /etc/config/network at the end after a bit of password munging.

My farm is in an area with poor (low single-digit Mbps) ADSL speeds, even poorer VDSL FTTC speeds (cable length) but somehow within reach of 60/30 Mbps 4G. Given that I can pick up an unlimited and uncapped data SIM for around half the price of line rental and decent DSL, using that makes a lot of sense.

Mobile carriers are eye-wateringly clueless ISPs though, hence unencrypted L2TP to aa.net.uk. It’s not there for security reasons, just to get to a real ISP with proper static v4 and v6, no nasty cgNAT, no crazy http mitm to randomly break scripts, etc. Amusingly, this actually improves latency to most places because the mobile carrier peers less skilfully. I see 35ms latency to LoNAP which is excellent for somewhere this rural.

Over the past year, I’ve found 4G here to be as reliable as the previous wired DSL. There’s just one odd behaviour I’ve noted—every 48h like clockwork, the connection drops. I disable modem level autoconnect and monitor the connection status with uqmi --get-data-status to detect this happening; it works fine to restart the interface to bring it back up immediately and this results in no more than a second or two of downtime. If I remember right, the factory firmware comes with some monitoring of its own which will probably detect this and restart it equally transparently.

I should also say that I patch OpenWRT in a couple of ways which might affect the config very slightly: in my tree, I fix openwrt/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh to obtain both v4 and v6 addresses direct from uqmi, getting rid of the superfluous dhcp client talking to the qmi interface (hence dhcp 0 in the config). So you probably want to drop that dhcp 0 line if you use my wwan stanza.

config globals globals
	option ula_prefix auto

config interface loopback
	option ifname lo
	option proto static
	option ipaddr 127.0.0.1
	option netmask 255.0.0.0

config interface lan
	option type bridge
	option ifname 'eth0 eth1'
	option proto static
	option ipaddr 192.168.1.1
	option netmask 255.255.255.0
	option ip6assign 64

config interface wwan
	option ifname wwan0
	option proto qmi
	option device /dev/cdc-wdm0
	option service umts
	option apn internet
	option username web
	option password web
	option autoconnect 0
	option dhcp 0
	option metric 1
	option peerdns 0

config interface wan
	option proto l2tp
	option server l2tp.aa.net.uk
	option username xy123@a.1
	option password FooBar123
	option ipv6 1
	option peerdns 0
	option checkup_interval 60

config interface wan6
	option ifname @wan
	option proto dhcpv6
	option peerdns 0

PS If you use uqmi for monitoring as well as interface control, you’ll probably also hit a bug where two uqmi instances access the /dev/cdc-wdm0 interface at once, and one of them deadlocks waiting for a response that was delivered to the other instead. If so, you can fix this by arranging for uqmi to flock() the device node to serialise access:

diff --git a/dev.c b/dev.c
index bd10207..d14255a 100644
--- a/dev.c
+++ b/dev.c
@@ -24,6 +24,7 @@
 #include <stdlib.h>
 #include <stdio.h>
 #include <string.h>
+#include <sys/file.h>
 #include "uqmi.h"
 #include "qmi-errors.h"
 #include "qmi-errors.c"
@@ -359,6 +360,9 @@ int qmi_device_open(struct qmi_dev *qmi, const char *path)
        if (fd < 0)
                return -1;
 
+       if (flock(fd, LOCK_EX) < 0)
+               return -1;
+
        us->notify_read = qmi_notify_read;
        ustream_fd_init(&qmi->sf, fd);
        INIT_LIST_HEAD(&qmi->req);

This is on my to-do list to send upstream at some point.

Does this seemingly innocent statement involve some shell scrips and cron jobs and the like? That’s probably too far into *nix land than I’m willing to travel. Was after a router that just works :slight_smile:

Yes, but you really don’t need any of that unless you’re replacing the factory firmware connection monitoring system, and don’t like any of the pre-packaged openwrt options either. You can choose your own adventure here. :slight_smile: You should just be able to set up the l2tp with a shorter metric than whatever you use for connectivity underneath it, and be done.

Well, that deffo didn’t work with the stock firmware. The modem interface is set to a metric of 40 and I tried setting the l2tp interface to 30 and no cigar.

I’m currently investigating Wireguard as a factory-supported replacement but am finding it doesn’t handle the modem connection dropping/reconnecting at all. But that’s for another thread

That’s strange - afraid I don’t know enough about the factory firmware extras and frontend to debug easily. I wonder if it was firewall related? There are wan and lan ‘zones’ in /etc/config/firewall; would the web front-end know to add the l2tp interface to the wan zone?

Hi,you can confirm this, look at the configuration of /etc/config/firewall
image

Hi, this shows wan, wan6 and wwan interfaces in the ‘wan’ zone. Is the l2tp one of these three? If not, possibly it needs adding here in the ‘option network’ line.

Hi Again,

Sorry for the delay in responding - I had cancelled by AANET account when I was unable to get this resolved with their support team.

To answer your question @ChrisW, yes I had put the l2tp interface in the wan zone and it didn’t seem to help.

In order to progress this, I’ve created a fork of a github repo that will stand up an unencrypted L2TP server in azure: GitHub - piratebriggs/setup-ipsec-vpn: Scripts to build your own IPsec VPN server, with IPsec/L2TP and Cisco IPsec on Ubuntu, Debian and CentOS

In it’s default config it’ll create a B1s server (~£6.50pcm) with a static public IP address.

So, I’ve now followed AANETs l2tp instructions again (https://support.aa.net.uk/L2TP_Client:_OpenWRT ) using my L2TP server in azure and suprisingly it’s “just worked” :slight_smile:

For reference, I’ve set the metric to 30 to be lower than the stock the LTE modem interface and added the l2tp interface to wan zone and that’s it.

I’m getting some good ping times from the Azure public IP so might run with that for a while. This won’t get me the ability to route traffic into my router (I don’t think) so that would be the driver on when to look at AANET again.

I spoke too soon! After restarting the Spitz, it reverted to routing lan traffic out of the LTE interface directly.

So I’ve just tried the trick you suggested of reporposing the ‘wan’ interface as the l2tp connection and that seems to have done the trick. I’ll keep an eye on it and resolve this thread if it proves stable.

Cheers!