On Mon, 10 Sep 2018, Craig Marker wrote:
I use auto=ignore since I have other processes that manage the tunnel
connection and ensure it sets up correctly (client initiating with server
rather than leaving that up to chance)..
So on the server use auto=add and on the client use auto=ondemand ?
I believe something went wrong during post-reboot initiation, which is
contained in the first two log
snippets. Multiples IPsec SAs are installed and I can’t explain why.
The last two log snippets capture ipsec auto —delete conn37 followed by ipsec
auto —replace conn37 and ipsec auto —route conn37. It appears like
something went amiss when the client receives the —delete conn37 notification,
as the quick mode initiation in #64 gets deleted, and thus the
client machine appears to forget about conn1. I believe the root problem is the
initial initiation of multiple SAs, though I could be wrong.
If you have scripts restarting things and doing --up which also causes
it to restart again after receiveing a delete from the other end, you
could be creating the scenario where multiple starts are happening.
Sep 7 03:23:17 cq-use1f-1 pluto[2446]: packet from 199.32.40.51:500: initial
Main Mode message received on 51.179.82.210:500 but no connection
has been authorized with policy RSASIG+IKEV1_ALLOW
Not all your connections are loaded? or there is a misconfiuration? Or a
race when you use --replace (which means --delete + add)
Sep 7 03:23:17 cq-use1f-1 pluto[2446]: "conn37" #1: responding to Main Mode
Sep 7 03:23:17 cq-use1f-1 pluto[2446]: "conn37" #1: STATE_MAIN_R1: sent MR1,
expecting MI2
Sep 7 03:23:17 cq-use1f-1 pluto[2446]: packet from 100.9.123.24:500: initial
Main Mode message received on 51.179.82.210:500 but no connection
has been authorized with policy RSASIG+IKEV1_ALLOW
Sep 7 03:23:17 cq-use1f-1 pluto[2446]: "conn37" #1: STATE_MAIN_R2: sent MR2,
expecting MI3
Sep 7 03:23:17 cq-use1f-1 pluto[2446]: "conn37" #1: Peer ID is ID_FQDN:
'@left-70.240.163.43'
Sep 7 03:23:17 cq-use1f-1 pluto[2446]: "conn37" #1: certificate verified OK:
CN=ABC123,OU=Engineering,O="Craig Inc.",L=Seattle,ST=Washington,C=US
Sep 7 03:23:17 cq-use1f-1 pluto[2446]: "conn37" #1: I am sending my cert
Sep 7 03:23:17 cq-use1f-1 pluto[2446]: "conn37" #1: STATE_MAIN_R3: sent MR3,
ISAKMP SA established {auth=RSA_SIG cipher=aes_256 integ=sha2_256
group=MODP2048}
Sep 7 03:23:18 cq-use1f-1 pluto[2446]: "conn37" #1: retransmitting in response
to duplicate packet; already STATE_MAIN_R3
Sep 7 03:23:18 cq-use1f-1 pluto[2446]: "conn37" #1: the peer proposed:
0.0.0.0/0:0/0 -> 0.0.0.0/0:0/0
if you are using leftsubnet=0.0.0.0 and rightsubnet=0.0.0.0, are you
using VTI devices or KLIPS devices?
… information unrelated to conn37 removed ...
Sep 7 03:23:20 cq-use1f-1 pluto[2446]: assign_holdpass() delete_bare_shunt()
failed
Sep 7 03:23:20 cq-use1f-1 pluto[2446]: initiate_ondemand_body() failed to
install negotiation_shunt,
Sep 7 03:23:20 cq-use1f-1 pluto[2446]: initiate on demand from 172.16.0.2:8 to
172.16.0.3:0 proto=1 because: acquire
it seems your auto=ondemand is causing aquires for everything? since you
have 0/0 to 0/0 ?
Sep 7 03:23:20 cq-use1f-1 pluto[2446]: "conn37" #5: STATE_QUICK_I2: sent QI2, IPsec
SA established tunnel mode {ESP/NAT=>0xc981ba01 <0xefe112e2
xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none NATD=70.240.163.43:4500
DPD=passive}
Sep 7 03:23:20 cq-use1f-1 pluto[2446]: "conn37" #6: STATE_QUICK_I2: sent QI2, IPsec
SA established tunnel mode {ESP/NAT=>0x863a2b6b <0xcbfb1484
xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none NATD=70.240.163.43:4500
DPD=passive}
clearly things are running bad races.
Sep 7 03:23:18 fmn-767 pluto[2190]: "conn1" #48: up-client output: vti interface
"conn1" already exists with conflicting setting
Sep 7 03:23:18 fmn-767 pluto[2190]: "conn1" #48: up-client output: existing:
conn1: ip/ip remote any local 70.240.163.43 ttl inherit key 16777216
Sep 7 03:23:18 fmn-767 pluto[2190]: "conn1" #48: up-client output: wanted :
conn1: ip/ip remote any local 70.240.163.43 ttl inherit key
How many conns with %any do you have? The current VTI does not support
more then one "any" target. Its a kernel limitation in VTI, which is
being replaced by xfrmi interfaces that won't have that limitation.
Server invokes ipsec auto —delete conn37 and later ipsec auto —replace conn37
and ipsec auto —route conn37...
running --route (eg on demand) is a little strange, since you are trying
to do these manually? you prob mean to go from --replace to --up.
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
