L2TP/IPSec having trouble on multi-homed setup.

RouterOS General
1

Hi all,

I’m trying to set up an L2TP/IPSec service on an RB493G (RouterOS 5.12). The target clients are Android and iOS devices. This is a full ESP tunnel, using NAT-Traversal.

The RB has 4 active connections:

  • Leased line a.b.c.192/27 (pref source: a.b.c.205 - Tunnel address: a.b.c.198)
  • A DSL line, e.h.g.235/32
  • A DMZ (10.0.0.0/24)
  • The LAN (192.168.1.0/24)

The default route out for traffic is the DSL line, but I’m using only the leased line for the VPN. I’m marking routes for inbound leased line connection to ensure outbound traffic goes the right way.

So far, I have the IPSec phase working well and phase one and two complete successfully. The problem arises during L2TP handshaking. I can see the client sending SCCRQ packets, and the server is attempting to send SCCRP packets, but these responses never reach the client.

Using the packet sniffer, I can see that the outbound UDP 1701 packets are routing out over the leased line, as intended, but they’re using the preferred source address and not the tunnel address. If I understand it correctly, this means the packets don’t match the IPSec policy and aren’t tunnelled.

The end result is that the two endpoints repeatedly bark SCCRQ and SCCRP at each other until the connection times out.

Is there something special I need to do to set the correct source address of the L2TP traffic in such a scenario?

Config is as follows:

/ip ipsec peer print
Flags: X - disabled 
 0   address=0.0.0.0/0 port=500 auth-method=pre-shared-key secret="<key>" generate-policy=yes 
     exchange-mode=main send-initial-contact=no nat-traversal=yes my-id-user-fqdn="" proposal-check=obey 
     hash-algorithm=sha1 enc-algorithm=aes-128 dh-group=modp1024 lifetime=1d lifebytes=0 
     dpd-interval=disable-dpd dpd-maximum-failures=1 

> /ip ipsec proposal print
Flags: X - disabled, * - default 
 0  * name="default" auth-algorithms=sha1 enc-algorithms=3des,aes-128,aes-192,aes-256 lifetime=30m pfs-group=modp1024

> /interface l2tp-server server print
          enabled: yes
          max-mtu: 1460
          max-mru: 1460
             mrru: disabled
   authentication: pap,chap,mschap1,mschap2
  default-profile: L2TP

> /ppp profile print           
Flags: * - default 
 0 * name="default" use-mpls=default use-compression=default use-vj-compression=default use-encryption=default 
     only-one=default change-tcp-mss=yes 

 1   name="L2TP" local-address=L2TP remote-address=L2TP use-mpls=default use-compression=no use-vj-compression=no 
     use-encryption=no only-one=default change-tcp-mss=yes address-list=DYNAMIC-L2TPClients 
     dns-server=192.168.0.1

 2 * name="default-encryption" use-mpls=default use-compression=default use-vj-compression=default use-encryption=yes 
     only-one=default change-tcp-mss=yes

I can post logs/tcpdumps (from the android client anyway) if desired, but I won’t spam them in for now :slight_smile:

Thanks,

Terry.

2

Set up NAT rule to change source address of outgoing L2TP packets.

3

Thanks for the reply.

I set up the SNAT rule as you suggested and watched the SCCRP packets leaving with the correct source address. According to the policy, these should have been encrypted and encapsulated (UDP:4500) but I was still not seeing those packets arriving on the client.

To remove the complicated network form the equation, I set up a brand new RB450G to act as a pure IPSec/L2TP box, and connected this to the DMZ on 10.0.0.30 with the necessary NAT rules and routing marks

It seems I’m back where I was previously, but this time I can see that the port 1701 SCCRP packets are arriving back at the gateway unencrypted. (They still have a source port of 1701 and I can see the device name in the packet tab via the sniffer); so it looks like the policy on the new RB450 box isn’t being applied to the outbound L2TP traffic.

This is the policy generated automatically by the peer:

/ip ipsec policy print detail
Flags: X - disabled, D - dynamic, I - inactive 
 0 D src-address=w.x.y.57/32 src-port=any dst-address=a.b.c.198/32 dst-port=any protocol=udp action=encrypt l
      level=require ipsec-protocols=esp tunnel=no sa-src-address=w.x.y.57 sa-dst-address=a.b.c.198 
      proposal=default priority=2

and the SA pair:

/ip ipsec installed-sa print detail
Flags: A - AH, E - ESP, P - pfs 
 0 E  spi=0x324C6F5 src-address=10.0.0.30 dst-address=w.x.y.57 auth-algorithm=sha1 enc-algorithm=3des replay=4 state=mature 
       auth-key="eff9..." enc-key="79a7..." add-lifetime=6h24m/8h use-lifetime=0s/0s lifebytes=0/0 

 1 E  spi=0x5905226 src-address=w.x.y.57 dst-address=10.0.0.30 auth-algorithm=sha1 enc-algorithm=3des replay=4 state=mature 
       auth-key="b97a..." enc-key="699c..." addtime=mar/08/2012 17:24:00 add-lifetime=6h24m/8h usetime=mar/08/2012 17:24:01 
       use-lifetime=0s/0s current-bytes=1584 lifebytes=0/0

And the remote peer:

/ip ipsec remote-peers print detail
 0     local-address=10.0.0.30 remote-address=w.x.y.57 state=established side=responder established=16m36s

(I’ve truncated the keys and masked the public IPs)

I can’t see any fault with this, but it’s pretty clear the policy isn’t being hit with outbound traffic. Is there something I’ve missed?

I should note that I have this identical IPSec/L2TP setup running on a 750G at home, but this is with just one external connection and IP address (no NAT in the way).