Category:L2TP Handover: Difference between revisions

From AAISP Support Site
No edit summary
Line 20: Line 20:
=Setting up OpenL2TP=
=Setting up OpenL2TP=


The OpenL2TP [http://www.openl2tp.org/downloads download page] only mentions version 1.6. This didn't compile on squeeze without building the l2tp configuration parser by hand with byacc first. If you go to [ftp://ftp.openl2tp.org/releases/openl2tp-1.6 the FTP site] there is actually a version 1.7 available, which compiles straight out of the tarball.
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.
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.
Line 26: Line 26:
peer profile create profile_name=doubtless
peer profile create profile_name=doubtless
peer profile modify profile_name=doubtless \
peer profile modify profile_name=doubtless \
tunnel_profile_name=doubtless \
tunnel_profile_name=aaisp-in \
session_profile_name=doubtless \
session_profile_name=aaisp-in \
ppp_profile_name=doubtless \
ppp_profile_name=aaisp-in \
peer_ipaddr=90.155.53.0 \
peer_ipaddr=90.155.53.8 \
peer_port=1701 \
netmask=255.255.255.0 \

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 \
peer_port=1701 \
tunnel profile create profile_name=doubtless
tunnel profile create profile_name=aaisp-in
tunnel profile modify profile_name=doubtless \
tunnel profile modify profile_name=aaisp-in \
secret=<your secret here> \ # leave out if you don't want tunnel authentication
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
auth_mode=challenge \ # leave out if you don't want tunnel authentication
src_ipaddr=<your LNS IP> \
src_ipaddr=<your LNS IP> \
our_udp_port=1701 \
our_udp_port=1701 \
mtu=1500 \
peer_profile_name=doubtless \
peer_profile_name=aaisp-in \
session_profile_name=doubtless \
session_profile_name=aaisp-in \
ppp_profile_name=doubtless \
ppp_profile_name=aaisp-in \
session profile create profile_name=doubtless
session profile create profile_name=aaisp-in
session profile modify profile_name=doubtless \
session profile modify profile_name=aaisp-in \
ppp_profile_name=doubtless \
ppp_profile_name=aaisp-in \
ppp profile create profile_name=doubtless
ppp profile create profile_name=aaisp-in
ppp profile modify profile_name=doubtless \
ppp profile modify profile_name=aaisp-in \
auth_pap=yes \
auth_pap=yes \
auth_chap=yes \
auth_chap=yes \
Line 59: Line 67:
local_ipaddr=<IP address of LNS endpoint on PPP link> \
local_ipaddr=<IP address of LNS endpoint on PPP link> \
remote_ipaddr=<IP address to give to SIM> \
remote_ipaddr=<IP address to give to SIM> \
mtu=1280 \
mru=1280 \
trace_flags=1024 \


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.
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.
Line 67: Line 72:
=Authentication=
=Authentication=


Enabling tunnel authentication lets you be confident that you really are talking to doubtless 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 supplies a CHAP username (the SIM's ICCID), challenge and response which will be verified if you enable PPP proxy authentication, however I have not worked out the secret that is being used here!
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=
=Musings=
Line 73: Line 78:
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.
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 haven't yet worked out what the secret is that is being used to generate the response. It isn't the l2tp tunnel authentication secret, the proxy authentication username, the ICCID, or the password that was supplied to the modem.
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.


The 'calling number' and 'called number' in the incoming call request are the SIM's ICCID.
The 'calling number' and 'called number' in the incoming call request are the SIM's ICCID.
Line 81: Line 86:
=Things to do=
=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.
* Figure out what secret is used in the PPP proxy authentication.
* Use that (or something else) to identify individual SIMs and supply the correct IP address to each one.

Revision as of 16:59, 14 December 2010


Related Pages on the A&A Website:


Overview

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.

This page documents my experiments setting up an LNS for my RevMobile data SIMs.

For the LNS, I used OpenL2TP running on Linux (Debian 'squeeze'). I did some experiments with xl2tpd as well.

SIM Configuration

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.

Setting up OpenL2TP

The OpenL2TP 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.

The 'calling number' and 'called number' in the incoming call request are the SIM's ICCID.

The two devices that I've been using -- a Vodafone (Huawei) K4505 and a Nokia E51 -- behave noticeably differently when it comes to PPP and particularly IPCP.

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.

Pages in category 'L2TP Handover'

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