Category:Incoming L2TP: Difference between revisions

From AAISP Support Site
mNo edit summary
No edit summary
 
(81 intermediate revisions by 8 users not shown)
Line 1: Line 1:
__NOTOC__<indicator name="L2TP">[[File:Menu-L2TP.svg|link=:Category:L2TP|30px|Back up to the L2TP Category]]</indicator>
__NOTOC__<indicator name="L2TP">[[File:Menu-L2TP.svg|link=:Category:L2TP|30px|Back up to the L2TP Category]]</indicator>
= L2TP from Customers to AAISP =


There are two reasons to use L2TP to connect in to AAISP:
# As a backup for your existing AAISP circuit in the event of a fault.
#* Logging in over L2TP using your DSL credentials (ie xxx@a.1) from a different ISP will give you your normal IP addresses. You can use this whilst your AAISP connection is being fixed.
#* This is enabled by default and available to everyone, there are no extra charges. Usage is taken from your quota in the usual way as if you were connecting over DSL.
#* Speed & monthly usage are capped depending on the service you have, but these should be reasonable for most users - see the main website as it'll be described there.
#* Regarding IP routing, The L2TP has priority over the DSL, so you'd want to bring it up/down as and when required as the DSL won't have IPs routed to it when the L2TP is up.
# Connect in to AAISP over a third-party internet connection.
#* This gives you your an AAISP IPv4 address and an IPv6 block. This will then give you unfiltered internet access with public IP addresses etc.
#* Speed is capped at 200Mb/s (3Mb/s for the low-cost Light service).
#* There are more reasons for doing this and further information and ordering on [https://www.aa.net.uk/broadband/l2tp-service/ A&A L2TP service].


== Connection Details ==
=L2TP from Customers to AAISP=
* Endpoint:
This is used to connect in to AAISP over a third-party internet connection. This gives you your usual AAISP IP (4 and 6) blocks and access to the internet as if you were conencted via a normal DSL circuit.
** l2tp.aa.net.uk
** or l2tp6.aa.net.uk
* Username & Password as supplied
* Hostname: AAISP
* Authentication Protocol: CHAP/MSCHAPv2 or PAP, but recommend CHAP, as L2TP is not encrypted
* Plain L2TP '''without any IPsec'''. This is important as some devices may not support disabling encryption on L2TP, eg iPhones
* Check that your ISP/mobile provider does not have features that will block 'VPN' services - eg Vodafone's 'SecureNet' will block access to our L2TP service but can usually be disabled via the provider's control pages/App/etc
*Please use the DNS name (l2tp.aa.net.uk) instead of hardcoding an IP address; IP addresses can and do change. If you have to use an IP, use 194.4.172.12, but do check the DNS for l2tp.aa.net.uk in case it changes.
*Static routes? Some L2TP client's config needs to have a static route to route traffic to the L2TP server directly rather than through the tunnel(!) - in these cases you may need to add multiple static routes and keep them updated as the IPs that l2tp.aa.net.uk may change and increase over time.


=== Speed/Latency Tweaks ===
* Hostname: l2tp.aa.net.uk
See: [[L2TP-Latency-Speed-Tweaks]]
* Plain L2TP without any IPsec
* MSCHAPv2 authentication


=== MTU ===
You may have to set a lower MTU to accommodate the host ISP, possibly as low as 1462 (or lower for some ISPs and still lower for mobile networks). In theory fragments will work to allow 1500 MTU on our service, but fragments are inefficient, and if everyone sends fragmented packets that could degrade the service.


=== Port forwarding on some 'Mobile Broadband' routers ===
We have reports from a few customers who are using 4G/5G mobile data routers for 'mobile broadband' that whilst they do support L2TP they do not appear to port forward the static IP on the L2TP. The web UI suggests that port-forwarding can be configured, but this seems to only port-forward the IP address on the mobile data connection and not the IP address on the L2TP connection. We suggest that customers should report this as a bug to the supplier/manufacturer of the router. This can have an impact on using our L2TP service as these routers will be restricting the capabilities (ie port forwarding). A work-around is to to a separate Ethernet router on your LAN to establish the tunnel.


