[Swan] IKEv2 with multiple conn entries

Tue May 22 20:10:16 UTC 2018

Hi Paul:

Thanks for your response. After reading some more I tried a different
syntax:

conn test80
    rightsubnets={64.40.200.80/32,64.40.200.82/32}
    also=test_common
    auto=start

When I tried starting the connection test80, here's what I got in
/var/log/secure:

May 16 17:18:18 mymachine sudo:  myuser : TTY=pts/7 ; PWD=/home/myuser ;
USER=root ; COMMAND=/sbin/ipsec auto --add test80
May 16 17:18:18 mymachine pluto[14869]: added connection description
"test80/1x1"
May 16 17:18:18 mymachine pluto[14869]: added connection description
"test80/1x2"
May 16 17:18:28 mymachine sudo:  myuser : TTY=pts/7 ; PWD=/home/myuser ;
USER=root ; COMMAND=/sbin/ipsec auto --up test80
May 16 17:18:28 mymachine pluto[14869]: initiating all conns with
alias='test80'
May 16 17:18:28 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68135:
initiating v2 parent SA
May 16 17:18:28 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68135:
test80/1x2 IKE proposals for initial initiator (selecting KE):
1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_256;INTEG=NONE;DH=MODP2048
May 16 17:18:28 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68135:
STATE_PARENT_I1: sent v2I1, expected v2R1
May 16 17:18:28 mymachine pluto[14869]: | Switching Child connection for
#68136 to "test80/1x1"[1] 66.200.40.2 from "test80/1x2"[1] 66.200.40.2
May 16 17:18:28 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68135:
test80/1x1 ESP/AH proposals for initiator:
1:ESP:ENCR=AES_GCM_C_256;INTEG=NONE;ESN=DISABLED
May 16 17:18:28 mymachine pluto[14869]: "test80/1x1"[1] 66.200.40.2 #68136:
STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=aes_gcm_16_256
integ=n/a prf=sha2_256 group=MODP2048}
May 16 17:18:28 mymachine pluto[14869]: "test80/1x1"[1] 66.200.40.2 #68136:
IKEv2 mode peer ID is ID_IPV4_ADDR: '66.200.40.2'
May 16 17:18:28 mymachine pluto[14869]: "test80/1x1"[1] 66.200.40.2 #68136:
negotiated connection [192.168.1.2-192.168.1.2:0-65535 0] ->
[64.40.200.80-64.40.200.80:0-65535 0]
May 16 17:18:28 mymachine pluto[14869]: "test80/1x1"[1] 66.200.40.2 #68136:
STATE_V2_IPSEC_I: IPsec SA established tunnel mode {ESP/NAT=>0xa7c54fee
<0xff4cd6d7 xfrm=AES_GCM_16_256-NONE NATOA=none NATD=66.200.40.2:4500
DPD=passive}
May 16 17:18:28 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68137:
test80/1x2 ESP/AH proposals for initiator:
1:ESP:ENCR=AES_GCM_C_256;INTEG=NONE;ESN=DISABLED
May 16 17:18:28 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68137:
STATE_V2_CREATE_I: sent IPsec Child req wait response
May 16 17:18:29 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68137:
STATE_V2_CREATE_I: retransmission; will wait 0.5 seconds for response
May 16 17:18:29 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68137:
STATE_V2_CREATE_I: retransmission; will wait 1 seconds for response
May 16 17:18:30 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68137:
STATE_V2_CREATE_I: retransmission; will wait 2 seconds for response
May 16 17:18:32 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68137:
STATE_V2_CREATE_I: retransmission; will wait 4 seconds for response
May 16 17:18:36 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68137:
STATE_V2_CREATE_I: retransmission; will wait 8 seconds for response
May 16 17:18:44 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68137:
STATE_V2_CREATE_I: retransmission; will wait 16 seconds for response
May 16 17:19:00 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68137:
STATE_V2_CREATE_I: retransmission; will wait 32 seconds for response
May 16 17:19:32 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68137:
STATE_V2_CREATE_I: 60 second timeout exceeded after 7 retransmits.  No
response (or no acceptable response) to our IKEv2 message
May 16 17:19:32 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68137:
starting keying attempt 2 of an unlimited number, but releasing whack
May 16 17:19:32 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68137:
deleting state (STATE_V2_CREATE_I)
May 16 17:26:43 mymachine sudo:  myuser : TTY=pts/7 ; PWD=/home/myuser ;
USER=root ; COMMAND=/bin/vi /etc/ipsec.d/test2.conf
May 16 17:48:36 mymachine pluto[14869]: "test80/1x1"[1] 66.200.40.2 #68136:
deleting other state #68136 connection (STATE_CHILDSA_DEL) "test80/1x1"[1]
66.200.40.2
May 16 17:48:36 mymachine pluto[14869]: packet from 66.200.40.2:4500:
deleting connection "test80/1x1"[1] 66.200.40.2 instance with peer
66.200.40.2 {isakmp=#0/ipsec=#0}
May 16 17:48:36 mymachine pluto[14869]: "test80/1x2"[1] 66.200.40.2 #68135:
deleting state (STATE_IKESA_DEL)
May 16 17:48:36 mymachine pluto[14869]: packet from 66.200.40.2:4500:
deleting connection "test80/1x2"[1] 66.200.40.2 instance with peer
66.200.40.2 {isakmp=#0/ipsec=#0}

Just as when I was trying the two different conn statements, the first
connection succeeds (64.40.200.80 in this case) and I can ping the remote
side, but the second one never completes.

Thanks for any insight you may have!
Yours,
Bobby

On Tue, May 22, 2018 at 12:40 PM, Paul Wouters <paul at nohats.ca> wrote:

> On Tue, 15 May 2018, Bobby Jones wrote:
>
> I have been beating my head against this for awhile, and I'm hoping that
>> someone can point me in the right direction.
>>
>> I have a number of IPSec tunnels established, mostly from libreswan to
>> Cisco ASAs. Most are IKE v1, and in that case if I
>> want to reach multiple hosts on the remote side I can have a formulation
>> like this in my .conf file:
>>
>> conn test1
>> rightsubnet=192.168.1.111/255.255.255.255
>> rightsourceip=192.168.1.111
>> also=test_common
>> auto=start
>> conn test2
>> rightsubnet=192.168.1.112/255.255.255.255
>> rightsourceip=192.168.1.112
>> also=test_common
>> auto=start
>>
>> However, if I use this syntax with IKEv2, I can start test1 and reach
>> 192.168.1.111, but test2 will then not complete.
>>
>
> That should work. Can you provide more logs to see what is happening?
>
> This formulation gets me up to the point where I see "STATE_PARENT_I2:
>> sent v2I2, expected v2R2" but then all I get is
>> "STATE_PARENT_I2: retransmission".
>>
>
> Odd, you should always recent an answer to I2. Especially since you got
> an answer to I1, so it shows no firewall is in the way.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20180522/833e73e4/attachment.html>