Bug #3317

L2TP not working with multiwan

Added by Davide Marini almost 4 years ago. Updated almost 4 years ago.

Status:CLOSEDStart date:
Priority:NormalDue date:
Assignee:-% Done:

100%

Category:nethserver-ipsec
Target version:v6.7
Security class: Resolution:
Affected version:v6.7 NEEDINFO:No

Description

Steps to reproduce
  • Set up an l2tp vpn with the multiwan feature enabled (backup or balance, as you want)
  • try to connect with a device (I have tested it with android )
Expected behavior
  • The vpn l2tp works flawlessy establishing a connection beetween client and server.

Actual behavior

  • The vpn doesn't work, the log shows: (IP_CLIENT and IP_SERVER instead of original IPs)
Nov 11 16:26:39 localhost pluto[28458]: packet from IP_CLIENT:500: ignoring unknown Vendor ID payload [01528bbbc00696121849ab9a1c5b2a5100000001]
Nov 11 16:26:39 localhost pluto[28458]: packet from IP_CLIENT:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000009]
Nov 11 16:26:39 localhost pluto[28458]: packet from IP_CLIENT:500: received Vendor ID payload [RFC 3947] method set to=109 
Nov 11 16:26:39 localhost pluto[28458]: packet from IP_CLIENT:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 109
Nov 11 16:26:39 localhost pluto[28458]: packet from IP_CLIENT:500: ignoring Vendor ID payload [FRAGMENTATION]
Nov 11 16:26:39 localhost pluto[28458]: packet from IP_CLIENT:500: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
Nov 11 16:26:39 localhost pluto[28458]: packet from IP_CLIENT:500: ignoring Vendor ID payload [Vid-Initial-Contact]
Nov 11 16:26:39 localhost pluto[28458]: packet from IP_CLIENT:500: ignoring Vendor ID payload [IKE CGA version 1]
Nov 11 16:26:39 localhost pluto[28458]: packet from IP_CLIENT:500: initial Main Mode message received on IP_SERVER:500 but no connection has been authorized with policy=
PSK

Work around/fix
Because when we have the MultiWAN active we have no default gateway (no default route for packets) we need to force the vpn to use a specific interface.
It's sufficient to declare the ip address of the red interface used by the vpn, I tried to change the field left=%defaultroute in /etc/ipsec.conf

[root@localhost ~]# diff -u /etc/e-smith/templates/etc/ipsec.conf/20l2tp /etc/e-smith/templates-custom/etc/ipsec.conf/20l2tp
--- /etc/e-smith/templates/etc/ipsec.conf/20l2tp    2015-08-27 17:59:24.000000000 +0200
+++ /etc/e-smith/templates-custom/etc/ipsec.conf/20l2tp    2015-11-13 14:19:51.810157214 +0100
@@ -13,7 +13,7 @@
  'auto' => 'add',
  'pfs' => 'no',

-    'left' => '%defaultroute',
+    'left' => 'IP_ADDRESS',
         'leftprotoport' => '17/%any',

and now everything works flawlessy (see logs):

