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?
@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 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:
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
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. 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, 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.
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.