Page MenuHomeVyOS Platform
Create Task
Maniphest T184

l2tp ipsec tunnel impossible to reconnect
Closed, WontfixPublic
Actions

Description

I have configured a standard l2tp connection with ipsec pre-shared key. I connect to Vyos with an Android phone. The first connection results in a functional tunnel but, if i close the connection and try to reopen again it doesnt function anymore, as long i restart pluto.
Here
-> my configuration (censored)
-> the log of the first functional connection
-> the log of the second doesnt functional connection

vpn {

ipsec {
    ipsec-interfaces {
        interface pppoe0
    }
    nat-networks {
        allowed-network 0.0.0.0/0 {
        }
    }
    nat-traversal enable
}
l2tp {
    remote-access {
        authentication {
            local-users {
                username xxxxxxxxxxx {
                    password ****************
                }
            }
            mode local
        }
        client-ip-pool {
            start a.a.a.a
            stop b.b.b.b
        }
        dns-servers {
            server-1 y.y.y.y
        }
        ipsec-settings {
            authentication {
                mode pre-shared-secret
                pre-shared-secret ****************
            }
        }
        mtu 1492
        outside-address c.c.c.c
        wins-servers {
            server-1 x.x.x.x
        }
    }
}

}

Nov 5 09:21:00 firewall pluto[7469]: packet from 5.170.105.43:22304: received Vendor ID payload [RFC 3947]
Nov 5 09:21:00 firewall pluto[7469]: packet from 5.170.105.43:22304: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
Nov 5 09:21:00 firewall pluto[7469]: packet from 5.170.105.43:22304: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Nov 5 09:21:00 firewall pluto[7469]: packet from 5.170.105.43:22304: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Nov 5 09:21:00 firewall pluto[7469]: packet from 5.170.105.43:22304: ignoring Vendor ID payload [FRAGMENTATION 80000000]
Nov 5 09:21:00 firewall pluto[7469]: packet from 5.170.105.43:22304: received Vendor ID payload [Dead Peer Detection]
Nov 5 09:21:00 firewall pluto[7469]: "remote-access-mac-zzz"[19] 5.170.105.43:22304 #27: responding to Main Mode from unknown peer 5.170.105.43:22304
Nov 5 09:21:00 firewall pluto[7469]: "remote-access-mac-zzz"[19] 5.170.105.43:22304 #27: Oakley Transform [AES_CBC (256), HMAC_SHA2_256, MODP_1024] refused due to strict flag
Nov 5 09:21:00 firewall pluto[7469]: "remote-access-mac-zzz"[19] 5.170.105.43:22304 #27: NAT-Traversal: Result using RFC 3947: peer is NATed
Nov 5 09:21:01 firewall pluto[7469]: "remote-access-mac-zzz"[19] 5.170.105.43:22304 #27: Peer ID is ID_IPV4_ADDR: '10.69.74.214'
Nov 5 09:21:01 firewall pluto[7469]: "remote-access-mac-zzz"[20] 5.170.105.43:22304 #27: deleting connection "remote-access-mac-zzz" instance with peer 5.170.105.43 {isakmp=#0/ipsec=#0}
Nov 5 09:21:01 firewall pluto[7469]: "remote-access-mac-zzz"[20] 5.170.105.43:22549 #27: sent MR3, ISAKMP SA established
Nov 5 09:21:01 firewall pluto[7469]: "remote-access-mac-zzz"[20] 5.170.105.43:22549 #27: ignoring informational payload, type IPSEC_INITIAL_CONTACT
Nov 5 09:21:01 firewall pluto[7469]: "remote-access-mac-zzz"[20] 5.170.105.43:22549 #28: IPSec Transform [AES_CBC (256), HMAC_SHA2_256] refused due to strict flag
Nov 5 09:21:01 firewall pluto[7469]: "remote-access-mac-zzz"[20] 5.170.105.43:22549 #28: responding to Quick Mode
Nov 5 09:21:01 firewall pluto[7469]: "remote-access-mac-zzz"[20] 5.170.105.43:22549 #28: Dead Peer Detection (RFC 3706) enabled
Nov 5 09:21:01 firewall pluto[7469]: "remote-access-mac-zzz"[20] 5.170.105.43:22549 #28: IPsec SA established {ESP=>0x0a202583 <0xc6ce6dd4 NATOA=0.0.0.0}
Nov 5 09:21:04 firewall xl2tpd[14677]: Connection established to 5.170.105.43, 39101. Local: 38431, Remote: 46083 (ref=0/0). LNS session is 'default'
Nov 5 09:21:04 firewall xl2tpd[14677]: Call established with 5.170.105.43, Local: 38974, Remote: 50461, Serial: 717948973
Nov 5 09:21:04 firewall pppd[22106]: pppd 2.4.4 started by root, uid 0
Nov 5 09:21:04 firewall zebra[2568]: interface ppp1 index 29 <POINTOPOINT,NOARP,MULTICAST> added.
Nov 5 09:21:04 firewall pppd[22106]: Connect: ppp1 <--> /dev/pts/1
Nov 5 09:21:04 firewall zebra[2568]: interface ppp1 mtu changed from 1500 to 1400
Nov 5 09:21:05 firewall pppd[22106]: Unsupported protocol 'Compression Control Protocol' (0x80fd) received
Nov 5 09:21:05 firewall zebra[2568]: warning: PtP interface ppp1 with addr 10.255.255.0/32 needs a peer address
Nov 5 09:21:05 firewall zebra[2568]: interface index 29 was renamed from ppp1 to l2tp0
Nov 5 09:21:05 firewall ripd[2575]: interface delete ppp1 index 29 flags 0x1090 metric 1 mtu 1400
Nov 5 09:21:05 firewall ripngd[2579]: interface delete ppp1 index 29 flags 0x1090 metric 1 mtu 1400
Nov 5 09:21:05 firewall pppd[22106]: Cannot determine ethernet address for proxy ARP
Nov 5 09:21:05 firewall pppd[22106]: local IP address 10.255.255.0
Nov 5 09:21:05 firewall pppd[22106]: remote IP address 192.168.27.129

