How to Configure L2TP VPN in Azure Cloud — A Quick, Secure Step‑by‑Step Guide

Implementing an L2TP/IPsec VPN inside Microsoft Azure is a practical choice when you need client compatibility with legacy devices, simple layering of Layer 2 services, or interoperability with clients that rely on L2TP. Azure does not provide a native managed L2TP server; therefore, you must host the VPN server inside a Virtual Machine (VM) in your Virtual Network. This guide walks you through a secure, production-ready approach to deploying L2TP/IPsec on Azure using a Linux-based implementation (strongSwan + xl2tpd). The steps include network design, VM provisioning, firewall/NAT rules, detailed configuration files, client setup notes, troubleshooting tips, and security hardening recommendations.

Prerequisites and architectural overview

Before starting, ensure you have the following:

• An Azure subscription with permissions to create VMs, public IPs, NSGs, and route tables.
• A production-grade Ubuntu Server (20.04/22.04) or similar Linux distribution image for the VM.
• Basic familiarity with IPsec, L2TP, and Linux networking and iptables/nftables.
• Clients that support L2TP/IPsec (Windows, macOS, iOS, Android, Linux NetworkManager). Note: modern setups often prefer IKEv2 or OpenVPN/SSTP for better NAT traversal and security.

High-level architecture: a single VPN VM runs strongSwan (IPsec) + xl2tpd (L2TP) in an Azure Virtual Network subnet. The VM has a static Public IP attached directly to its NIC so IPsec traffic (NAT-T over UDP 4500) can be properly handled. An NSG restricts traffic to required UDP ports. IP forwarding and NAT (MASQUERADE) allow VPN clients to access VNet resources or the internet.

Step 1 — Create VNet, subnet and Network Security Group (NSG)

Create a Virtual Network and a subnet dedicated to VPN services (e.g., 10.1.0.0/24). Isolating VPN servers in their own subnet helps with security and routing control.

• VNet: 10.1.0.0/16
• VPN subnet: 10.1.1.0/24

Create an NSG for the VPN subnet (or attach to the VPN VM NIC) and allow only needed ports:

• Allow UDP 500 (IKE)
• Allow UDP 4500 (NAT-T — essential)
• Allow UDP 1701 (L2TP)
• Allow TCP/22 for administration from restricted management IPs only

Important: Do not open broad ephemeral port ranges or allow 0.0.0.0/0 to management ports. Restrict SSH/RDP to known admin IPs.

Step 2 — Provision the VM and attach a static Public IP

Provision an Ubuntu Server VM in the VPN subnet. Assign a Standard SKU Public IP and attach it to the VM’s NIC. Using a Public IP on the NIC (not through a load balancer) avoids protocol translation issues and simplifies IPsec operation.

• VM size: at least 2 vCPUs and 4 GB RAM for moderate usage; scale up for many concurrent clients.
• Storage: use managed disks (SSD recommended).
• Availability: place VM in an Availability Zone or use an Availability Set for HA considerations.

Step 3 — Basic OS hardening and prerequisites

Connect via SSH from a locked-down administrative IP. Then:

• Update OS: apt update && apt upgrade -y
• Install packages: strongswan, xl2tpd, ppp, iptables-persistent (or persist with nftables)
• Enable IP forwarding: edit /etc/sysctl.conf and set net.ipv4.ip_forward=1; then sysctl -p

Sample installation commands

On Ubuntu:

apt update && apt install -y strongswan xl2tpd ppp iptables-persistent

Step 4 — strongSwan (IPsec) configuration

strongSwan handles the IPsec layer and NAT-T. You can use pre-shared keys for simplicity, but for production use, use certificate-based authentication. Below are the essential config snippets.

/etc/ipsec.conf

Put a connection that accepts remote clients and assigns virtual IPs:

config setup
  uniqueids=never

conn L2TP-PSK
  keyexchange=ikev1
  authby=secret
  type=transport
  left=%any
  leftauth=psk
  leftsubnet=0.0.0.0/0
  leftfirewall=yes
  right=%any
  rightsourceip=10.2.0.0/24
  rightauth=psk
  rightprotoport=17/1701
  ike=aes256-sha1-modp1024!
  esp=aes256-sha1!
  dpdaction=clear
  auto=add

Notes:

• rightsourceip defines IPs assigned to VPN clients (choose a range not colliding with your VNet).
• leftsubnet=0.0.0.0/0 allows client traffic to be forwarded. Adjust to limit access to specific subnets.

