locked
How to troubleshoot Site to Site IPSEC Tunnel? RRS feed

  • Question

  • I am evaluating the new site to site VPN feature. I have my IPSEC firewall endpoint up on my end. I am using the Cisco device settings. My IPSEC firewall endpoint is showing successful quick mode negotiation always. However main mode negotiation will succeed, and then fail. Firewall logging on my end shows outbound data form Azure IaaS VM is being received by my firewall and passed to my local network, likewise my firewall logging on my end shows outbound data from my local network to Azure. The Azure portal shows DATA OUT is occuring in the VPN.

    The problem is getting from on-premise to Azure. Azure portal shows zero (0) DATA IN. I am never able to get a handshake to occur inbound to Azure. I am wondering how I can get diagostic feedback from Azure host firewalls to further troubleshoot this issue. If I had this data, I would want to inspect what the other side of the tunnel endpoint is seeing from my network.

    The internal LAN network is 172.16.10.0/24

    The Azure VPN network is 172.16.100.0/22
         The ServerSubnet is 172.16.100.0/24
         The GatewaySubnet is 172.16.101/24

    There are three (3) IPSEC events below, the successful main mode, the failure main mode, and the successful quick mode. Quick mode always succeeds and main mode sometimes fails and sometimes succeeds.

    EVENT 1 of 3: MAIN MODE WITH SUCCESS

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          7/30/2012 12:24:20 PM
    Event ID:      4650
    Task Category: IPsec Main Mode
    Level:         Information
    Keywords:      Audit Success
    User:          N/A
    Computer:      CERBERUS.odyssey.com
    Description:
    An IPsec main mode security association was established. Extended mode was not enabled.  Certificate authentication was not used.

    Local Endpoint:
     Principal Name: -
     Network Address: 209.136.145.209
     Keying Module Port: 4500

    Remote Endpoint:
     Principal Name: -
     Network Address: 168.62.8.236
     Keying Module Port: 1024

    Security Association Information:
     Lifetime (minutes): 480
     Quick Mode Limit: 0
     Main Mode SA ID: 1483

    Cryptographic Information:
     Cipher Algorithm: AES-128
     Integrity Algorithm: SHA1
     Diffie-Hellman Group: DH group 2

    Additional Information:
     Keying Module Name: IKEv1
     Authentication Method: Preshared key
     Role: Responder
     Impersonation State: Not enabled
     Main Mode Filter ID: 192749

    EVENT 2 of 3: MAIN MODE WITH FAILURE

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          7/30/2012 12:24:09 PM
    Event ID:      4653
    Task Category: IPsec Main Mode
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      CERBERUS.odyssey.com
    Description:
    An IPsec main mode negotiation failed.

    Local Endpoint:
     Local Principal Name: -
     Network Address: 209.136.145.209
     Keying Module Port: 500

    Remote Endpoint:
     Principal Name:  -
     Network Address: 168.62.8.236
     Keying Module Port: 500

    Additional Information:
     Keying Module Name: IKEv1
     Authentication Method: Unknown authentication
     Role:   Initiator
     Impersonation State: Not enabled
     Main Mode Filter ID: 192749

    Failure Information:
     Failure Point:  Local computer
     Failure Reason:  Negotiation timed out

     State:   Sent first (SA) payload
     Initiator Cookie:  922681fab962366d
     Responder Cookie: 0000000000000000
    Event Xml:

    EVENT 3 of 3: QUICK MODE WITH SUCCESS

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          7/30/2012 12:24:20 PM
    Event ID:      5451
    Task Category: IPsec Quick Mode
    Level:         Information
    Keywords:      Audit Success
    User:          N/A
    Computer:      CERBERUS.odyssey.com
    Description:
    An IPsec quick mode security association was established.
     
    Local Endpoint:
     Network Address: 172.16.10.0
     Network Address mask: 255.255.255.0
     Port:   0
     Tunnel Endpoint:  209.136.145.209

    Remote Endpoint:
     Network Address: 172.16.100.0
     Network Address Mask: 255.255.252.0
     Port:   0
     Private Address:  0.0.0.0
     Tunnel Endpoint:  168.62.8.236

     Protocol:  0
     Keying Module Name: -

    Cryptographic Information:
     Integrity Algorithm - AH: -
     Integrity Algorithm - ESP: SHA-1
     Encryption Algorithm: AES-128

    Security Association Information:
     Lifetime - seconds: 3600
     Lifetime - data:  100000
     Lifetime - packets: 2147483647
     Mode:   Tunnel
     Role:   Responder
     Quick Mode Filter ID: 192509
     Main Mode SA ID: 1483
     Quick Mode SA ID: 3580

    Additional Information:
     Inbound SPI:  1849790146
     Outbound SPI:  466534998
     Virtual Interface Tunnel ID:  0
     Traffic Selector ID:  0

    Thank you,

    John Joyner


    John Joyner MVP-SC-CDM

    Monday, July 30, 2012 5:55 PM

All replies

  • I am seeing my issue previously in the thread:

    http://social.msdn.microsoft.com/Forums/en-US/WAVirtualMachinesVirtualNetwork/thread/b4b8bef1-9546-473a-be84-852e00f3171b

    I have identical situation and identical ask.

    Will proceed with trying other vendor endpoints as suggested by the last post in that thread.


    John Joyner MVP-SC-CDM

    Tuesday, July 31, 2012 1:54 PM
  • Would like to provide this product feedback:

    After identifying an alternative hardware IPSEC endpoint, and working quite some hours to no success, I am disappointed that even though my firewall shows outbound IPSEC traffic trying to establish the tunnel, nothing ever happens on the Azure end. It is a frustrating consumer experience that no feedback from Azure is available. It's an all or nothing proposition which is maybe not going to work with technology as specific as IPSEC site to site VPN.

    Have you guys considered a means to return log traffic to the consumer? I know it might not be in your plans, but to make Azure VPN a commercial success, I recommend add a feature to Azure IaaS VPN that allows the customer to get a filtered log from the Azure firewall system, for example, all traffic from the IP source of your IPSEC tunnel and/or error indications of IPSEC negotiation failure, etc.

    With the current lack of any visibility into whether IKE traffic is even being received by Azure, this is a very hard spot. In lieu of providing the customer with access to their actual trafffic logs, or at least error logs, an acceptable alternative would be no-cost PSS assistance with first-time setup of the VPN. Without either log feedback or the opportunity to engage a human and get feedback, I am concerned Azure VPN won't be viable.

    Thanks for the consideration, 

    John 


    John Joyner MVP-SC-CDM

    Wednesday, August 1, 2012 9:51 PM
  • I wanted to update this thread that we did get success in the Azure Virtual Network using a 'supported' hardware device (Cisco 861, implemented as follows-Internet in the WAN port, a VLAN to the LAN in a switch port). First attempt at Azure VPN with TMG software firewall and second attempt with Fortigate hardware firewall failed. (These might have been been made to work if diagnotic data from the Azure side was available per my last in this thread.)

    I have positive feedback that on the third attempt (but the first attempt with 'supported' hardware) everything worked the first try.

    Based on this experience, it looks like since it's 'all or nothing' with the supported hardware list, then while Azure VPN is a BYOD service, it is expressly not agnostic regarding the customer's IPSEC endpoint. The good news is also that once Azure VPN is up and running it is a seamless experience, expecially if you are already using IPSEC tunnels for branch office and WAN communciation.


    John Joyner MVP-SC-CDM


    Tuesday, August 7, 2012 3:44 AM