Nov 5 09:21:36 firewall pluto[7469]: ERROR: asynchronous network error report on pppoe0 for message to 5.170.105.43 port 22549, complainant 5.170.104.0: Connection refused [er
rno 111, origin ICMP type 3 code 3 (not authenticated)]
Nov 5 09:21:51 firewall pluto[7469]: ERROR: asynchronous network error report on pppoe0 for message to 5.170.105.43 port 22549, complainant 5.170.104.0: Connection refused [er
rno 111, origin ICMP type 3 code 3 (not authenticated)]
Nov 5 09:22:01 firewall pluto[7469]: packet from 5.170.105.43:22304: received Vendor ID payload [RFC 3947]
Nov 5 09:22:01 firewall pluto[7469]: packet from 5.170.105.43:22304: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
Nov 5 09:22:01 firewall pluto[7469]: packet from 5.170.105.43:22304: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Nov 5 09:22:01 firewall pluto[7469]: packet from 5.170.105.43:22304: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Nov 5 09:22:01 firewall pluto[7469]: packet from 5.170.105.43:22304: ignoring Vendor ID payload [FRAGMENTATION 80000000]
Nov 5 09:22:01 firewall pluto[7469]: packet from 5.170.105.43:22304: received Vendor ID payload [Dead Peer Detection]
Nov 5 09:22:01 firewall pluto[7469]: "remote-access-mac-zzz"[21] 5.170.105.43:22304 #29: responding to Main Mode from unknown peer 5.170.105.43:22304
Nov 5 09:22:01 firewall pluto[7469]: "remote-access-mac-zzz"[21] 5.170.105.43:22304 #29: Oakley Transform [AES_CBC (256), HMAC_SHA2_256, MODP_1024] refused due to strict flag
Nov 5 09:22:01 firewall pluto[7469]: "remote-access-mac-zzz"[21] 5.170.105.43:22304 #29: NAT-Traversal: Result using RFC 3947: peer is NATed
Nov 5 09:22:02 firewall pluto[7469]: "remote-access-mac-zzz"[21] 5.170.105.43:22304 #29: Peer ID is ID_IPV4_ADDR: '10.69.74.214'
Nov 5 09:22:02 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22304 #29: deleting connection "remote-access-mac-zzz" instance with peer 5.170.105.43 {isakmp=#0/ipsec=#0}
Nov 5 09:22:02 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: sent MR3, ISAKMP SA established
Nov 5 09:22:02 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: ignoring informational payload, type IPSEC_INITIAL_CONTACT
Nov 5 09:22:03 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #30: IPSec Transform [AES_CBC (256), HMAC_SHA2_256] refused due to strict flag
Nov 5 09:22:03 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #30: responding to Quick Mode
Nov 5 09:22:03 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #30: cannot install eroute -- it is in use for "remote-access-mac-zzz"[20] 5.170.105.43:22549 #28
Nov 5 09:22:06 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x05b16dd3 (perhaps this is a duplicated packet)
Nov 5 09:22:06 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: sending encrypted notification INVALID_MESSAGE_ID to 5.170.105.43:22549
Nov 5 09:22:09 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x05b16dd3 (perhaps this is a duplicated packet)
Nov 5 09:22:09 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: sending encrypted notification INVALID_MESSAGE_ID to 5.170.105.43:22549
Nov 5 09:22:09 firewall xl2tpd[14677]: Maximum retries exceeded for tunnel 38431. Closing.
Nov 5 09:22:12 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x05b16dd3 (perhaps this is a duplicated packet)
Nov 5 09:22:12 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: sending encrypted notification INVALID_MESSAGE_ID to 5.170.105.43:22549
Nov 5 09:22:15 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x05b16dd3 (perhaps this is a duplicated packet)
Nov 5 09:22:15 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: sending encrypted notification INVALID_MESSAGE_ID to 5.170.105.43:22549
Nov 5 09:22:18 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x05b16dd3 (perhaps this is a duplicated packet)
Nov 5 09:22:18 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: sending encrypted notification INVALID_MESSAGE_ID to 5.170.105.43:22549
Nov 5 09:22:20 firewall pluto[7469]: "remote-access-mac-zzz"[20] 5.170.105.43:22549 #27: DPD: Phase1 state #27 has been superseded by #29 - timeout ignored
Nov 5 09:22:22 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x05b16dd3 (perhaps this is a duplicated packet)
Nov 5 09:22:22 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: sending encrypted notification INVALID_MESSAGE_ID to 5.170.105.43:22549
Nov 5 09:22:24 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x05b16dd3 (perhaps this is a duplicated packet)
Nov 5 09:22:24 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: sending encrypted notification INVALID_MESSAGE_ID to 5.170.105.43:22549
Nov 5 09:22:27 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x05b16dd3 (perhaps this is a duplicated packet)
Nov 5 09:22:27 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: sending encrypted notification INVALID_MESSAGE_ID to 5.170.105.43:22549
Nov 5 09:22:30 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x05b16dd3 (perhaps this is a duplicated packet)
Nov 5 09:22:30 firewall pluto[7469]: "remote-access-mac-zzz"[22] 5.170.105.43:22549 #29: sending encrypted notification INVALID_MESSAGE_ID to 5.170.105.43:22549
Nov 5 09:22:35 firewall pluto[7469]: ERROR: asynchronous network error report on pppoe0 for message to 5.170.105.43 port 22549, complainant 5.170.104.0: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]