= Some Notes from customers setting up L2TP IN to AAISP: =
= Notes on setting up L2TP IN to AAISP: =
{{AAMenu|img=Menu-FireBrick.svg|link=L2TP_Client:_FireBrick|title=L2TP from FireBrick|text=Creating a L2TP connection from a FireBrick to AAISP}}

{{AAMenu|img=Menu-Apple.svg|link=L2TP_Client:_OSX|title=L2TP from OSX|text=Creating a L2TP connection from Apple OSX to AAISP}}
== FireBrick FB2500/2700 Fully Loaded ==
{{AAMenu|img=Menu-Apple.svg|link=L2TP_Client:_iOS|title=L2TP from iOS|text=Our L2TP service won't work from iOS (iPhones & iPads)}}

{{AAMenu|img=Menu-Windows.svg|link=L2TP_Client:_Windows|title=L2TP from Windows|text=Creating a L2TP connection from Windows to AAISP}}
The FireBrick can connect as an L2TP client for fallback and for its main connection. One thing to watch out for is making sure that the FB doesn't set its own gateway to be the tunnel (which would logically send tunnel packets up the tunnel, which is horrid). You can get around this by using separate routing tables.
{{AAMenu|img=Menu-Linux.svg|link=L2TP_Client:_Debian|title=L2TP from Debian|text=Creating a L2TP connection from Debian to AAISP using xl2tpd}}

{{AAMenu|img=Menu-Linux.svg|link=L2TP_Client:_Linux|title=L2TP from Linux|text=Creating a L2TP connection from Linux/Ubuntu/Network Manager to AAISP using xl2tpd}}
This example is for L2TP being the main connection:
{{AAMenu|img=Menu-Linux.svg|link=Router:Linux_-_Debian_-_With_L2TP_Fallback|title=L2TP Failover with Debian|text=Creating a L2TP fallback for AAISP using xl2tpd}}

{{AAMenu|img=Menu-Routerboard.svg|link=L2TP_Client:_Routerboard|title=L2TP from Routerboard|text=Creating a L2TP connection from Routerboard to AAISP}}
<interface name="WAN"
{{AAMenu|img=Menu-OpenWRT.svg|link=L2TP_Client:_OpenWRT|title=L2TP from OpenWRT|text=Creating a L2TP connection from OpenWRT to AAISP}}
port="WAN1"
{{AAMenu|img=Menu-Cisco.svg|link=L2TP_Client:_Cisco|title=L2TP from Cisco|text=Creating a L2TP connection from Cisco to AAISP}}
table="1"
{{AAMenu|img=Menu-voip.svg|link=L2TP_Client:_SNOM|title=L2TP from a SNOM VoIP Phone|text=Creating a L2TP connection from a SNOM phone to AAISP}}
comment="DHCP client">
{{AAMenu|img=Menu-router.svg|link=L2TP_Client:_Mobile_Broadband_Routers|title=L2TP from 4G/5G Huawei/Gigacube|text=Creating a L2TP connection 4G/5G Huawei/Gigacube type mobile broadband routers to AAISP}}

{{AAMenu|img=Menu-router.svg|link=L2TP_Client:_Other_Routers|title=L2TP from Other Routers|text=Generic information for creating a L2TP connection from other routers to AAISP (eg Netgear, TP-Link etc that are not listed here.}}
<l2tp>
{{AAMenu|img=Menu-router.svg|link=L2TP_Client:_Ubiquiti_Edgerouter|title=Ubiquiti|text=Problems with Ubiquiti Edgerouter.}}
<outgoing name="AAISP"
{{AAMenu|img=Menu-router.svg|link=L2TP_Client:_MikroTik_RouterBOARD_hEX|title=MikroTik|text=Create an L2TP connection from a MikroTik Routerboard.}}
ip="90.155.53.19"
{{AAMenu|img=Menu-router.svg|link=L2TP_Client:_OpenWRT_with_Policy_Based_Routing|title=OpenWRT-Policy Based Routing|text=Create an L2TP connection from a OpenWRT with Policy Based Routing.}}
graph="AAISP"
table="1"
payload-table="0"
username="example@a"
password="secret"
tcp-mss-fix="true"
comment="L2TP tunnel to AAISP"/>
</l2tp>

You can set to fall back to NAT if the tunnel is down. Traffic on routing table 0 won't have a default gateway if the L2TP is down, so will match this rule set that has target interface "nowhere":

<rule-set name="Fallback"
target-interface="nowhere"
no-match-action="continue"
comment="NAT fallback if can't establish L2TP">
<rule name="NAT"
set-nat="true"
set-table="1"
action="accept"/>
</rule-set>

If the L2TP is being used for fallback, you are probably better off setting the routing table for the L2TP to something other than 0. Remember firewall rules only apply to single routing tables.

== RouterBoard ==

Connecting to L2TP with a RouterBoard was pretty seamless - put in the L2TP server IP, username and password and it just connects. Have to mess about with IP / Route and NAT / masquerading a bit to get devices behind the RouterBoard online but that all depends on whether you have an additional IP block and what you want to do with it anyway.

==Apple OSX==
An Apple computer can be used to create an L2TP connection in to AAISP, here's how:

*Apple Menu - Settings - Network
*Click the + Icon
*Create a new VPN Interface with Type L2TP over IPSec
[[File:l2tp-osx-newconnection.png]]
*In the Authentication settings set the Password
*For ease of use Tick 'Show VPN status in menu bar
*Optionally, in the Advanced Settings Tick, 'Send all Traffic over VPN connection'
*Then Connect
[[File:l2tp-osx-connected.png]]
*To Disconnect, click Disconnect

You can use the new icon in the Status bar (Up by the clock, to connect and disconnect the connection

[[File:l2tp-osx-ipsecmenu.png]]

===VPN Connection - IPsec Error===
Use this at your own risk. The notes below involves editing/creating system files, and whilst 'worked for us' may not work for you.

By default, OSX requires the L2TP connection to use IPSec encryption. At the moment the AAISP service is just plain L2TP and does not offer encryption.

[[File:L2tp-osx-ipsecerror.png]]

To enable OSX to connect without IPSec, then the /etc/ppp/options file needs to be edited. A simple way of doing this is as follows:

#Use the Search icon to search for Terminal
[[File:osx-finding-terminal.png]]

and then enter in:

echo "plugin L2TP.ppp" > options
echo "l2tpnoipsec" >> options
sudo mv options /etc/ppp

If the mv (move) fails, then you may already have a /etc/ppp/options file, in this case it would need to be edited manually.

To undo this change delete the /etc/ppp/options file.

== Windows 7 ==

Connecting with Windoze 7 was almost as easy except that the default connection settings don't work. You have to edit the connection properties and on the Security tab change 'Type of VPN:' to 'Layer 2 Tunneling Protocol with IPsec (L2TP/IPSec)' otherwise it only tries PPTP, and change 'Data encryption:' to 'Optional encryption (connect even if no encryption)' as it doesn't like A+A's certificate (because RevK declines to use a root certification authority recognised by Microsoft, or is it that Microsoft declines to recognise the root certification authority chosen by RevK). I guess the alternative would probably be to add the root certificate to the machine in question. Anyway, with those two changes it works fine.

Watch out if you are using [[IPv6]]. It seems that Win7 negotiates a non-routable [[IPv6]] address with the LNS. You have to discard this address and manually configure one of your routed [[IPv6]] addresses. ipconfig /release6 is your friend here.

== Cisco Routers ==

Cisco routers running IOS 12.3(2)T and later support L2TP client initiated tunneling which allows the router to establish an L2TP tunnel to A&amp;A's L2TP server.

Most of the information required was gleaned from here: [http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gtvoltun.html] plus a bit of trial and error and some packet capturing of good and bad L2TP sessions.

I have tested this on a Cisco 837 router running 12.3(11)YZ2, a 2821 running 12.4(15)T10 SPServices and a 2801 running 12.4(24)T3 ADVIPServices

'''Caveats:'''

- You will need to sanity check routing in your particular environment. This is especially important if you choose to use '''ppp ipcp route default''' on the l2tp tunnel. It's safest to make sure that you have a static route set to the L2TP server.

- I haven't tested this for [[IPv6|IPV6]] yet.

- This is "early release" information - I haven't yet used this in anger over a long period of time but will try to remember to come back and update if I find any major issues.

- This config snippet contains no security settings - be sure to configure some!

- I've used the IP address of the L2TP server rather than the DNS address - this is obviously at risk of change .

- You need to be running IP CEF on the router

'''Config:'''

Replace ''&lt;whatever&gt;'' with the appropriate information for your connection

ip cef
l2tp-class lc-aaisp
pseudowire-class pc-aaisp
encapsulation l2tpv2
protocol l2tpv2 lc-aaisp
ip local interface ''&lt;interface that l2tp connection should go out from&gt;''
interface Virtual-PPP9797
shutdown
ip address negotiated
no cdp enable
ppp authentication chap callin
ppp chap hostname ''&lt;l2tp line login eg stzzz@a.2&gt;''
ppp chap password 0 ''&lt;site password&gt;''
ppp direction callout
ppp pap refuse
pseudowire 90.155.53.19 10 pw-class pc-aaisp

Once the interface is configured you can issue a '''no shut''' on it to bring it up.

'''Debugging:'''

'''debug ppp authentication''' and '''debug ppp negotiation''' are your friends... In particular if you see "Circuit ID not set - contact support" in the authentication debug, contact A&amp;A support to get them to fix your L2TP login.

Once the connection is up, you should see the virtual PPP interface configured with the static IP that is assigned to it in clueless.

If you get stuck, pop into the IRC channel and see if I'm around (basil_uk) and I'll help if possible.

== OpenWRT ==

I'll give details about doing things without LuCI - if you want to do it through the web UI, it should be obvious from the text config what you need to twiddle.

Tested with the following package versions -

kmod-l2tp - 3.18.10-1
kmod-l2tp-eth - 3.18.10-1
kmod-l2tp-ip - 3.18.10-1
kmod-pppol2tp - 3.18.10-1
ppp-mod-pppol2tp - 2.4.7-5
xl2tpd - 1.3.6-5619e1771048e74b729804e8602f409af0f3faea
luci-proto-ipv6 - git-15.090.50849-576e235-1
luci-proto-ppp - git-15.090.50849-576e235-1

You'll first need to create a static route for <code>l2tp.aa.net.uk</code> via your bulk interface (usually <code>wan</code>) in <code>/etc/config/network</code> -

config route
option interface 'wan'
option target '90.155.53.19'

Then add the tunnel to <code>/etc/config/network</code> - note that even though we enable it, the interface won't get an IPv6 address. Fear not, we can fix that in a minute.

config interface 'aaisp'
option proto 'l2tp'
option server 'l2tp.aa.net.uk'
option username 'yourusername@a'
option password 'YOURPASSWORD'
option ipv6 '1'
option peerdns '0'
option metric '50'

Next let's configure DHCPv6 over the tunnel interface since PPP IPV6CP doesn't seem to work properly. Again in <code>/etc/config/network</code> - edit to taste if you don't want to gobble up your entire /48. Though this shows as a separate interface in OpenWRT-land, they'll both assign addresses to the same underlying interface, 'l2tp-aaisp'.

config interface 'aaisp6'
option proto 'dhcpv6'
option reqprefix '48'
option peerdns '0'
option _orig_ifname 'aaisp'
option _orig_bridge 'false'
option ifname 'l2tp-aaisp'
option reqaddress 'force'

Now we have -

* All IPv4 traffic going out of our bulk WAN interface (metric 0)
* The L2TP tunnel has its default gateway set, but unused (metric 50)
* All IPv6 traffic going out of the tunnel (haven't tested what would happen if your bulk interface was also IPv6 capable)
* DNS unchanged from original setup (I use dnscrypt-proxy and some REDIRECT iptables plumbing to secure DNS query traffic)

Next steps

* iptables PREROUTING rules to mark traffic that should egress via the tunnel
* iproute2 magic to route the marked traffic properly
* a painful sense of irony that we're dodging nasty shaping and filtering on our bulk interface only to do it ourselves
* a really sweet hat

Prod me (<code>daveio</code>) on IRC if you have trouble, I'll try to assist if I'm around.

== Linux / xl2tpd ==

<ol>
<li>Ensure the following kernel options are set or the corresponding modules are available:</li>
<ol>
<li><code>CONFIG_PPPOL2TP</code>
<li><code>CONFIG_L2TP</code>
</ol>
<li>Install xl2tpd and pppd on your Linux router.</li>
<li>Edit <code>/etc/xl2tpd/xl2tpd.conf</code> to contain the following:<br />
<code>[lac aaisp]<br />
lns = l2tp.aaisp.net.uk<br />
require authentication = no<br />
pppoptfile = /etc/ppp/options.aaisp</code></li>
<li>Create <code>/etc/ppp/options.aaisp</code> containing the following (obviously change the name and password to match your L2TP login details):<br />
<code>+ipv6<br />
ipv6cp-use-ipaddr<br />
name xyz@a.X<br />
password Your_xyz@A.X_password<br />
noauth</code></li>
<li>Create the xl2tpd control file:<br />
<code>mkdir -p /var/run/xl2tpd<br />
touch /var/run/xl2tpd/l2tp-control</code></li>
<li>Start the xl2tpd service (for systemd, use service command for older RC systems):<br />
<code>systemctl start xl2tpd</code></li>
<li>Tell the daemon to connect to aaisp:<br />
<code>echo "c aaisp" > /var/run/xl2tpd/l2tp-control</code></li>
</ol>
This should give you a new PPP device which encapsulates the L2TP connection.

== Other Hardware ==

The TL-WR741ND router works, although it can only do NAT, but is very cheap.


[[Category:L2TP]]
[[Category:L2TP]]

Latest revision as of 14:26, 5 March 2024

L2TP from Customers to AAISP

There are two reasons to use L2TP to connect in to AAISP:

  1. As a backup for your existing AAISP circuit in the event of a fault.
    • Logging in over L2TP using your DSL credentials (ie xxx@a.1) from a different ISP will give you your normal IP addresses. You can use this whilst your AAISP connection is being fixed.
    • This is enabled by default and available to everyone, there are no extra charges. Usage is taken from your quota in the usual way as if you were connecting over DSL.
    • Speed & monthly usage are capped depending on the service you have, but these should be reasonable for most users - see the main website as it'll be described there.
    • Regarding IP routing, The L2TP has priority over the DSL, so you'd want to bring it up/down as and when required as the DSL won't have IPs routed to it when the L2TP is up.
  2. Connect in to AAISP over a third-party internet connection.
    • This gives you your an AAISP IPv4 address and an IPv6 block. This will then give you unfiltered internet access with public IP addresses etc.
    • Speed is capped at 200Mb/s (3Mb/s for the low-cost Light service).
    • There are more reasons for doing this and further information and ordering on A&A L2TP service.

Connection Details

  • Endpoint:
    • l2tp.aa.net.uk
    • or l2tp6.aa.net.uk
  • Username & Password as supplied
  • Hostname: AAISP
  • Authentication Protocol: CHAP/MSCHAPv2 or PAP, but recommend CHAP, as L2TP is not encrypted
  • Plain L2TP without any IPsec. This is important as some devices may not support disabling encryption on L2TP, eg iPhones
  • Check that your ISP/mobile provider does not have features that will block 'VPN' services - eg Vodafone's 'SecureNet' will block access to our L2TP service but can usually be disabled via the provider's control pages/App/etc
  • Please use the DNS name (l2tp.aa.net.uk) instead of hardcoding an IP address; IP addresses can and do change. If you have to use an IP, use 194.4.172.12, but do check the DNS for l2tp.aa.net.uk in case it changes.
  • Static routes? Some L2TP client's config needs to have a static route to route traffic to the L2TP server directly rather than through the tunnel(!) - in these cases you may need to add multiple static routes and keep them updated as the IPs that l2tp.aa.net.uk may change and increase over time.

Speed/Latency Tweaks

See: L2TP-Latency-Speed-Tweaks

MTU

You may have to set a lower MTU to accommodate the host ISP, possibly as low as 1462 (or lower for some ISPs and still lower for mobile networks). In theory fragments will work to allow 1500 MTU on our service, but fragments are inefficient, and if everyone sends fragmented packets that could degrade the service.

Port forwarding on some 'Mobile Broadband' routers

We have reports from a few customers who are using 4G/5G mobile data routers for 'mobile broadband' that whilst they do support L2TP they do not appear to port forward the static IP on the L2TP. The web UI suggests that port-forwarding can be configured, but this seems to only port-forward the IP address on the mobile data connection and not the IP address on the L2TP connection. We suggest that customers should report this as a bug to the supplier/manufacturer of the router. This can have an impact on using our L2TP service as these routers will be restricting the capabilities (ie port forwarding). A work-around is to to a separate Ethernet router on your LAN to establish the tunnel.

Notes on setting up L2TP IN to AAISP:

Menu-FireBrick.svg

L2TP from FireBrick

Creating a L2TP connection from a FireBrick to AAISP

Menu-Apple.svg

L2TP from OSX

Creating a L2TP connection from Apple OSX to AAISP

Menu-Apple.svg

L2TP from iOS

Our L2TP service won't work from iOS (iPhones & iPads)

Menu-Windows.svg

L2TP from Windows

Creating a L2TP connection from Windows to AAISP

Menu-Linux.svg

L2TP from Debian

Creating a L2TP connection from Debian to AAISP using xl2tpd

Menu-Linux.svg

L2TP from Linux

Creating a L2TP connection from Linux/Ubuntu/Network Manager to AAISP using xl2tpd

Menu-Linux.svg

L2TP Failover with Debian

Creating a L2TP fallback for AAISP using xl2tpd

Menu-Routerboard.svg

L2TP from Routerboard

Creating a L2TP connection from Routerboard to AAISP

Menu-OpenWRT.svg

L2TP from OpenWRT

Creating a L2TP connection from OpenWRT to AAISP

Menu-Cisco.svg

L2TP from Cisco

Creating a L2TP connection from Cisco to AAISP

Menu-voip.svg

L2TP from a SNOM VoIP Phone

Creating a L2TP connection from a SNOM phone to AAISP

Menu-router.svg

L2TP from 4G/5G Huawei/Gigacube

Creating a L2TP connection 4G/5G Huawei/Gigacube type mobile broadband routers to AAISP

Menu-router.svg

L2TP from Other Routers

Generic information for creating a L2TP connection from other routers to AAISP (eg Netgear, TP-Link etc that are not listed here.

Menu-router.svg

Ubiquiti

Problems with Ubiquiti Edgerouter.

Menu-router.svg

MikroTik

Create an L2TP connection from a MikroTik Routerboard.

Menu-router.svg

OpenWRT-Policy Based Routing

Create an L2TP connection from a OpenWRT with Policy Based Routing.