L2TP over IPsec

https//www.racom.eu/eng/products/m/midge/app/vpn/l2tp.html

Print version

4. L2TP over IPsec

The Layer 2 Tunneling Protocol is a tunneling protocol which does not support any encryption or confidentiality. It relies on an encryption protocol that it passes within the tunnel to provide privacy. L2TPv3 is supported. Tunnel can be bridged to the local interfaces.

In this example, IPsec is configured to provide mentioned encryption and confidentiality. The topology is very simple, just point-to-point and connecting devices within 192.168.1.0/24 LAN subnet over M!DGE2 cellular connection (private APN).

[Note]Note

The L2TP is supported in M!DGE2 since the FW version 4.3.40.100.

Topology diagram, L2TP over IPsec

Fig. 4.1: Topology diagram, L2TP over IPsec


[Note]Note

Only L2TP and IPsec parameters are displayed and explained. Configuring private APN, ETH IP addresses etc. is not included.

4.1. L2TP Configuration

M!DGE2 A

Go to the VPN -> L2TP -> Tunnel configuration menu.

M!DGE2 A - L2TP configuration

Fig. 4.2: M!DGE2 A – L2TP configuration


Parameters:

Operational mode

enabled

Transport protocol

IP (default value, UDP can be better in environment with NAT and firewalls)

Local IP

10.203.3.28 (local WWAN IP address)

Remote IP

10.203.3.33 (remote WWAN IP address)

Local Tunnel ID

1 (L2TP tunnel numeric ID of local unit)

Remote tunnel ID

2 (L2TP tunnel numeric ID of remote unit)

Local Session ID

1 (L2TP tunnel session ID of local unit)

Remote Session ID

1 (L2TP tunnel session ID of remote unit)

Local Cookie

12345678 (optional parameter, 8digit value)

Remote Cookie

87654321 (optional parameter, 8digit value)

MTU

1488 Bytes (default)

Bridge interface

LAN1 (the interface for which we create “pseudowire” over L2TP)

Apply the changes and enable the L2TP in Administration menu.

L2TP administration

Fig. 4.3: L2TP administration


M!DGE2 B

Do the same configuration in B unit as well, but just switch the IPs, IDs and cookies so they match each other with A unit.

M!DGE2 B - L2TP settings

Fig. 4.4: M!DGE2 B – L2TP settings


This should enable non-secure L2TP only communication between our M!DGE2 units and all devices connected via LAN1 in 192.168.1.0/24 network. You can verify the accessibility via PING tool.

Run the PING to verify accessibility

Fig. 4.5: Run the PING to verify accessibility


Check the results.

PING results over L2TP non-secure tunnel

Fig. 4.6: PING results over L2TP non-secure tunnel


4.2. IPsec configuration

Go to the VPN -> IPsec -> Configuration menu and configure the IPsec tunnel.

M!DGE2 A

M!DGE2 A – General IPsec configuration

Fig. 4.7: M!DGE2 A – General IPsec configuration


Parameters:

Remote peer address

0.0.0.0 (passive mode)

Other values can stay in default or set them as required. Set the IKE Proposal to match 2nd M!DGE2.

M!DGE2 A – IPsec IKE Proposal

Fig. 4.8: M!DGE2 A – IPsec IKE Proposal


Configure the parameters as required. We configured the IKEv2 with PSK “midge”. The IDs are set to FQDN “midge1” and “midge2”. Other parameters are in default settings.

M!DGE2 A – IPsec Proposal

Fig. 4.9: M!DGE2 A – IPsec Proposal


The Encapsulation mode is important. Set it to Transport mode, otherwise it will not work. The mode enables usage with other tunneling protocols such as L2TP or GRE.

Check the Force encapsulation to make sure IPsec runs over UDP.

M!DGE2 A – IPsec Networks

Fig. 4.10: M!DGE2 A – IPsec Networks


This can seem strange, but the WWAN IP addresses must be set as networks so that L2TP (or GRE) is built over IPsec – i.e. once IPsec is up, all the communication between these 2 units is via IPsec tunnel.

M!DGE2 B

Do almost the same configuration as with M!DGE2 A. See the screenshots below.

M!DGE2 B – General IPsec configuration

Fig. 4.11: M!DGE2 B – General IPsec configuration


Make sure to provide correct Peer address – i.e. M!DGE A WWAN IP (10.203.3.28). The DPD action can be “restart”.

M!DGE2 B – IPsec IKE Proposal

Fig. 4.12: M!DGE2 B – IPsec IKE Proposal


Make sure to set parameters the same as in M!DGE2 A, but with switched IDs. IPsec proposal is the same. The Networks are just switched.

M!DGE2 B – IPsec networks

Fig. 4.13: M!DGE2 B – IPsec networks


Enable IPsec on both ends and wait until the tunnel is established.

IPsec tunnel being up

Fig. 4.14: IPsec tunnel being up


Verify the remote LAN IP accessibility again.

Ping accessibility test

Fig. 4.15: Ping accessibility test


It is not visible if it really utilizes IPsec or just L2TP. For such a purpose, capture the WWAN traffic and open the file in Wireshark application.

Start tcpdump, excluding management ports.

Tcpdump capture

Fig. 4.16: Tcpdump capture


Click on the start button. Then, run the PING command in second M!DGE2 unit.

PING to remote unit

Fig. 4.17: PING to remote unit


After the test finishes, download the tcpdump file. Unzip this file and open the saved file in Windows/Linux application called Wireshark. Check that most of data are ESP (i.e. IPsec encapsulated). If not, check your configuration.

Wireshark ESP/IPsec example output

Fig. 4.18: Wireshark ESP/IPsec example output


GRE over IPsec

The very the same principles are used for GRE tunnel over IPsec. Configure IPsec the same way. Configure GRE tunnel for Routing purposes – it is NOT connecting Layer2 devices, but Layer3 (IP). Thus, it requires different LAN subnets at individual sites, e.g. 192.168.1.0/24 and 192.168.2.0/24.

GRE over IPsec example

Fig. 4.19: GRE over IPsec example


Do the opposite site the same way, just mirror the parameters. If IPsec is disabled, you should see unencrypted data on WWAN encapsulated to GRE (new network 172.16.1.x). Once IPsec is enabled, you will see ESP data again.

©  2024 RACOM s.r.o. All Rights Reserved.