Nov 13 11:51:18 localhost pluto[30745]: "~L2TP"[1] IP_CLIENT #1: responding to Main Mode from unknown peer IP_CLIENT
Nov 13 11:51:18 localhost pluto[30745]: "~L2TP"[1] IP_CLIENT #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Nov 13 11:51:18 localhost pluto[30745]: "~L2TP"[1] IP_CLIENT #1: STATE_MAIN_R1: sent MR1, expecting MI2
Nov 13 11:51:18 localhost pluto[30745]: "~L2TP"[1] IP_CLIENT #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): peer is NATed
Nov 13 11:51:18 localhost pluto[30745]: "~L2TP"[1] IP_CLIENT #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Nov 13 11:51:18 localhost pluto[30745]: "~L2TP"[1] IP_CLIENT #1: STATE_MAIN_R2: sent MR2, expecting MI3
Nov 13 11:51:18 localhost pluto[30745]: "~L2TP"[1] IP_CLIENT #1: Main mode peer ID is ID_IPV4_ADDR: '192.168.5.18'
Nov 13 11:51:18 localhost pluto[30745]: "~L2TP"[1] IP_CLIENT #1: switched from "~L2TP" to "~L2TP" 
Nov 13 11:51:18 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #1: deleting connection "~L2TP" instance with peer IP_CLIENT {isakmp=#0/ipsec=#0}
Nov 13 11:51:18 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Nov 13 11:51:18 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #1: new NAT mapping for #1, was IP_CLIENT:500, now IP_CLIENT:4500
Nov 13 11:51:18 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=m
odp1024}
Nov 13 11:51:18 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #1: Dead Peer Detection (RFC 3706): enabled
Nov 13 11:51:18 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #1: ignoring informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000
Nov 13 11:51:18 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #1: received and ignored informational message
Nov 13 11:51:19 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #1: the peer proposed: IP_SERVER/32:17/0 -> 192.168.5.18/32:17/0
Nov 13 11:51:19 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #2: responding to Quick Mode proposal {msgid:6e9f6ef4}
Nov 13 11:51:19 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #2:     us: IP_SERVER<IP_SERVER>[@localhost.localdomain,+S=C]:17/%any
Nov 13 11:51:19 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #2:   them: IP_CLIENT[192.168.5.18,+S=C]:17/0
Nov 13 11:51:19 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #2: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Nov 13 11:51:19 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #2: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Nov 13 11:51:19 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #2: Dead Peer Detection (RFC 3706): enabled
Nov 13 11:51:19 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #2: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Nov 13 11:51:19 localhost pluto[30745]: "~L2TP"[2] IP_CLIENT #2: STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x0bdaf63a <0x695b15d6 xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=IP_CLIENT:4500 DPD=enabled}

I would like to configure this parameter in the web interface.

Associated revisions

Revision f7e13bf6
Added by Giacomo Sanchietti almost 4 years ago

l2tp: multiwan support. Refs #3317

History

#1 Updated by Giacomo Sanchietti almost 4 years ago

  • Description updated (diff)
  • Affected version set to v6.7

#2 Updated by Giacomo Sanchietti almost 4 years ago

  • Category set to nethserver-ipsec
  • Status changed from NEW to TRIAGED
  • Target version set to v6.7
  • % Done changed from 0 to 20

#3 Updated by Filippo Carletti almost 4 years ago

I'd prefer being able to establish the vpn on every wan.
Suppose you have a dns entry pointing to both your public ip, you could have a single l2tp connection working even if a link is down.

As an option, we could have an optinos box to select the list where the vpn could be established:

  • red1
  • red2
  • red3

But I can't see any drawback enabling every red by default.

#4 Updated by Giacomo Sanchietti almost 4 years ago

Filippo Carletti wrote:

I'd prefer being able to establish the vpn on every wan.

This is a template-custom ready for test:

{
    #
    # 20l2tp
    #
    use esmith::NetworksDB;
    my $ndb = esmith::NetworksDB->open_ro();

    my $status = $ipsec{'ServerStatus'} || 'disabled';
    if ($status eq 'disabled') {
        return '';
    }

    # L2TP connections
    foreach ($ndb->red()) {
        $conn->{'~L2TP'.$_->key} = {
            'auto' => 'add',
            'pfs' => 'no',

            'left' => '%'.$_->key,
            'leftprotoport' => '17/%any',

            'right' => '%any',
            'rightprotoport' => '17/%any',

            'ikelifetime' => '8h',
            'keylife' => '1h',

            'dpddelay' => '30',
            'dpdtimeout' => '120',
            'dpdaction' => 'clear',

        'type' => 'transport',
        };
    }

    '';
}

#5 Updated by Giacomo Sanchietti almost 4 years ago

  • Status changed from TRIAGED to ON_DEV
  • Assignee set to Giacomo Sanchietti
  • % Done changed from 20 to 30

Proposed template correctly works on the field.

#6 Updated by Giacomo Sanchietti almost 4 years ago

  • Status changed from ON_DEV to MODIFIED
  • % Done changed from 30 to 60

