Hi Tom, I'm using similar configuration, but without keyingtries. Give it a chance without this parameter.
And try to set local_addr = 10.17.0.3 in connections.VPN01 due to the following:
10[CFG] looking for peer configs matching 10.17.0.3[%any]...81.xxx.yyy.zzz[81.xxx.yyy.zzz] 10[CFG] no matching peer config found
May be this'll help. On 02.10.2020 19:18, Tom Cannaerts wrote:
I'm trying to setup a connection between a StrongSwan behind NAT and a directly connected Fortigate but I just can't get the connection up. This is the relevant config: # 10.17.0.3 is the private IP of StrongSwan # 83.aaa.bbb.ccc is the public IP of StrongSwan where port 500 and 4500 are NAT'd to the private # 81.xxx.yyy.zzz is the public IP of the Fortigate # 10.16.0.0/24 <http://10.16.0.0/24> is the subnet at the StrongSwan side that I'm trying to tunnel # 10.40.0.0/24 <http://10.40.0.0/24> is the subnet at the Fortigate sida that I'm trying to tunnel connections { VPN01 { version=2 proposals = aes256-sha256-modp2048 keyingtries = 0 remote_addrs = 81.xxx.yyy.zzz local { id = 83.aaa.bbb.ccc auth = psk } remote { id = 81.xxx.yyy.zzz auth = psk } children { VPN01-MAIN { start_action = start esp_proposals = aes256-sha256-modp2048 local_ts = 10.16.0.0/24 <http://10.16.0.0/24> remote_ts = 10.40.0.0/24 <http://10.40.0.0/24> } } } } secrets { ike1 { id = 81.xxx.yyy.zzz secret = secret-goes-here } } When loading this config, following entries appear in the log: 07[NET] received packet: from 81.xxx.yyy.zzz[500] to 10.17.0.3[500] (360 bytes) 07[ENC] parsed IKE_SA_INIT request 0 [ SA KE No ] 07[IKE] 81.xxx.yyy.zzz is initiating an IKE_SA 07[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 07[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(CHDLESS_SUP) N(MULT_AUTH) ] 07[NET] sending packet: from 10.17.0.3[500] to 81.xxx.yyy.zzz[500] (392 bytes) 10[NET] received packet: from 81.xxx.yyy.zzz[500] to 10.17.0.3[500] (240 bytes) 10[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) AUTH SA TSi TSr ] 10[CFG] looking for peer configs matching 10.17.0.3[%any]...81.xxx.yyy.zzz[81.xxx.yyy.zzz] 10[CFG] no matching peer config found 10[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ] I believe the N(AUTH_FAILED) is because he can't match the config, not because of an actual PSK error. I've re-entered the PSK multiple times and even tried using a very simple PSK. So for some reason it can't find a peer config for 81.xxx.yyy.zzz. Is that because it's using the internal IP address for the matching? The strange thing is that I have another tunnel/connection setup with a WatchGuard in another office in pretty much the exactly the same way, and that's working just fine. Anyone an idea on what I can still check? Thanks!
-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
