Otdfbt

I am currently trying to set up a IPsec tunnel between my on-premise center and to the VPN in Azure. I am setting up OpenSwan 2.6.23 on an Ubuntu Lucid box, and my box is behind a NAT.

ipsec.conf

config setup
 nat_traversal=yes
 protostack=netkey
 interfaces=%defaultroute
 klipsdebug=none
 plutodebug=none

conn to-azure
 authby=secret
 auto=start
 type=tunnel

 left=10.0.210.22
 leftid=<my-public-ip>
 leftnexthop=%defaultroute
 leftsubnet=10.0.210.0/24

 right=<azure-gateway-public-ip>
 rightsubnet=10.13.0.0/16
 rightnexthop=%defaultroute

 ike=aes256-sha1-modp1024
 ikev2=insist
 phase2=esp
 phase2alg=aes256-sha1
 pfs=no

ipsec.secrets

<my-public-ip> <azure-gateway-public-ip>: PSK "supersecurepassword"

This is what I receive when I start ipsec, and from what I understand is that it shows the tunnel is established.

000 "to-azure": 10.0.210.0/24===10.0.210.22<10.0.210.22>[<my-public-ip>,+S=C]---10.0.210.3...10.0.210.3---<azure-gateway-public-ip><<azure-gateway-public-ip>>[+S=C]===10.13.0.0/16; erouted; eroute owner: #2
000 "to-azure": myip=unset; hisip=unset;
000 "to-azure": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "to-azure": policy: PSK+ENCRYPT+TUNNEL+UP+!IKEv1+IKEv2ALLOW+IKEv2Init+lKOD+rKOD; prio: 24,16; interface: eth0;
000 "to-azure": newest ISAKMP SA: #1; newest IPsec SA: #2;
000 "to-azure": IKE algorithms wanted: AES_CBC(7)_256-SHA1(2)-MODP1024(2); flags=-strict
000 "to-azure": IKE algorithms found: AES_CBC(7)_256-SHA1(2)_160-2,
000 "to-azure": IKE algorithm newest: _256-SHA1-MODP1024
000 "to-azure": ESP algorithms wanted: AES(12)_256-SHA1(2); flags=-strict
000 "to-azure": ESP algorithms loaded: AES(12)_256-SHA1(2)_160
000 "to-azure": ESP algorithm newest: AES_256-HMAC_SHA1; pfsgroup=<N/A>
000
000 #2: "to-azure":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REPLACE in 27760s; newest IPSEC; eroute owner; nodpd; idle; import:admin initiate
000 #1: "to-azure":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REPLACE in 3484s; newest ISAKMP; nodpd; idle; import:admin initiate
000

However, when I check the auth.logs it shows the following:

added connection description "to-azure"
listening for IKE messages
NAT-Traversal: Trying new style NAT-T
NAT-Traversal: ESPINUDP(1) setup failed for new style NAT-T family IPv4 (errno=19)
NAT-Traversal: Trying old style NAT-T
adding interface eth0/eth0 10.0.210.22:500
adding interface eth0/eth0 10.0.210.22:4500
adding interface lo/lo 127.0.0.1:500
adding interface lo/lo 127.0.0.1:4500
adding interface lo/lo ::1:500
loading secrets from "/etc/ipsec.secrets"
"to-azure" #1: initiating v2 parent SA
"to-azure" #1: transition from state STATE_IKEv2_START to state STATE_PARENT_I1
"to-azure" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
"to-azure" #2: transition from state STATE_PARENT_I1 to state STATE_PARENT_I2
"to-azure" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 auth=IKEv2 cipher=aes_256 integ=sha1 prf=oakley_sha group=modp1024
packet from <azure-gateway-public-ip>: IKEv2 mode peer ID is ID_IPV4_ADDR: '<azure-gateway-public-ip>'
"to-azure" #2: transition from state STATE_PARENT_I2 to state STATE_PARENT_I3
"to-azure" #2: negotiated tunnel [10.0.210.0,10.0.210.255] -> [10.13.0.0,10.13.255.255]
"to-azure" #2: STATE_PARENT_I3: PARENT SA established tunnel mode ESP=>0xeebf6740 <0x4d67c332 xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=none
| releasing whack for #2 (sock=-1)
| releasing whack for #1 (sock=-1)
packet from <azure-gateway-public-ip>: received packet that was neither (I)nitiator or (R)esponder, msgid=0

ipsec verify shows that everything is OK, with OE disabled. Why am I still unable to receive the packet from my Azure instance?

I tried your IPsec.conf file on my CentOS. It works for me. The version of
libreswan installed on my box is 3.15.

To troubleshoot this issue, please follow the steps below:

Verify if the VPN connection has been established correctly. Please try to get the log from Azure VPN Gateway. Here is a good guide: Step-by-Step: Capturing Azure Resource Manager (ARM) VNET Gateway Diagnostic Logs

If the connection has been established properly, then please make sure that routing function has been enabled on the Linux box and the proper route entries have been advertised to your local network.