/etc/ipsec.secrets

For PSK-based auth (replace with a strong secret or use certificates):

: PSK "YourVeryStrongPreSharedKeyHere"

Step 5 — xl2tpd and PPP setup

Configure xl2tpd to create L2TP tunnels and ppp options for authentication and DNS assignment.

/etc/xl2tpd/xl2tpd.conf

[global]
listen-addr = 0.0.0.0

[lns default]
ip range = 10.2.0.10-10.2.0.200
local ip = 10.2.0.1
require chap = yes
refuse pap = yes
require authentication = yes
ppp debug = no
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

/etc/ppp/options.xl2tpd

ipcp-accept-local
ipcp-accept-remote
ms-dns 8.8.8.8
ms-dns 8.8.4.4
auth
crtscts
lock
hide-password
modem
debug
name l2tpd
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4
mtu 1400
mru 1400

/etc/ppp/chap-secrets

Add user accounts for L2TP (format: username server password IP):

vpnuser    l2tpd    VeryStrongUserPassword    *

Step 6 — IP tables NAT and firewall

Enable NAT so VPN client traffic can reach the internet or VNet resources:

iptables -t nat -A POSTROUTING -s 10.2.0.0/24 -o eth0 -j MASQUERADE
iptables -A FORWARD -s 10.2.0.0/24 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Persist rules with iptables-persistent or convert to nftables. Replace eth0 with your VM NIC name.

Step 7 — Start services and verify

Restart services:

• systemctl restart strongswan
• systemctl restart xl2tpd

Use ipsec statusall and journalctl -u strongswan -u xl2tpd to debug. From a client, initiate the VPN and watch logs to confirm IKE negotiation and L2TP session establishment.

Client configuration highlights

Windows:

• Create a new VPN connection (Network & Internet > VPN).
• Type: L2TP/IPsec with pre-shared key (enter the PSK or configure certificate).
• Advanced properties > allow use of UDP 4500 (NAT-T) and set MTU to 1400 if encountering fragmentation.

macOS / iOS / Android:

• Create L2TP/IPsec profiles with PSK or certificates. Ensure NAT-T is enabled on client side (most OS do it automatically).

Troubleshooting common issues

• No IKE connection: Verify NSG allows UDP 500 and 4500 to the VM public IP. Check strongSwan logs for negotiation errors and PSK mismatches.
• L2TP connects but no traffic: Verify ip_forward is enabled and iptables MASQUERADE exists. Check client route table—set default route if you want all traffic to go through VPN.
• ESP packets dropped: Azure may drop protocol 50 when using certain load balancer configurations. Attach Public IP to NIC (not behind a standard LB), and ensure NAT-T (UDP 4500) is used.
• MTU/fragmentation: Set lower MTU (1400) in ppp options to avoid fragmentation across IPsec tunnels.

Security hardening and production considerations

While PSK is simple, it is less secure than certificate-based authentication. For production:

• Use certificate authentication with a private CA or Azure Key Vault integration for strongSwan certificates.
• Restrict NSG rules to trusted client IP ranges where possible.
• Enable logging and centralize to Azure Monitor or a SIEM for auditing.
• Regularly rotate PSKs and user credentials if PSK must be used.
• Keep the VM patched and minimize installed packages. Consider using an automated configuration management tool (Ansible, Chef) and image baking.
• For availability, run a second VPN VM in a different availability zone and use a public Front Door or load balancing strategy that supports IPsec (testing required). Alternatively, prefer managed Azure VPN Gateway (IKEv2/SSTP) or Azure Virtual WAN for enterprise scale.

When to choose alternatives

L2TP is widely supported but has limitations: NAT traversal complexity and reliance on PSK in many deployments. For improved security, performance, and native Azure integration consider:

• Azure VPN Gateway (native managed solution using IKEv2/SSTP or Route-based S2S/Point-to-site).
• OpenVPN or WireGuard on a VM for easier NAT traversal and simpler modern crypto.
• Azure Virtual WAN for multi-site scale and built-in redundancy.

Deploying L2TP/IPsec on Azure is feasible and effective when you follow secure practices: attach a public IP directly to your VM NIC, open only the necessary UDP ports (500, 4500, 1701), enable NAT-T, and use certificate-based authentication in production. The combination of strongSwan and xl2tpd provides a mature, flexible stack that supports many client platforms.

For more operational guidance, scripts, and step-by-step templates tailored for production deployments, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/, where we provide deep-dive posts and implementation resources.