#7 Updated by Giacomo Sanchietti almost 4 years ago

  • Status changed from MODIFIED to ON_QA
  • Assignee deleted (Giacomo Sanchietti)
  • % Done changed from 60 to 70
In nethserver-testing:
  • nethserver-ipsec-1.1.2-1.7.gf7e13bf.ns6.noarch.rpm
Test case
  • Configure a firewall with multiwan and enable l2tp
  • Connect with a client, the vpn should work without any further configuration

#8 Updated by Davide Principi almost 4 years ago

  • Assignee set to Davide Marini

#9 Updated by Davide Marini almost 4 years ago

  • Status changed from ON_QA to VERIFIED
  • % Done changed from 70 to 90

New package installaed: everything worked as expected:

ipsec.log:

Nov 30 10:40:35 localhost pluto[18308]: "~L2TPppp0"[1] IP_CLIENT #1: responding to Main Mode from unknown peer IP_CLIENT
Nov 30 10:40:35 localhost pluto[18308]: "~L2TPppp0"[1] IP_CLIENT #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Nov 30 10:40:35 localhost pluto[18308]: "~L2TPppp0"[1] IP_CLIENT #1: STATE_MAIN_R1: sent MR1, expecting MI2
Nov 30 10:40:35 localhost pluto[18308]: "~L2TPppp0"[1] IP_CLIENT #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): peer is NATed
Nov 30 10:40:35 localhost pluto[18308]: "~L2TPppp0"[1] IP_CLIENT #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Nov 30 10:40:35 localhost pluto[18308]: "~L2TPppp0"[1] IP_CLIENT #1: STATE_MAIN_R2: sent MR2, expecting MI3
Nov 30 10:40:35 localhost pluto[18308]: "~L2TPppp0"[1] IP_CLIENT #1: Main mode peer ID is ID_IPV4_ADDR: '192.168.5.18'
Nov 30 10:40:35 localhost pluto[18308]: "~L2TPppp0"[1] IP_CLIENT #1: switched from "~L2TPppp0" to "~L2TPppp0" 
Nov 30 10:40:35 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #1: deleting connection "~L2TPppp0" instance with peer IP_CLIENT {isakmp=#0/ipsec=#0}
Nov 30 10:40:35 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Nov 30 10:40:35 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #1: new NAT mapping for #1, was IP_CLIENT:500, now IP_CLIENT:4500
Nov 30 10:40:35 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}
Nov 30 10:40:35 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #1: Dead Peer Detection (RFC 3706): enabled
Nov 30 10:40:35 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #1: ignoring informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000
Nov 30 10:40:35 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #1: received and ignored informational message
Nov 30 10:40:36 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #1: the peer proposed: IP_SERVER/32:17/0 -> 192.168.5.18/32:17/0
Nov 30 10:40:36 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #2: responding to Quick Mode proposal {msgid:9ad4f3fa}
Nov 30 10:40:36 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #2:     us: IP_SERVER<%ppp0>[@localhost.localdomain,+S=C]:17/%any
Nov 30 10:40:36 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #2:   them: IP_CLIENT[192.168.5.18,+S=C]:17/0
Nov 30 10:40:36 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #2: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Nov 30 10:40:36 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #2: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Nov 30 10:40:36 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #2: Dead Peer Detection (RFC 3706): enabled
Nov 30 10:40:36 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #2: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Nov 30 10:40:36 localhost pluto[18308]: "~L2TPppp0"[2] IP_CLIENT #2: STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x08b4e8c1 <0x7f2c7c6b xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=IP_CLIENT:4500 DPD=enabled}

now the log also shows the interface used for the connection (L2TPppp0)

#10 Updated by Giacomo Sanchietti almost 4 years ago

  • Assignee deleted (Davide Marini)

#11 Updated by Giacomo Sanchietti almost 4 years ago

  • Status changed from VERIFIED to CLOSED
  • % Done changed from 90 to 100
Released in nethserver-updates:
  • nethserver-ipsec-1.1.3-1.ns6.noarch.rpm

Also available in: Atom PDF