Hi Paul, Thanks for your quick response!
On Thu, Aug 2, 2018 at 1:04 PM, Paul Wouters <[email protected]> wrote: > On Thu, 2 Aug 2018, Qiuyu Xiao wrote: > >> I tried to use LibreSwan to encrypt traffic for geneve protocol but >> failed. >> >> Below is my configuration: >> >> In host 1 /etc/ipsec.conf: >> >> config setup >> uniqueids=yes >> >> conn %default >> keyingtries=%forever >> type=transport >> auto=route >> ike=aes_gcm256-sha2_256 >> esp=aes_gcm256 >> ikev2=insist > > > Don't use the auto=route keyword in %default (for now) because it will > confuse things because things can start on demand while you also > manually bring things up. So use auto=add in the conn tun-in-1 tun-out-1 I changed it to `auto=add`. >> conn tun-in-1 >> left=10.33.79.236 >> right=10.33.78.213 >> authby=secret >> leftprotoport=udp/6081 >> rightprotoport=udp >> >> conn tun-out-1 >> left=10.33.79.236 >> right=10.33.78.213 >> authby=secret >> leftprotoport=udp >> rightprotoport=udp/6081 > > > Since you use transport mode, I assume those 10.* IP's are native IPs > and that these are not tunneled using other public IPs ? Yes. 10.* IPs are native IPs. > >> In host 2 /etc/ipsec.conf: >> >> config setup >> uniqueids=yes >> >> conn %default >> keyingtries=%forever >> type=transport >> auto=route >> ike=aes_gcm256-sha2_256 >> esp=aes_gcm256 >> ikev2=insist >> >> conn tun-in-1 >> left=10.33.78.213 >> right=10.33.79.236 >> authby=secret >> leftprotoport=udp/6081 >> rightprotoport=udp >> >> conn tun-out-1 >> left=10.33.78.213 >> right=10.33.79.236 >> authby=secret >> leftprotoport=udp >> rightprotoport=udp/6081 > > > >> Then in host 1, I run `ipsec auto --up tun-in-1`. This command can >> succeed. >> >> [root@localhost script]# ipsec auto --up tun-in-1 >> 002 "tun-in-1" #1: initiating v2 parent SA >> 133 "tun-in-1" #1: STATE_PARENT_I1: initiate >> 002 "tun-in-1" #1: tun-in-1 IKE proposals for initial initiator >> (selecting KE): >> 1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_256;INTEG=NONE;DH=MODP2048 >> 133 "tun-in-1" #1: STATE_PARENT_I1: sent v2I1, expected v2R1 >> 002 "tun-in-1" #1: WARNING: connection tun-in-1 PSK length of 12 bytes >> is too short for sha2_256 PRF in FIPS mode (16 bytes required) >> 002 "tun-in-1" #1: tun-in-1 ESP/AH proposals for initiator: >> 1:ESP:ENCR=AES_GCM_C_256;INTEG=NONE;ESN=DISABLED >> 134 "tun-in-1" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 >> {auth=IKEv2 cipher=aes_gcm_16_256 integ=n/a prf=sha2_256 >> group=MODP2048} >> 002 "tun-in-1" #2: IKEv2 mode peer ID is ID_IPV4_ADDR: '10.33.78.213' >> 002 "tun-in-1" #2: WARNING: connection tun-in-1 PSK length of 12 bytes >> is too short for sha2_256 PRF in FIPS mode (16 bytes required) >> 002 "tun-in-1" #2: negotiated connection >> [10.33.79.236-10.33.79.236:6081-6081 17] -> >> [10.33.78.213-10.33.78.213:0-65535 17] >> 004 "tun-in-1" #2: STATE_V2_IPSEC_I: IPsec SA established transport >> mode {ESP=>0x550ec954 <0x3fc4cff0 xfrm=AES_GCM_16_256-NONE NATOA=none >> NATD=none DPD=passive} >> >> However, when I run `ipsec auto --up tun-out-1`, it failed. >> >> [root@localhost script]# ipsec auto --up tun-out-1 >> 002 "tun-out-1" #3: tun-out-1 ESP/AH proposals for initiator: >> 1:ESP:ENCR=AES_GCM_C_256;INTEG=NONE;DH=MODP2048;ESN=DISABLED >> 139 "tun-out-1" #3: STATE_V2_CREATE_I: sent IPsec Child req wait response >> 010 "tun-out-1" #3: STATE_V2_CREATE_I: retransmission; will wait 0.5 >> seconds for response >> 010 "tun-out-1" #3: STATE_V2_CREATE_I: retransmission; will wait 1 >> seconds for response >> 010 "tun-out-1" #3: STATE_V2_CREATE_I: retransmission; will wait 2 >> seconds for response >> 010 "tun-out-1" #3: STATE_V2_CREATE_I: retransmission; will wait 4 >> seconds for response >> >> The LibreSwan version is `Linux Libreswan 3.23 (netkey) on >> 3.10.0-862.9.1.el7.x86_64`. > > > Can you try 3.25 from download.libreswan.org/binaries/rhel/7/ ? > It added more support for create child sa support. I installed `libreswan-3.25-2.el7.x86_64.rpm`. The same error still exists. But I get more information as below: [root@localhost script]# ipsec auto --up tun-in-1 002 "tun-in-1" #4: initiating v2 parent SA 133 "tun-in-1" #4: STATE_PARENT_I1: initiate 002 "tun-in-1" #4: local IKE proposals for tun-in-1 (IKE SA initiator selecting KE): 1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_256;INTEG=NONE;DH=MODP2048 133 "tun-in-1" #4: STATE_PARENT_I1: sent v2I1, expected v2R1 002 "tun-in-1" #4: WARNING: connection tun-in-1 PSK length of 12 bytes is too short for sha2_256 PRF in FIPS mode (16 bytes required) 002 "tun-in-1" #4: local ESP/AH proposals for tun-in-1 (IKE SA initiator emitting ESP/AH proposals): 1:ESP:ENCR=AES_GCM_C_256;INTEG=NONE;DH=NONE;ESN=DISABLED 134 "tun-in-1" #5: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=aes_gcm_16_256 integ=n/a prf=sha2_256 group=MODP2048} 002 "tun-in-1" #5: IKEv2 mode peer ID is ID_IPV4_ADDR: '10.33.78.213' 002 "tun-in-1" #5: WARNING: connection tun-in-1 PSK length of 12 bytes is too short for sha2_256 PRF in FIPS mode (16 bytes required) 003 "tun-in-1" #5: Authenticated using authby=secret 002 "tun-in-1" #5: negotiated connection [10.33.79.236-10.33.79.236:6081-6081 17] -> [10.33.78.213-10.33.78.213:0-65535 17] 004 "tun-in-1" #5: STATE_V2_IPSEC_I: IPsec SA established transport mode {ESP=>0xa19d2649 <0x59126c5a xfrm=AES_GCM_16_256-NONE NATOA=none NATD=none DPD=passive} [root@localhost script]# ipsec auto --up tun-out-1 002 "tun-out-1" #6: local ESP/AH proposals for tun-out-1 (ESP/AH initiator emitting proposals): 1:ESP:ENCR=AES_GCM_C_256;INTEG=NONE;DH=MODP2048;ESN=DISABLED 139 "tun-out-1" #6: STATE_V2_CREATE_I: sent IPsec Child req wait response 003 "tun-out-1" #6: dropping unexpected CREATE_CHILD_SA message containing TS_UNACCEPTABLE notification; message payloads: SK; encrypted payloads: N; missing payloads: SA,Ni,TSi,TSr 010 "tun-out-1" #6: STATE_V2_CREATE_I: retransmission; will wait 0.5 seconds for response 010 "tun-out-1" #6: STATE_V2_CREATE_I: retransmission; will wait 1 seconds for response 010 "tun-out-1" #6: STATE_V2_CREATE_I: retransmission; will wait 2 seconds for response 010 "tun-out-1" #6: STATE_V2_CREATE_I: retransmission; will wait 4 seconds for response > >> Does anyone know what is the issue with my configuration? I also tried >> check the log (/var/log/messages) but I can't get much information. I >> used `ipsec whack --debug all`. Is this the proper way to enable more >> log information? > > > The easiest is to add logfile=/var/log/pluto.log to "config setup" in > /etc/ipsec.conf > > I dont think you need to add plutodebug= or ipsec whack --debug-all to > figure out what is happening now. But if we find a bug then we might > need to do that (but I think then we will just add a test case upstream > to figure out the bug) > > Paul > ps. thanks for using ESP and not AH - I will comment on the draft to do > that, since we are hoping to obsolete AH Thanks, Qiuyu _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
