Hi, I am using a VyOS instance on AWS to establish a IPSec tunnel to an Azure virtual network gateway. I do not want to use NAT-T. I specifically set the authentication id value in the IPSec configuration but after the IPSec parameter are negotiated between the peers over UDP 500, traffic switches to UDP 4500. I have not seen this before - any idea why this is or how to get around it? Only ikev2 is supported on Azure and I have disabled mobike as well as nat-traversal in the hope this would fix the issue - but no luck.
Config:
set vpn ipsec site-to-site peer 20.186.24.44 authentication id '32.51.19.16’
set vpn ipsec site-to-site peer 20.186.24.44 authentication mode ‘pre-shared-secret’
set vpn ipsec site-to-site peer 20.186.24.44 authentication pre-shared-secret ‘123456’
set vpn ipsec site-to-site peer 20.186.24.44 connection-type ‘initiate’
set vpn ipsec site-to-site peer 20.186.24.44 description ‘MSA tunnel1’
set vpn ipsec site-to-site peer 20.186.24.44 ike-group ‘MSA’
set vpn ipsec site-to-site peer 20.186.24.44 ikev2-reauth 'inherit'
set vpn ipsec site-to-site peer 20.186.24.44 local-address ‘172.16.4.10’
set vpn ipsec site-to-site peer 20.186.24.44 vti bind ‘vti2’
set vpn ipsec site-to-site peer 20.186.24.44 vti esp-group ‘MSA’
set vpn ipsec esp-group MSA lifetime '27000'
set vpn ipsec esp-group MSA mode 'tunnel'
set vpn ipsec esp-group MSA pfs 'enable'
set vpn ipsec esp-group MSA proposal 1 encryption 'aes256'
set vpn ipsec esp-group MSA proposal 1 hash 'sha1'
set vpn ipsec ike-group MSA dead-peer-detection action 'restart'
set vpn ipsec ike-group MSA dead-peer-detection interval '15'
set vpn ipsec ike-group MSA dead-peer-detection timeout '30'
set vpn ipsec ike-group MSA ikev2-reauth 'no'
set vpn ipsec ike-group MSA key-exchange 'ikev2'
set vpn ipsec ike-group MSA lifetime '28800'
set vpn ipsec ike-group MSA mobike 'disable'
set vpn ipsec ike-group MSA proposal 1 dh-group '2'
set vpn ipsec ike-group MSA proposal 1 encryption 'aes256'
set vpn ipsec ike-group MSA proposal 1 hash 'sha1'
set vpn ipsec nat-traversal 'disable'
Thanks
Hello,
Azure gateways are in fact behind a NAT, so that’s why 
No way … thank you for that! It was driving me nuts. Do you perhaps have any idea what these frequent packets are traversing the tunnel? I am not sending any data over the tunnel - are these dpd packets perhaps?
1 Like
That’s right, Azure will send IKE traffic when the local traffic counters for each SA haven’t increased in a while. If you had traffic I believe you would not be seeing those anymore.
If your device didn’t respond, Azure would tore down that SA (and IIRC try to negotiate it again). It also used to tore down the SA after 5 minutes or so of inactivity, regardless of your device responding to those packets, but I am not sure if that’s still the case.
Once again, thank you very much. This helps a lot 
1 Like
I just noticed the below in the logs - see “local host is behind NAT” - is this to be expected?
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 09[NET] sending packet: from 172.16.4.10[500] to 20.186.24.44[500] (336 bytes)
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 10[NET] received packet: from 20.186.24.44[500] to 172.16.4.10[500] (364 bytes)
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 10[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V ]
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 10[IKE] received MS NT5 ISAKMPOAKLEY v9 vendor ID
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 10[IKE] received MS-Negotiation Discovery Capable vendor ID
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 10[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 10[IKE] local host is behind NAT, sending keep alives
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 10[IKE] authentication of '32.51.19.16' (myself) with pre-shared key
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 10[IKE] establishing CHILD_SA peer-20.186.24.44-tunnel-vti{1}
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 10[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 10[NET] sending packet: from 172.16.4.10[4500] to 20.186.24.44[4500] (236 bytes)
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 11[NET] received packet: from 20.186.24.44[4500] to 172.16.4.10[4500] (204 bytes)
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 11[ENC] parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr ]
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 11[IKE] authentication of '20.186.24.44' with pre-shared key successful
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 11[IKE] IKE_SA peer-20.186.24.44-tunnel-vti[1] established between 172.16.4.10[32.51.19.16]...20.186.24.44[20.186.24.44]
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 11[IKE] scheduling rekeying in 28009s
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 11[IKE] maximum IKE_SA lifetime 28549s
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 11[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
Aug 16 10:15:15 ip-172-16-4-10 charon[1579]: 11[IKE] CHILD_SA peer-20.186.24.44-tunnel-vti{1} established with SPIs c37e69f8_i 753830b0_o and TS 0.0.0.0/0 === 0.0.0.0/0
Aug 16 10:15:17 ip-172-16-4-10 charon[1579]: 09[NET] received packet: from 20.186.24.44[4500] to 172.16.4.10[4500] (76 bytes)
Aug 16 10:15:17 ip-172-16-4-10 charon[1579]: 09[ENC] parsed INFORMATIONAL request 0 [ ]
Aug 16 10:15:17 ip-172-16-4-10 charon[1579]: 09[ENC] generating INFORMATIONAL response 0 [ ]
Aug 16 10:15:17 ip-172-16-4-10 charon[1579]: 09[NET] sending packet: from 172.16.4.10[4500] to 20.186.24.44[4500] (76 bytes)
Aug 16 10:15:19 ip-172-16-4-10 charon[1579]: 13[NET] received packet: from 20.186.24.44[4500] to 172.16.4.10[4500] (76 bytes)
Aug 16 10:15:19 ip-172-16-4-10 charon[1579]: 13[ENC] parsed INFORMATIONAL request 1 [ ]
Aug 16 10:15:19 ip-172-16-4-10 charon[1579]: 13[ENC] generating INFORMATIONAL response 1 [ ]
Aug 16 10:15:19 ip-172-16-4-10 charon[1579]: 13[NET] sending packet: from 172.16.4.10[4500] to 20.186.24.44[4500] (76 bytes)
Aug 16 10:15:21 ip-172-16-4-10 charon[1579]: 12[NET] received packet: from 20.186.24.44[4500] to 172.16.4.10[4500] (76 bytes)
Aug 16 10:15:21 ip-172-16-4-10 charon[1579]: 12[ENC] parsed INFORMATIONAL request 2 [ ]
Aug 16 10:15:21 ip-172-16-4-10 charon[1579]: 12[ENC] generating INFORMATIONAL response 2 [ ]
I think that is part of the parsing of Azure’s packet, so it may refer to Azure when it says local host. That is if all lines marked with [10] refer to the same packet, which I believe to be the case.
Once again, thanks a lot!
1 Like
