[Swan] Configuring IPsec for geneve tunnel

[Paul Wouters]

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 at 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 at 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