Latest revision as of 21:00, 11 August 2019

Mobile and DSL L2TP Handover: Overview

Our "data-only" SIMs allow for the possibility of L2TP hand over to your own LNS. (Note: our SIP2SIM SIMs don't have this ability - sorry)

Less common, but still possible, is relaying a DSL circuit to your own LNS, eg, an ADSL, VDSL, FTTP etc circuit.

This means that the data SIM (or DSL line) connects directly in to your network, and you control the IP address allocation, routing and any fire-walling or filtering as you wish.

The settings for a SIM can be set on the control pages. For DSL connections the L2TP settings are set by staff, so please do contact them for any changes or setup. The information that would be requested is:

Target IP (with an optional backup IP) - the L2TP server at your side
Host - the hostname we present
Secret - the password we use (optional)

SIM Configuration

Accessing This Feature

Access is via the Control Pages as follows:

Log in to the Control Pages with your xxx@a login
Click on the SIM ICCID you want to edit
Fill in the L2TP relay information there

You can enter the IP address of your LNS (and an alternative if you like), and a shared secret if you want to do tunnel authentication.

L2TP relay settings on the Control Pages

DSL Configuration

Wholesalers will usually already have their configuration set to relay based on their realm.
For individual circuits please contact staff to set up relaying on to your own L2TP server.

Technical Pages

For more technical information, please see:

Device Configuration

See the pages below for example configurations of L2TP servers.

Pages in category 'L2TP Handover'

The following 5 pages are in this category, out of 5 total.

F

FireBrick L2TP Server

L

L2TP Tunnels and Credentials

M

O

OpenL2TP

@@ Line 1: / Line 1: @@
+<indicator name="Front">[[File:Menu-datasim.svg|link=:Category:Data SIMs|30px|Back up to the Data SIM Category Page]]</indicator><indicator name="L2TP">[[File:Menu-L2TP.svg|link=:Category:L2TP|30px|Back up to the L2TP Category]]</indicator>
-[[Category:Configuring]]
+= Mobile and DSL L2TP Handover: Overview =
-[[Category:L2TP]]
+Our "data-only" SIMs allow for the possibility of L2TP hand over to your own LNS. (Note: our SIP2SIM SIMs don't have this ability - sorry)
-[[Category:Mobile]]
-[[Category:Control Pages]]
-[[Category:Internet]]
+Less common, but still possible, is relaying a DSL circuit to your own LNS, eg, an ADSL, VDSL, FTTP etc circuit.
+This means that the data SIM (or DSL line) connects directly in to your network, and you control the IP address allocation, routing and any fire-walling or filtering as you wish.
-=Related Pages on the A&A Website:=
-*[http://www.aaisp.net.uk/kb-telecoms-mobilel2tp.html www.aaisp.net.uk/kb-telecoms-mobilel2tp.html]
-----
+The settings for a SIM can be set on the control pages. For DSL connections the L2TP settings are set by staff, so please do contact them for any changes or setup. The information that would be requested is:
-= Overview =
+*Target IP (with an optional backup IP) - the L2TP server at your side
-Data SIMs from A&A can be terminated at A&A (in which you'll get a static public IP) or A&A can relay the L2TP on to your own server.
+*Host - the hostname we present
+*Secret - the password we use (optional)
-=SIM Configuration=
+==SIM Configuration==
+{{CPbox|#Click on the SIM ICCID you want to edit
-At the moment you need to ask staff to set up L2TP handover on a SIM (either on IRC, or email support@. You will need to give them the ICCID, the IP address of your LNS, and a shared secret if you want to do tunnel authentication. More on that later.
+#Fill in the L2TP relay information there}}
+You can enter the IP address of your LNS (and an alternative if you like), and a shared secret if you want to do tunnel authentication.
 [[File:Clueless-SIM-l2tp.png|none|frame|L2TP relay settings on the Control Pages]]
+==DSL Configuration==
+*Wholesalers will usually already have their configuration set to relay based on their realm.
+*For individual circuits please contact staff to set up relaying on to your own L2TP server.
+=Technical Pages=
-=Your L2TP Server Settings=
+For more technical information, please see:
+*[[L2TP Tunnels and Credentials|L2TP Sessions and Credentials]]
+*[[Mobile L2TP Technical|Mobile L2TP Technical information]]
+=Device Configuration=
-==Setting up L2TP Server on FireBrick==
+See the pages below for example configurations of L2TP servers.
-[[File:L2tp-sessions.png|none|frame|FireBrick Status Page]]
-Please see this page:
-[[FireBrick L2TP Server]]
+[[Category:Data SIMs]]
-==Setting up OpenL2TP==
+[[Category:L2TP]]
-This page documents my experiments setting up an LNS for my RevMobile data SIMs, also see [[FireBrick L2TP Server|How to set up L2TP on a FireBrick]].
-For the LNS, I used [http://www.openl2tp.org/ OpenL2TP] running on Linux ([http://www.debian.org/ Debian] 'squeeze'). I did some experiments with xl2tpd as well.
-The OpenL2TP [http://www.openl2tp.org/downloads download page] offers version 1.8, which compiles straight out of the tarball.
-This is the configuration I'm using -- with my IP addresses and tunnel secret removed, naturally! If you don't want tunnel authentication, leave out the 'secret=' and 'auth_mode=' lines.
- peer profile create profile_name=doubtless
- peer profile modify profile_name=doubtless \
- 	tunnel_profile_name=aaisp-in \
- 	session_profile_name=aaisp-in \
- 	ppp_profile_name=aaisp-in \
- 	peer_ipaddr=90.155.53.8 \
- 	peer_port=1701 \
- peer profile create profile_name=careless
- peer profile modify profile_name=careless \
- 	tunnel_profile_name=aaisp-in \
- 	session_profile_name=aaisp-in \
- 	ppp_profile_name=aaisp-in \
- 	peer_ipaddr=90.155.53.9 \
- 	peer_port=1701 \
- tunnel profile create profile_name=aaisp-in
- tunnel profile modify profile_name=aaisp-in \
- 	secret=<your secret here> \	# leave out if you don't want tunnel authentication
- 	auth_mode=challenge \		# leave out if you don't want tunnel authentication
- 	src_ipaddr=<your LNS IP> \
- 	our_udp_port=1701 \
- 	mtu=1500 \
- 	peer_profile_name=aaisp-in \
- 	session_profile_name=aaisp-in \
- 	ppp_profile_name=aaisp-in \
- session profile create profile_name=aaisp-in
- session profile modify profile_name=aaisp-in \
- 	ppp_profile_name=aaisp-in \
- ppp profile create profile_name=aaisp-in
- ppp profile modify profile_name=aaisp-in \
- 	auth_pap=yes \
- 	auth_chap=yes \
- 	auth_mschapv1=no \
- 	auth_mschapv2=no \
- 	auth_eap=no \
- 	auth_none=yes \
- 	auth_peer=no \
- 	dns_ipaddr_pri=<DNS IP to give to SIM> \
- 	local_ipaddr=<IP address of LNS endpoint on PPP link> \
- 	remote_ipaddr=<IP address to give to SIM> \
-I needed the src_ipaddr line in the tunnel profile because my LNS machine has several IP addresses on the same subnet, and the one that the LNS should be using is not the primary IP. openl2tp does not record the IP address that an l2tp packet came to and use that as the source address for the reply ... adding src_ipaddr fixes that.
-===Authentication===
-Enabling tunnel authentication lets you be confident that you really are talking to doubtless or careless, and not some other LAC. Without it you are limited to just trusting the incoming IP address. What this doesn't do is authenticate the individual PPP sessions over the tunnel. doubtless and careless supply a CHAP username (the SIM's ICCID), challenge and response which will be verified if you enable PPP proxy authentication. The secret that is used is so obvious that it took me nearly 2 months to work it out. It's "password", without the quotes.
-===Musings===
-PPP over GPRS connections is a bit, well, weird. The PPP connection that pppd on your laptop establishes is not all the way through to your LNS as you might expect. It isn't even terminated in the mobile network -- it's actually terminated on the modem. What this means is that the username and password you give to pppd are verified by the modem -- which just accepts anything you supply.
-The proxy authentication username that the LAC presents is a UK 07xxx phone number. It also presents a CHAP authentication ID, challenge and response. These are ignored unless you enable allow_ppp_proxy.
-I gather that there is an option to pass the username and password that were supplied to the modem all the way through to the LNS, this would replace the phone number and 'password'. Haven't tried this yet.
-The 'calling number' and 'called number' in the incoming call request are the SIM's ICCID.
-[[Mobile_IPv6|IPv6]]
-===Things to do===
-Work out how to identify individual SIMs and supply the correct IP address to each one. If you set 'auth_none' to 'no' in the ppp profile then PPP forces the other end to authenticate -- this is separate from the PPP proxy authentication although it uses the same username and secret. The username is currently a telephone number (447...) so I think I can use that.
-I've got this working, in as much as it allows entries in the LNS's chap-secrets to contain IP addresses and the correct one is passed to the modem. However (at least on pppd 2.4.5 with openl2tp 1.8) I haven't found a way to set the IP address on the LNS's end of the link. If you use the '-- local:remote' syntax in chap-secrets it picks up the remote IP but not the local one.
-Another bit of fun is that at the moment the IP address on the LNS's end of the PPP link doesn't get communicated to the other end. It goes out to the LAC okay, which accepts it, but never passes it on. (I think I once saw it work with a data SIM that was connecting directly to A&A, but that doesn't seem to happen any more either.) To be honest, this in itself isn't that great a problem. However ...
-Windows 7, and the Vodafone Mobile Broadband software (the Mac version works nicely with non-Vodafone SIMs, the Windows one doesn't, go figure) treat suitably capable 3G devices essentially as if they were Ethernet interfaces, rather than PPP devices. There's lots of interesting magic going on in there that I haven't figured out, but what they try to do is figure out a netmask and default gateway based on the IP address they're given. If you supply the second or third IP in a /30 for instance, they pick the other one as the default gateway. I want to see if and how this behaviour changes if the server end's IP address gets passed through correctly.
-My Huawei K4505 doesn't offer a remote address if it doesn't get one from the peer. In this situation, Linux picks 10.64.64.64. My Nokia E51 offers 10.6.6.6 in this situation.
-===PPP observations===
-Microsoft's PPP implementations up to and including Vista still believe in classful addressing. If you don't want the PPP interface to be the default route, then if they are given a 'class A' address they assume a netmask of 255.0.0.0 and set a corresponding network route, similarly for class B and C addresses. Windows 7 has the option to disable this automatic classful route if you don't set the default route. Nice one Microsoft :-)
-The Linux pppd understands the concept of point-to-point, non-broadcast links and gets it right.
-Mac OS X, despite using the same pppd, manages to muck things up, however this can be fixed with suitable runes in /etc/ppp/ip-up:
- # Remove the network route that pppd 'helpfully' sets up for us, which we don't need, and which just gets in the way.
- O1=$(echo $IPLOCAL | sed 's/\..*//')
- if [ "$O1" -le 127 ] ; then
-   # Class A -- netmask 255.0.0.0
-   /sbin/route delete -interface -net $O1.0.0.0 $IFNAME 255.0.0.0 >> /var/log/ppp-ip-updown.log
- elif [ "$O1" -le 191 ] ; then
-   # Class B -- netmask 255.255.0.0
-   O12=$(echo $IPLOCAL | sed 's/\.[0-9]*\.[0-9]*$//')
-   /sbin/route delete -interface -net $O12.0.0 $IFNAME 255.255.0.0 >> /var/log/ppp-ip-updown.log
- else
-   # Class C -- netmask 255.255.255.0
-   # (This will also pick up class D and E, which I doubt we'll be given!)
-   O123=$(echo $IPLOCAL | sed 's/\.[0-9]*$//')
-   /sbin/route delete -interface -net $O123.0 $IFNAME 255.255.255.0 >> /var/log/ppp-ip-updown.log
- fi
-Yes, it's hacky!