Bug #3317
L2TP not working with multiwan
| Status: | CLOSED | Start date: | ||
|---|---|---|---|---|
| Priority: | Normal | Due 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 )
- 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
l2tp: multiwan support. Refs #3317
History
#1
Updated by Giacomo Sanchietti over 5 years ago
- Description updated (diff)
- Affected version set to v6.7
#2
Updated by Giacomo Sanchietti over 5 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 over 5 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 over 5 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 over 5 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 over 5 years ago
- Status changed from ON_DEV to MODIFIED
- % Done changed from 30 to 60
#7
Updated by Giacomo Sanchietti over 5 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
- 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 over 5 years ago
- Assignee set to Davide Marini
#9
Updated by Davide Marini over 5 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 over 5 years ago
- Assignee deleted (
Davide Marini)
#11
Updated by Giacomo Sanchietti over 5 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