[Swan] Bringing up strongSwan+Libreswan transport connection

[Andrew Cagney]

On Sun, 29 Sep 2019 at 17:27, Pavel Volkov <sailor at lists.xtsubasa.org> wrote:
>
> Please help me debug my connection problem.
>
> I have:
>
> 2. Libreswan 3.29 behind NAT for a client.
>
> conn server
>         ike=aes256-sha256
>         esp=aes256-sha256
>         dpdaction=restart
>         dpddelay=35
>         dpdtimeout=300
>         fragmentation=yes
>         rekey=yes
>         auto=start
>         type=transport
>         encapsulation=auto
>         ikev2=insist
>         left=server.example.com
>         leftid=@server.example.com
>         leftrsasigkey=%cert
>         right=%defaultroute
>         rightcert=client.example.com
>         rightid=%fromcert
>         rightrsasigkey=%cert

> However, Libreswan isn't able to finish the process:
>
> pluto[26303]: "server" #1: initiating v2 parent SA
> pluto[26303]: "server": constructed local IKE proposals for server (IKE SA
> initiator selecting KE):
> 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048,MODP3072,MODP4096,MODP8192,ECP_256,ECP_384,ECP_521,CURVE25519
> pluto[26303]: "server" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
> pluto[26303]: "server": constructed local ESP/AH proposals for server (IKE
> SA initiator emitting ESP/AH proposals):
> 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;DH=NONE;ESN=DISABLED
> pluto[26303]: "server" #2: STATE_PARENT_I2: sent v2I2, expected v2R2
> {auth=IKEv2 cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256
> group=MODP2048}
> pluto[26303]: "server" #2: loading root certificate cache
> pluto[26303]: "server" #2: certificate verified OK: CN=server.example.com
> pluto[26303]: "server" #2: IKEv2 mode peer ID is ID_FQDN:
> '@server.example.com'
> pluto[26303]: "server" #2: Authenticated using RSA

(is this from whack or the log file?)

two things are happening here:

- first pluto authenticates that the response did indeed come from the
server, and hence, the contents can be trusted
(this seems to have worked so certs should be ok)
- it uses the network configuration information from the now trusted
packet to establish the tunnel;

I suspect the second step failed, but for some reason it didn't log
it.  Perhaps there's something wrong with the network configuration.
However to spot this you might need to add:
    plutodebug=all
to the config

> pluto[26303]: "server" #2: STATE_PARENT_I2: retransmission; will wait 0.5
> seconds for response
> pluto[26303]: "server" #2: EXPECTATION FAILED: st->st_remote_certs.verified
> == NULL (in decode_certs() at x509.c:696)

The comment that goes with the pexpect() is:

         * Since the MITM has already failed their first
         * attempt at proving their credentials, there's no
         * point in giving them a second chance.

because the authenticated packet was, in the end, rejected, things are
going no where.
I'll tone down the error.

> pluto[26303]: "server" #2: EXPECTATION FAILED:
> ike->sa.st_remote_certs.verified == NULL (in ikev2_parent_inR2() at
> ikev2_parent.c:3684)
> pluto[26303]: "server" #2: X509: CERT payload bogus or revoked
> pluto[26303]: "server" #2: STATE_PARENT_I2: retransmission; will wait 1
> seconds for response
> pluto[26303]: "server" #2: EXPECTATION FAILED: st->st_remote_certs.verified
> == NULL (in decode_certs() at x509.c:696)
> pluto[26303]: "server" #2: EXPECTATION FAILED:
> ike->sa.st_remote_certs.verified == NULL (in ikev2_parent_inR2() at
> ikev2_parent.c:3684)
> pluto[26303]: "server" #2: X509: CERT payload bogus or revoked
> pluto[26303]: "server" #2: STATE_PARENT_I2: retransmission; will wait 2
> seconds for response
> pluto[26303]: "server" #2: EXPECTATION FAILED: st->st_remote_certs.verified
> == NULL (in decode_certs() at x509.c:696)
> pluto[26303]: "server" #2: EXPECTATION FAILED:
> ike->sa.st_remote_certs.verified == NULL (in ikev2_parent_inR2() at
> ikev2_parent.c:3684)
> pluto[26303]: "server" #2: X509: CERT payload bogus or revoked
>
> Security associations creation is also unfinished:
>
> $ sudo ip xfrm state show
> src xxx.xxx.149.202 dst 192.168.1.2
>         proto esp spi 0x9d338af9 reqid 16389 mode tunnel
>         replay-window 0
>         anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
>         sel src xxx.xxx.149.202/32 dst 192.168.1.2/32
>
> Since I use Gentoo here on Libreswan side, maybe I miss something in my
> kernel?
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan