2

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?

3
  • Could you ping the private address of your Azure VM from the Linux box? Commented Apr 28, 2017 at 8:50
  • @StevenLee-MSFT No I could not
    – leeeennyy
    Commented May 2, 2017 at 5:09
  • Then it seems that the VPN tunnel has not been established correctly. As I have mentioned, please try to check the log from Azure side. Commented May 2, 2017 at 6:50

1 Answer 1

1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .