[prev in list] [next in list] [prev in thread] [next in thread] 

List:       libreswan-dev
Subject:    [Swan-dev] passert report in bug #252
From:       paul () nohats ! ca (Paul Wouters)
Date:       2015-11-24 15:40:52
Message-ID: alpine.LFD.2.20.1511241027580.30357 () bofh ! nohats ! ca
[Download RAW message or body]


libreswan git version causes:

Nov 24 15:47:53 sol pluto[11380]: packet from 31.4.183.190:19128: received Vendor ID \
                payload [RFC 3947]
Nov 24 15:47:53 sol pluto[11380]: packet from 31.4.183.190:19128: ignoring Vendor ID \
                payload [draft-ietf-ipsec-nat-t-ike-02]
Nov 24 15:47:53 sol pluto[11380]: packet from 31.4.183.190:19128: ignoring Vendor ID \
                payload [draft-ietf-ipsec-nat-t-ike-02_n]
Nov 24 15:47:53 sol pluto[11380]: packet from 31.4.183.190:19128: ignoring Vendor ID \
                payload [draft-ietf-ipsec-nat-t-ike-00]
Nov 24 15:47:53 sol pluto[11380]: packet from 31.4.183.190:19128: received Vendor ID \
                payload [FRAGMENTATION 80000000]
Nov 24 15:47:53 sol pluto[11380]: packet from 31.4.183.190:19128: received Vendor ID \
                payload [Dead Peer Detection]
Nov 24 15:47:53 sol pluto[11380]: "tunnel2-nat"[1] 31.4.183.190 #1: enabling possible \
                NAT-traversal with method RFC 3947 (NAT-Traversal)
Nov 24 15:47:53 sol pluto[11380]: "tunnel2-nat"[1] 31.4.183.190 #1: responding to \
                Main Mode from unknown peer 31.4.183.190
Nov 24 15:47:53 sol pluto[11380]: "tunnel2-nat"[1] 31.4.183.190 #1: transition from \
                state STATE_MAIN_R0 to state STATE_MAIN_R1
Nov 24 15:47:53 sol pluto[11380]: "tunnel2-nat"[1] 31.4.183.190 #1: STATE_MAIN_R1: \
                sent MR1, expecting MI2
Nov 24 15:47:53 sol pluto[11380]: "tunnel2-nat"[1] 31.4.183.190 #1: NAT-Traversal: \
Result using RFC 3947 (NAT-Traversal) sender port 19128: I am behind NAT+peer behind \
                NAT
Nov 24 15:47:53 sol pluto[11380]: "tunnel2-nat"[1] 31.4.183.190 #1: transition from \
                state STATE_MAIN_R1 to state STATE_MAIN_R2
Nov 24 15:47:53 sol pluto[11380]: "tunnel2-nat"[1] 31.4.183.190 #1: STATE_MAIN_R2: \
                sent MR2, expecting MI3
Nov 24 15:47:53 sol pluto[11380]: "tunnel2-nat"[1] 31.4.183.190 #1: Main mode peer ID \
                is ID_IPV4_ADDR: '10.36.198.35'
Nov 24 15:47:53 sol pluto[11380]: "tunnel2-nat"[1] 31.4.183.190 #1: switched from \
                "tunnel2-nat"[1] 31.4.183.190 to "tunnel2-nat"
Nov 24 15:47:53 sol pluto[11380]: "tunnel2-nat"[2] 31.4.183.190 #1: deleting \
                connection "tunnel2-nat" instance with peer 31.4.183.190 \
                {isakmp=#0/ipsec=#0}
Nov 24 15:47:53 sol pluto[11380]: "tunnel2-nat"[2] 31.4.183.190 #1: ASSERTION FAILED \
                at
/home/packages/src/libreswan/libreswan.git/programs/pluto/connections.c:316: \
c->spd.this.virt == NULL

This assert was added on 2015-09-07 by Hugh in commit bcc2880b

Something weird _is_ happening. It's a new incoming connection, so
instantiation is expected. but then it switches to the template? which I
think gets instantiated (note the appearance of "tunnel2-nat"[2])

Why do we expect that c->spd.this.virt == NULL? It is only set to NULL
in modecfg_inR1() which happens way later in the exchange.

Note that in this case both endspoints are behind NAT. But we should
have only one virt enabled (for "that", not "this", since we are the
server? So I do understand the passert's idea.). I've asked the
reporter if they used vhost=/vnet= in both leftsubnet and rightsubnet.

Paul


[prev in list] [next in list] [prev in thread] [next in thread]