Sent via Iphone
> On 15 Oct 2018, at 20:46, Whit Blauvelt <[email protected]> wrote: > > Hi Satavee, > > Now that you mention that, I recall one of the Cisco admins some time back, > when we were still running Openswan on this end, saying that the Cisco had > duplicates up for tunnels giving trouble. Restarting the Cisco at the same > time as this end helped. More recently when I've called when there's trouble > that haven't noticed that; but I'm not sure they looked closely. > > I'm not specifying which IKE version to run. Whack shows the tunnels > configured as: > > 000 "cisco/8x1": policy: > PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO; > 000 "cisco/8x1": IKE algorithms: 3DES_CBC-HMAC_SHA1-MODP2048, > 3DES_CBC-HMAC_SHA1-MODP1536 > > Are you saying the "PARENT SA established" message is specific to when > there's trouble? I don't have that at all right now, but the tunnel's stable > at the moment. That mean: you’re running ikev1 , as mentioned it working fine for me when connect to cisco router. Satavee > Thanks for the suggestions, > Whit > > >> On Mon, Oct 15, 2018 at 06:07:02AM +0700, Satavee Junwana wrote: >> Hi Whit, >> >> I also have problem when connect to Cisco (ISR Router no ASA) , >> but >> it only have a problem with IKEv2 – not sure what IKE version are you using – >> >> >> >> If you’re running ikev2 – try to observe this --- >> >> 000 #1: "ppp1_DC172":4500 STATE_PARENT_I3 (PARENT SA established); >> EVENT_SA_REPLACE in 2889s; newest ISAKMP; idle; >> >> 000 #2: "ppp1_DC172":4500 STATE_V2_IPSEC_I (IPsec SA established); >> EVENT_SA_REPLACE in 166s; newest IPSEC; eroute owner; isakmp#1; idle; >> >> 000 #2: "ppp1_DC172" [email protected] [email protected] [email protected] >> [email protected] ref=0 refhim=0 Traffic: ESPin=0B ESPout=40KB! ESPmax=0B >> >> 000 #3: "ppp1_DC192":4500 STATE_PARENT_I3 (PARENT SA established); >> EVENT_SA_REPLACE in 2882s; newest ISAKMP; idle; >> >> 000 #4: "ppp1_DC192":4500 STATE_V2_IPSEC_I (IPsec SA established); >> EVENT_SA_REPLACE in 225s; newest IPSEC; eroute owner; isakmp#3; idle; >> >> 000 #4: "ppp1_DC192" [email protected] [email protected] [email protected] >> [email protected] ref=0 refhim=0 Traffic: ESPin=252B ESPout=252B! ESPmax=0B >> >> # >> >> >> >> [root@s504-1809 ~]# ipsec whack --status |grep "PARENT SA established" >> >> 000 #5: "ppp1_DC172":4500 STATE_PARENT_I3 (PARENT SA established); >> EVENT_SA_REPLACE in 3267s; idle; >> >> 000 #6: "ppp1_DC172":4500 STATE_PARENT_I3 (PARENT SA established); >> EVENT_SA_REPLACE in 3255s; newest ISAKMP; idle; >> >> >> >> Libreswan/ikev2 has be initiated Phase 1 for each subnet ,Cisco side will be >> deleted the first one and last one is working – >> >> >> >> >> >> Good luck/Satavee >> >> >> >> Sent from Mail for Windows 10 >> >> >> >> From: Whit Blauvelt >> Sent: Monday, October 15, 2018 00:06 >> To: Paul Wouters >> Cc: [email protected] >> Subject: Re: [Swan] Trying to get dependably clean restarts with Cisco ASAs >> onother ends >> >> >> >> On Sat, Oct 13, 2018 at 07:45:57PM -0400, Paul Wouters wrote: >> >> >> >>> Rekeying support got extended and improved, so please tryt 3.27. We do >> >>> know there is at least one interop issue left that we see on Cisco, so >> >>> I'm not guaranteeing your issue will be resolved. >> >> >> >> Hi Paul, >> >> >> >> Upgraded to 3.27. Still getting the problem after a fast restart. If I wait, >> >> say, 15 seconds to restart, most but not all the subnets work. Sometimes a >> >> subnet will work from libreswan box but not behind it, sometimes the >> >> reverse, and sometimes not from either. The majority always work, but a >> >> different majority. >> >> >> >> The pattern is still that if I wait a minute to restart, all subnets >> >> connect. It's as if something has to reset on the Cisco for the restart to >> >> be clean. When I've spoken with the various admins on the Cisco side (this >> >> is for a private cloud setup at Rackspace), they haven't come up with much >> >> of an explanation. >> >> >> >> The problems may all be in routing from this end to subnets behind the >> >> Cisco. Subnets behind the Cisco can at least sometimes reach addresses on >> >> subnets here, which aren't working the other way. This does not cause it to >> >> start working from this side. It seems like off and on with a minute between >> >> is the only reliable method I've tried so far -- although as I mentioned >> >> previously it does look like it can also spontaneously recover. >> >> >> >> Proxyarp is (and has been) 0 for the LAN interface on the libreswan box. I >> >> suppose some other box on the LAN could have it on though. I can't see how >> >> that should affect traffic from the libreswan box itself even if it is the >> >> case, so likely not the problem. >> >> >> >> Thanks again for your help. >> >> >> >> Whit >> >> _______________________________________________ >> >> Swan mailing list >> >> [email protected] >> >> https://lists.libreswan.org/mailman/listinfo/swan >> >> >> _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