Details

Difficulty level
Easy (less than an hour)
Version
-

Event Timeline

oliveriandrea created this task.Nov 5 2016, 8:27 AM
syncer added a subscriber: syncer.Nov 5 2016, 12:55 PM

Can you provide vyos version ?

oliveriandrea added a comment.Nov 7 2016, 8:09 AM

1.1.7

oliveriandrea added a comment.Nov 9 2016, 10:39 PM

It seems related to this Android 6.X 7.X bug
https://code.google.com/p/android/issues/detail?id=194269
https://code.google.com/p/android/issues/detail?id=196939

Android tries to use, during Phase 2, AES256 and SHA2_256 but it actually uses a SHA2_256 draft version which reduces the output to only 96 bits, so pluto replies with authentication errors... I have tried to add to /etc/ipsec.d/tunnels/remote-access esp=AES256-SHA256_96! but does not correspond to the proposal of Android so it is not usefull...
strongswan 5.X has the option sha2-truncbug=yes which permits to circumvent the bug (but it modifies also the reply of strongswan to ALL SHA2_256 requests..) maybe it would be possible to implement an option in vpn l2tp which enables this workaround only if the user wants to configure l2tp for android clients

syncer closed this task as Wontfix.Aug 1 2017, 4:50 AM
syncer triaged this task as Normal priority.
syncer changed the edit policy from "Task Author" to "Custom Policy".
syncer added a project: VyOS 1.1.x.
syncer set Version to -.

It not make sense debug this on 1.1.x
will be addressed in 1.2.x

syncer edited projects, added Rejected; removed VyOS 1.1.x.Oct 15 2018, 6:30 AM