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

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 ?

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.

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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan

Reply via email to