[strongSwan] QUICK_MODE never receives response from remote host

[Matt Wright]

ya I thought I tried that previously, but I tried it again this morning 
in case I was mistaken, and perhaps I was a little too eager.  I was 
expecting the response to come back from the remote host a little more 
quickly that it appears to have been doing.  so when I saw 2 or 3 
retransmits, I was assuming it wasn't going to work, and gave up.

well... guess this host just takes it's sweet time, and I now got a 
response after 4 retransmits of the initial request, and now my VPN 
tunnel is up

On 3/13/2020 5:27, Noel Kuntze wrote:
> Hello Matt,
>
> Try adding a ! after the esp proposal you want to use.
>
> Kind regards
>
> Noel
>
> Am 12.03.20 um 22:13 schrieb Matt Wright:
>> I've been trying to figure this one out for several hours, have googled a bunch of stuff, but gotten nowhere quick :(
>>
>> I'm trying to setup a tunnel between a machine I control and a remote system controlled by someone else.  Previously to today we had this tunnel setup and running on our local Watchguard router, and it all seemed to be working correctly.  However moving forward I need to get this configuration working elsewhere, so enter strongswan.
>>
>> as far as I can tell everything is setup correctly, however when initiating the connection, phase 1 seems to complete successfully, but as soon as QUICK_MODE starts, I get no response back from the remote host
>>
>> it doesn't help matters, that this is the first time I'm really trying to do anything like this, and the information I've got from the remote host provider is somewhat... vague, so I've had to make educated guesses to even get to this point
>>
>> Below are logs and configuration, and hopefully, someone will be able to shed some light on this.  As mentioned I've tried a whole bunch of different things, so the config is a bit of a mess.
>>
>> ----------------My Config---------------
>>
>> conn VPN
>>          authby=psk #this specifies how the connection is authenticated
>>          auto=add
>>          #rightauth=psk
>>          #aggressive=yes
>>          type=tunnel #the type of connection
>>          left=66.60.177.3 #This is the public ip address of server A
>>          #leftsourceip=%config
>>          #modeconfig=pull
>>          leftsubnet=10.10.10.0/24 #This is the subnet/private ip of server A
>>          right=173.14.59.177 #This is the public ip address of server B/remote server
>>          rightsubnet=10.1.25.0/24 #This is the subnet/private ip of server B
>>          #rightsourceip=172.20.22.0
>>          #rightsubnet=172.20.22.0/24
>>          ike=aes128-sha1-modp1024! #Internet key exchange, type of encryption
>>          #ah=aes128-sha1-modp1024 #Internet key exchange, type of encryption
>>          #esp=aes128-sha1 #Internet key exchange, type of encryption
>>          esp=aes128-sha256-modp1024 #Internet key exchange, type of encryption
>>          #esp=aes128-sha1-modp1024 #Internet key exchange, type of encryption
>>          keyexchange=ikev1 #Internet key exchange version
>>          #pfs=yes
>>          #pfsgroup=modp1024
>>          #rightprotoport = udp/1801
>>          #rightikeport=1801
>>
>> ---------------------configuration information provided by the remote host---------------------
>>
>> Public IP: 173.14.59.177
>>
>> Local network: 10.1.25.0/24
>>
>> Remote network: 172.20.22.0/24
>>
>>   
>>
>> Phase 1
>>
>> key: preshare
>>
>> DH Group: 2
>>
>> encryption: AES 128
>>
>> hash: SHA1
>>
>>   
>>
>> Phase 2
>>
>> DH Group: 2 (pfs)
>>
>> protocal: ESP
>>
>> encryption: AES 128
>>
>> hash: SHA1
>>
>>   
>>
>> Ports
>>
>> TCP: 1801
>>
>> UDP: 1801, 3527
>>
>> --------------------- log-------------------------
>>
>> initiating Main Mode IKE_SA VPN[1] to 173.14.59.177
>> generating ID_PROT request 0 [ SA V V V V ]
>> sending packet: from 66.60.177.3[500] to 173.14.59.177[500] (156 bytes)
>> received packet: from 173.14.59.177[500] to 66.60.177.3[500] (160 bytes)
>> parsed ID_PROT response 0 [ SA V V V ]
>> received unknown vendor ID: 94:36:e8:d6:71:74:ef:9a:ed:06:8d:5a:d5:21:3f:18:7a:3f:8b:a6:00:00:00:16:00:00:06:1e
>> received DPD vendor ID
>> received unknown vendor ID: 48:65:61:72:74:42:65:61:74:5f:4e:6f:74:69:66:79:38:6b:01:00
>> generating ID_PROT request 0 [ KE No ]
>> sending packet: from 66.60.177.3[500] to 173.14.59.177[500] (196 bytes)
>> received packet: from 173.14.59.177[500] to 66.60.177.3[500] (196 bytes)
>> parsed ID_PROT response 0 [ KE No ]
>> generating ID_PROT request 0 [ ID HASH ]
>> sending packet: from 66.60.177.3[500] to 173.14.59.177[500] (76 bytes)
>> received packet: from 173.14.59.177[500] to 66.60.177.3[500] (76 bytes)
>> parsed ID_PROT response 0 [ ID HASH ]
>> IKE_SA VPN[1] established between 66.60.177.3[66.60.177.3]...173.14.59.177[173.14.59.177]
>> scheduling reauthentication in 9941s
>> maximum IKE_SA lifetime 10481s
>> generating QUICK_MODE request 601747937 [ HASH SA No KE ID ID ]
>> sending packet: from 66.60.177.3[500] to 173.14.59.177[500] (316 bytes)
>> sending retransmit 1 of request message ID 601747937, seq 4
>> sending packet: from 66.60.177.3[500] to 173.14.59.177[500] (316 bytes)
>> sending retransmit 2 of request message ID 601747937, seq 4
>> sending packet: from 66.60.177.3[500] to 173.14.59.177[500] (316 bytes)
>> sending retransmit 3 of request message ID 601747937, seq 4
>> sending packet: from 66.60.177.3[500] to 173.14.59.177[500] (316 bytes)
>> sending retransmit 4 of request message ID 601747937, seq 4
>> sending packet: from 66.60.177.3[500] to 173.14.59.177[500] (316 bytes)
>> sending retransmit 5 of request message ID 601747937, seq 4
>> sending packet: from 66.60.177.3[500] to 173.14.59.177[500] (316 bytes)
>> giving up after 5 retransmits
>> establishing connection 'VPN' failed
>>