none
VPN question with azure new Virtual network feature

    Question

  • I'm trying out the new VPN feature and connect it to our on site VPN device.  The device is a WatchGuard X500 and we already have a few VPN connections to our other sites.  Here is my question:

    I configure the gateway (phase1) and the tunnel (phase2) and put in the Azure generated shared key.  All looks good but then i get the following error:

    2012-06-08 12:59:48 iked Process 5/6 Msg : failed to process ID payload 4 Debug
    2012-06-08 12:59:48 iked Cannot process MM ID payload from 157.55.196.151:1032 to 66.60.177.226 cookies i=a37acb38 685bc580 r=f7bf3274 3f7c6ed1 msg_id="0203-5029" Debug
    2012-06-08 12:59:49 iked Received fifth message with policy [gateway.azure] from 157.55.196.151:1032 main mode msg_id="0203-5025" Debug

    2012-06-08 12:59:49 iked Searching ID: IP address - policy [gateway.azure] peerId [192.168.4.5] msg_id="0203-4011"

    Since we are not using a Cisco or Juniper device i'm having issues trying to configure our router to accept the connection.  Plus the network on our Azure VPN is 192.168.4.0/24 so i'm not sure where it is getting the 192.168.4.5 IP address from??

    What settings should i configure each phase for on our side when trying to connect to Azure VPN?  Thanks!

    Debug

    Friday, June 08, 2012 7:37 PM

Answers

  • Hi, EDRandD:

    Azure supports the following crypto settings for Phase 2 negotiation:

    Authentication/Hashing: hmac-sha1

    Encryption: AES128 or 3DES

    We recommend a lifetime of 3600 seconds and a lifetime-size of 10240000 KB or more.

    Based on the error message, your P2 negotiation failed on the first message at the responder side.  That seems to indicate either the responder (i.e. your WatchGuard device) does not like the cryptographic transforms specified by the Azure gateway or it does not recognize the traffic selectors (basically the subnet ranges on both sides) specified in the first message.  Please double-check and make sure these parameters are properly specified in your configuration for the WatchGuard device.

    I assume you have already got access to the portal.  If so, you may drill down to one of your virtual networks.  Then you should see a "Download" button at the bottom.  Click that and you will find a list of configuration scripts for our supported VPN routers.  Download one of them to use that as a reference.

    • Marked as answer by Arwind - MSFT Thursday, June 14, 2012 11:34 AM
    Tuesday, June 12, 2012 8:14 AM
    Moderator

All replies

  • We are also having the same issue with a Microsoft Threat Management Gateway (TMG) 2010.

    Our settings are:

    Local Tunnel Endpoint: 1.1.1.1.

    Remote Tunnel Endpoint: 2.2.2.2

    IKE Phase I Parameters:
        Mode: Main mode
        Encryption: AES256
        Integrity: SHA256
        Diffie-Hellman group: Group 2 (1024 bit)
        Authentication Method: Pre-shared secret (0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef)
        Security Association Lifetime: 28800 seconds


    IKE Phase II Parameters:
        Mode: ESP tunnel mode
        Encryption: AES256
        Integrity: SHA256
        Perfect Forward Secrecy: OFF
        Diffie-Hellman group: Group 2 (1024 bit)
        Time Rekeying: ON
        Security Association Lifetime: 3600 seconds

        Kbyte Rekeying: ON
        Rekey After Sending: 102400000 Kbytes

    Site-to-Site Network IP Subnets:
        Subnet: 10.0.0.0/255.255.255.0

    Friday, June 08, 2012 7:57 PM
  • When i was troubleshooting it was asking for the following settings:

    SHA1

    AES (128bit)

    Try that.  I see you are set to 256 and i don't think they support that but i could be wrong i can't get mine to work either :)

    Friday, June 08, 2012 8:00 PM
  • Tried below, still no luck.  I'm trying to find the cheapest supported router to offer.  Bummer SonicWall isn't on the list either.

    IKE Phase I Parameters:
        Mode: Main mode
        Encryption: AES128
        Integrity: SHA1
        Diffie-Hellman group: Group 2 (1024 bit)
        Authentication Method: Pre-shared secret (0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef)


    IKE Phase II Parameters:
        Mode: ESP tunnel mode
        Encryption: AES128
        Integrity: SHA1
        Perfect Forward Secrecy: OFF
        Diffie-Hellman group: Group 2 (1024 bit)
        Time Rekeying: ON
        Security Association Lifetime: 3600 seconds

        Kbyte Rekeying: ON
        Rekey After Sending: 102400000 Kbytes

    Friday, June 08, 2012 8:15 PM
  • What's your error?  Mine is Msg 5 of 6 failed all others passed.

    -King

    Friday, June 08, 2012 8:16 PM
  • Hi!

    We support IKE 1 with AES 128 and 3DES.

    Please refer to http://tmgblog.richardhicks.com/2011/01/25/configuring-site-to-site-vpn-with-forefront-tmg-and-cisco-pix-and-asa/ for information on how to configure TMG server as a site-to-site VPN solution. Please note that this is not formally supported by Microsoft as part of our virtual network preview program. The supported VPN device list is accessible here (http://www.windowsazure.com/en-us/manage/services/networking/)

    We suggest you work with your VPN device manufacturer or leverage their support forums to conffigure Site-to-site VPN.

    Thank you.

    Saturday, June 09, 2012 9:26 PM
    Moderator
  • Hi, EDRandD: Does your WatchGuard router have a command to set peer-id (or proxy-id) for IKE Phase 1 negotiation (I will be very surprised if it does not have such an option, : ))? Please use that command to set the peer-id/proxy-id to be 192.168.4.5. This address you see is actually the IP address of the Azure gateway (i.e. the peer of your WatchGuard router). For the Cisco/Juniper devices we officially support, none of them require such a setting to be explicitly declared, but we are also aware that some device may have such a requirement (and that's also the reason why we do not support these devices officially at this point).
    Sunday, June 10, 2012 6:38 AM
    Moderator
  • YuanYuan,

    That allowed me to successfully connect Phase 1 now I'm having issues with phase two.  What settings does  Azure need for Phase 2?  I get the following errors:

    2012-06-11 14:28:46 iked Phase 2 started by peer with message(id 35) from 157.56.161.236:1024 quick mode msg_id="0203-5081"

    Debug

    2012-06-11 14:28:46 iked PMM rejected Remote P2SA Request, reason code=10102

    Debug

    2012-06-11 14:28:46 iked WARNING: Rejected phase 2 negotiation from 157.56.161.236 due to not preferred IKE gateway (multi-WAN) msg_id="0205-5205"

    Debug

    2012-06-11 14:28:46 QuickMode: <

    Debug

    2012-06-11 14:28:46 iked Rejected QM first message from 157.56.161.236:1024 to 66.60.177.226 cookies i=866d096b 71922f43 r=fef52065 dcaaa5c0 msg_id="0203-5086"

    Debug

    2012-06-11 14:28:46 iked Sending NO_PROPOSAL_CHOSEN message to 157.56.161.236:1024 msg_id="0203-5060"

    Debug

    Monday, June 11, 2012 9:06 PM
  • EDRand, good luck my friend! 

    Since we have different VPN's (and my logging is completely different) I've opened a TMG specific thread here:

    http://social.msdn.microsoft.com/Forums/en-US/windowsazureconnectivity/thread/eff37274-8b25-471a-bbc0-3303a0c58960

    Tuesday, June 12, 2012 4:05 AM
  • Hi, EDRandD:

    Azure supports the following crypto settings for Phase 2 negotiation:

    Authentication/Hashing: hmac-sha1

    Encryption: AES128 or 3DES

    We recommend a lifetime of 3600 seconds and a lifetime-size of 10240000 KB or more.

    Based on the error message, your P2 negotiation failed on the first message at the responder side.  That seems to indicate either the responder (i.e. your WatchGuard device) does not like the cryptographic transforms specified by the Azure gateway or it does not recognize the traffic selectors (basically the subnet ranges on both sides) specified in the first message.  Please double-check and make sure these parameters are properly specified in your configuration for the WatchGuard device.

    I assume you have already got access to the portal.  If so, you may drill down to one of your virtual networks.  Then you should see a "Download" button at the bottom.  Click that and you will find a list of configuration scripts for our supported VPN routers.  Download one of them to use that as a reference.

    • Marked as answer by Arwind - MSFT Thursday, June 14, 2012 11:34 AM
    Tuesday, June 12, 2012 8:14 AM
    Moderator
  • EDRandD,

    I'm having the same issues as you connecting a Watchguard to the Azure Gateway.  I made it past my Phase 1 issue thanks to you and YuanYuan Yu... but I'm still stuck on Phase 2.  Did you resolve your issue?

    I seem to have problems regardless of whether I have PFS-Diddie-Hellman Group2 checked or not and I have authentication set to SHA1, Encryption is AEs-128, and key expiry is 1 hour/102400000kb.

    Any thoughts?  Thanks!

    -Chris

    Thursday, June 21, 2012 8:25 PM
  • Hi, Chris:

    Here is a screenshot of a working setup between a WatchGuard XTM 510 router and the Azure gateway.  Also please disable PFS for Phase 2. I hope this can help you make progress.

    Friday, June 22, 2012 5:46 PM
    Moderator
  • Yu,

    I'm not in front of my box but looking at it this is exactly what i did on a X550e Watchguard and it didn't work.  I'll try again but perhaps the newer XTM models work but the older Edge boxes don't.

    I'll keep you posted. 

    I take it the Internal Gateway IP is .5?

    -King


    • Edited by EDRandD Friday, June 22, 2012 5:59 PM
    Friday, June 22, 2012 5:52 PM
  • Chris,

    I wasn't able to get it to work on a x550e on software 10.2 which is what all our HA setups are so we just went ahead and purchased a supported device like the Juniper SRX210

    What model are you working with?

    -King

    Friday, June 22, 2012 5:53 PM
  • Yu & King -

    Thank you both for your advice; I have an XTM device running 11.5.2 and I had already tried what Yu sent in his screenshots (and then once again after reading his post just in case) but I am still unable to make it work.  In the case I've done something stupid (which is quite possible) with my subnets, let me tell you what my settings were...

    Azure subnets/addresses
    Gateway: 168.62.x.y
    Main Address Space: 10.4.0.0/16
    Subnet FrontEndSubnet: 10.4.2.0/24
    Subnet BackEndSubnet: 10.4.3.0/24
    Local connectivity gateway subnet: 10.4.1.0/24

    XTM Config IP settings:
    Local Gateway: My IP
    Remote Gateway: 168.62.x.y
    Gateway ID for tunnel authentication: 10.4.1.5
    Tunnell addresses: 192.168.x.y/24 <==>10.4.1.0/24

    Any last thoughts before we give up and move to a supported device?

    Thanks again,
    Chris

    Monday, June 25, 2012 1:17 PM
  • Yu & King,

    we have an XTM 330 running 11.5.3 and I had tried to conneted to azure also. The connection works by unchecking the NAT Traversal checkbox, but then it connects but no data running thru the tunnel. It seem to be a NAT-T prob.

    I have tried Yu's config and get the following error.

    2012-06-25 17:09:32 iked (NATT)Select IPSec Transform : NATDiscovered (1). Orig UDP_ENCAP mode (1), in mode (f003)!   Debug
    2012-06-25 17:09:32 iked Select IPSec Transform : keylength match 128  Debug
    2012-06-25 17:09:32 iked Select IPSec Transform : Remote LifeSec 3600, Local LifeSec 3600  Debug
    2012-06-25 17:09:32 iked Select IPSec Transform :Remote LifeKB: 102400000, Local LifeKB: 102400000  Debug
    2012-06-25 17:09:32 iked Check SA Payload: found match proposal (localNum 1 peerNum 1)  Debug
    2012-06-25 17:09:32 iked Rejected QM first  message from 168.63.25.115:1032 to 87.139.7.68 cookies i=f67e767f d870c8b8 r=f29a54a8 7bc118ec  Debug
    2012-06-25 17:09:32 iked IkeNotifyPayloadHtoN : net order spi(0x5c 0xcc 0x93 0xa3)    Debug
    2012-06-25 17:09:32 iked sendto_with_pktinfo: sendmsg with MARKER via fd=12, DestPort=1032 SrcPort=4500  Debug
    2012-06-25 17:09:32 iked  Sending PAYLOAD_MALFORMED message to 168.63.25.115:1032  Debug
    2012-06-25 17:09:32 iked Process IKE Packet: Sent Error Notify Value 16 when P1SA State is 10  Debug
    2012-06-25 17:09:32 iked IkeDeleteQMState: try to delete QMState 0x100eed44 (ID 6) with IsakmpSA 0x100d932c  Debug
    2012-06-25 17:09:32 iked SA Nego Fail: saHandle 0x1087b968 InitMode 0, reason 2  Debug
    2012-06-25 17:09:32 iked findSPINodeBySPI: SPI:0x77001b37 hash:65 : 0x10875e10  Debug
    2012-06-25 17:09:32 iked ipsecSpiNodeFree: SPI(0x77001b37) node deleted from hash table. SPI count:9  Debug
    2012-06-25 17:09:32 iked findSPINodeBySPI: SPI:0x5ccc93a3 hash:75 : 0x10872dc0  Debug
    2012-06-25 17:09:32 iked ipsecSpiNodeFree: SPI(0x5ccc93a3) node deleted from hash table. SPI count:8  Debug
    2012-06-25 17:09:32 iked SA Nego Fail: free saHandle  Debug
    2012-06-25 17:09:32 iked (Delete QMState) rasUserCapacity 5 count 0    Debug
    2012-06-25 17:09:32 iked (Delete QMState) maxPendingP2SARequest 128 current 0   Debug
    2012-06-25 17:09:32 iked Process IKE Packet: delete QM State with retValue 16  Debug
    2012-06-25 17:09:32 iked ike_process_pkt : ProcessData returned error (16)   Debug

    - Joerg

    Monday, June 25, 2012 3:19 PM
  • Joerg,

    We get the same thing and although i was able to get it to connect just like you no data would pass through.  Another error we get is

    2012-06-25 11:05:56 iked WARNING: Rejected phase 2 negotiation from 157.56.x.x due to not preferred IKE gateway (multi-WAN) msg_id="0205-5205"

    So we just gave up and purchased a supported device.  However, if you figure it our or i come across a solution i'll let you know.

    -King

    Monday, June 25, 2012 6:08 PM
  • Hi, Chris:

    A couple problems with your setup:

    1. Your tunnel endpoint definition is incorrect: 192.168.x.y/24 <==>10.4.1.0/24

    This should be <Entire address space in your Azure virtual network> <==> <Entire address space for your on-premise network>

    So based on what you listed above, the tunnel endpoint routes should be:

    192.168.x.y/24 <==> 10.4.0.0/16  (make sure 192.168.x.7/24 is what your specified in your virtual network definition, go to the Azure portal, and then look up the value in "NETWORKS" => "LOCAL NETWORKS" => "ADDRESS SPACE").

    2. The gateway ID for tunnel authentication is not guaranteed to be "10.4.1.5".  That's just one possible value the Azure gateway can take on.  In reality, any address in the gateway subnet (which is 10.4.1.0/24 in your case) is possible (except for the reserved IP addresses such as .0 or .255 obviously).  So please check the log of your WatchGuard device to find out what the internal IP of the Azure gateway actually is.  Don't just assume .5 is the IP, : )  As I have mentioned, we are aware of a few VPN devices with this problem (i.e. having to know the internal IP of the Azure gateway to be able to bring up the tunnel) and as such, they are not in the official list of supported devices.



    Tuesday, June 26, 2012 1:28 AM
    Moderator
  • Hi, Joerg & King:

    We will definitely need NAT-T mode to be enabled on the device in order to have a properly functioning tunnel.  I am not sure how you manage to get to a "Connected" state by unchecking that box, but if I understand IKE correctly, that is just not supposed to work, : )

    Due to limited time and resource, we cannot possibility test all the VPN devices (especially given the fact that even for the same vendor, they have different hardware skus and different versions of the underline OS) available out there.  Unfortunately, WatchGuard devices are not on the supported device list (although we do have one working setup against a particular WatchGuard device/OS as I mentioned above).  But as you can tell (by us answering the questions on this forum and various other support channels), we are still trying to enable our scenario for as many customers as possible, regardless of what devices they currently have in house.  

    We have actually run into the exact same error as you guys did:

    2012-06-18 13:12:42 iked  Sending PAYLOAD_MALFORMED message to 168.63.x.x:1032        Debug
    2012-06-18 13:12:42 iked Process IKE Packet: Sent Error Notify Value 16 when P1SA State is 10    Debug
    2012-06-18 13:12:42 iked IkeDeleteQMState: try to delete QMState 0x8141840 (ID 1) with IsakmpSA 0x811ad20     Debug
    2012-06-18 13:12:42 iked SA Nego Fail: saHandle 0x084659a8 InitMode 0, reason 2         Debug
    2012-06-18 13:12:42 iked SA Nego Fail: free saHandle              Debug

    But later on, it just started working magically using the configuration I posted above.  Honestly, I think the best option is to contact the customer support from WatchGuard as they probably have the best knowledge of what this specific error message indicates. 

    Tuesday, June 26, 2012 2:06 AM
    Moderator
  • Hi Everyone,

    We are trying to get the same setup up and running and are having similar problems.
    After using the suggested phase 1 and phase 2 settings on our firebox XTM520 (11.5.3) we succeeded to get the tunnel up and send some traffic to the azure virtual network.

    The strange thing however is the connection seems to work only when connections are initiated from our side.
    When we ping the virtual machine on the other side the virtual machine can also ping machines in our local subnet. After a while (a few seconds) however this stops working until we initiate a connection again from our side.

    In the watchguard logs we encounter the same PAYLOAD_MALFORMED messages, even when traffic is going over the tunnel.

    We will contact watchguard today to see if they can give some extra pointers.

    Maarten

    Wednesday, June 27, 2012 7:23 AM
  • Watchguard support had a look at our setup and they noticed something :

    Hello Maarten, 
    there's something a bit strange. 
    I can see inside the packet tracer (WebUI -> System Status -> VPN Statistics -> Debug) 
    That the remote peer sends a Phase2 QM1 first message with number of Transforms = 1 
    But it actually sends two Transform sets with the same number of Transform 
    The first one it sends is Transform_ID ESP_AES with proposal: 
    SHA1-AES128 
    the second (with the same Transform number) is Transform_ID ESP_3DES Proposal: SHA1-3DES 
    This can't be correct, either it should only send 1 unique Transform or send as two independant transform sets 
    I am referencing line numbers 36-140 

    ISAKMP Header 
    0: f0 9e 1e 45 b1 c7 88 21 I-COOKIE 
    8: d7 f7 29 55 69 bc 9a 44 R-COOKIE 
    16: 08 Next Payload - ISA_HASH 
    17: 10 Version 1.0 
    18: 20 Exchange is Oakley Quick Mode 
    19: 01 Flags Encrypted 
    20: 00 00 00 01 Message ID 
    24: 00 00 01 1c Payload Length is 284 
    MSG: 13:59:35 Decrypted Payloads <<QM 1st 
    HASH Payload 
    0: 01 Next Payload - ISA_SA 
    1: 00 Reserved 
    2: 00 18 Payload Length is 24 
    4: da 0e ce 1c 4f f7 0a d9 01 2a 3a 57 a8 da ff b5 ....O....*:W.... 
    20: d9 c7 2b b1 ..+. 
    SA Payload 
    24: 0a Next Payload - ISA_NONCE 
    25: 00 Reserved 
    26: 00 78 Payload Length is 120 
    28: 00 00 00 01 DOI - IPSEC 
    32: 00 00 00 01 Situation: IDENTITY_ONLY 
    PROPOSAL Payload 
    36: 02 Next Payload - ISA_PROP 
    37: 00 Reserved 
    38: 00 38 Payload Length is 56 
    40: 01 Proposal Number 
    41: 03 Protocol ID - ESP 
    42: 04 SPI Size = 4 
    43: 01 Number of Transforms = 1 
    44: 88 c5 62 43 SPI 
    TRANSFORM Payload 
    48: 00 Next Payload - NONE 
    49: 00 Reserved 
    50: 00 2c Payload Length is 44 
    52: 01 Transform Number is 1 
    53: 0c Transform ID - ESP_AES 
    54: 00 00 Reserved 
    56: 80 04 f0 03 Class=ENCAPSULATION_MODE, Value=Unknown 
    60: 80 06 00 80 Class=KEY_LENGTH, Value=128 
    64: 80 05 00 02 Class=HMAC_ALG, Value=HMAC_SHA1 
    68: 80 01 00 01 Class=SA_LIFE_TYPE, Value=LIFE_SEC 
    72: 00 02 00 04 Class=SA_LIFE_DURATION, Value=(follows) 
    76: 00 00 0e 10 Value=3600 
    80: 80 01 00 02 Class=SA_LIFE_TYPE, Value=LIFE_KB 
    84: 00 02 00 04 Class=SA_LIFE_DURATION, Value=(follows) 
    88: 06 1a 80 00 Value=102400000 
    PROPOSAL Payload 
    92: 00 Next Payload - NONE 
    93: 00 Reserved 
    94: 00 34 Payload Length is 52 
    96: 02 Proposal Number 
    97: 03 Protocol ID - ESP 
    98: 04 SPI Size = 4 
    99: 01 Number of Transforms = 1 
    100: 88 c5 62 43 SPI 
    TRANSFORM Payload 
    104: 00 Next Payload - NONE 
    105: 00 Reserved 
    106: 00 28 Payload Length is 40 
    108: 01 Transform Number is 1 
    109: 03 Transform ID - ESP_3DES 
    110: 00 00 Reserved 
    112: 80 04 f0 03 Class=ENCAPSULATION_MODE, Value=Unknown 
    116: 80 05 00 02 Class=HMAC_ALG, Value=HMAC_SHA1 
    120: 80 01 00 01 Class=SA_LIFE_TYPE, Value=LIFE_SEC 
    124: 00 02 00 04 Class=SA_LIFE_DURATION, Value=(follows) 
    128: 00 00 0e 10 Value=3600 
    132: 80 01 00 02 Class=SA_LIFE_TYPE, Value=LIFE_KB 
    136: 00 02 00 04 Class=SA_LIFE_DURATION, Value=(follows) 
    140: 06 1a 80 00 Value=102400000

    if there are multiple transforms then it should show inside the Proposal Payload Number of Transforms = 2 

    and then inside the Transform Payload: Transform Number is 1 

    and for the second Transform Number is 2 
    But from my point of view this is definetly wrong 
    That it works for a short moment when you initiate is pretty clear since you only have 1 Transform set configured 

    I tried to add a second proposal (3DES and AES128bit) but the problem described above still exists : both have transform number 1.

    Any ideas ?

    Maarten

    Wednesday, June 27, 2012 12:46 PM
  • Hi to all,

    we talk to Watchguard Support also. It seems to be a non standard configuration and has to be reconfigured on Azure. 

    The remote peer sends a Phase2 QM1 first message with number of Transforms = 1

    But it actually sends two Transform sets with the same number of Transform

    The first one it sends is Transform_ID ESP_AES with proposal:

    SHA1-AES128

    the second (with the same Transform number) is Transform_ID ESP_3DES Proposal: SHA1-3DES

    This can't be correct, either it should only send 1 unique Transform or send as two independent transform sets.

    - Joerg

    • Proposed as answer by Bitspeak Friday, May 24, 2013 3:04 PM
    • Unproposed as answer by Bitspeak Friday, May 24, 2013 3:04 PM
    Thursday, June 28, 2012 10:48 AM
  • YuanYuan, Winner, Agile, Kingaday and everyone else this was all good info.  But after reading some of your replies and talking to support myself i've come to the realization that watchguard XTM and Edge simply won't work with Azure due to some differences in the handshake.  Azure Virtual network is a preview and not a final product so i hope one day they will support watchguard or visa versa but Azure simply doesn't support the device so i've moved on.

    I purchased a Juniper SRX210 and was able to get it working within a day and that's only because i have never configured or even seen JunoOs before in my life :).  I'm still having issue's with it routing to my network but that's just my lack of understanding the CLI and not Azure because i'm able to ping both side's via the device.  Anyone know how to setup a Juno to route traffic from one network to another via a VPN i'm all ears :) i know its easy but just different then what i'm used to.

    anyway thanks everyone and i encourage you to leave your tickets open with Watchguard because that means they will always address them when things change with Azure.  Its NEW and these are NEW type problems but good problems.

    -King

    Thursday, June 28, 2012 6:36 PM
  • Hi, Joerg, Maarten, King:

    Thanks a lot for the feedback.  The feedback from Watchguard's support crew is very insightful.  It is true that for maximum compatibility, the Azure gateway announces two crypto transforms (AES128 and 3DES) and the problem Watchguard folks identified in the logs is very interesting.  I have sent an email to our IPSec team already to ask for their inputs on this issue.  As King said, Windows Azure Virtual Network is still in CTP, so we are trying to identify as many such issues as possible and incorporate the learnings into the ongoing development in order to deliver a more robust product.  Unfortunately, due to limited time and resources, we cannot realistically test/validate our technology against every single VPN device out there.  But that is the whole point of having a CTP release, we chose to push out these features so that we can collect feedback from early adopters like you guys and adjust our priorities based on what the real users out there are trying to do instead of imagining what they should be while sitting in our offices.  While we are investigating this problem internally, in the meantime, the best option for you may just either switch to a support hardware devices or use a software solution that is proven to work (say Microsoft TMG Server 2010).  I really apologize for any inconvenience this may have cost. 

    Friday, June 29, 2012 9:12 AM
    Moderator
  • Hi to all,

    Thanks for screenshots and debug informations. I have now the same error messages for QM on phase 2.

    I hope that Microsoft made the change soon...

    Christophe.


    c.girod

    Friday, June 29, 2012 10:10 AM
  • Hi, c.girod & all:

    I have talked to our IPSec team about this issue.  After reviewing the report from WatchGuard support, here is the response they provided:

    "

    I see nothing wrong with the way we construct the SA payload.

    You may map the below explanation to the  relevant RFC sections:

    http://tools.ietf.org/html/rfc2408#section-3.6

    and

    Sec 4.5 here http://tools.ietf.org/html/rfc2407

     

    There are 2 ESP proposals with 1 transform each.

     

    The first proposal, first transform has Transform-ID of  AES. The authentication algo for ESP is specified via attributes. So attribute of type authentication algo = HMAC-SHA1

     

    The second proposal , first transform has -ID of  3DES. Attribute of type authentication algo = HMAC-SHA1

    "

    So in short, we are not sending 1 proposal with 2 transforms.  We (Windows Azure) are sending 2 proposals, each with a single transform.  

    Another fact is this configuration of the Windows Azure gateway works with many other VPN devices out there (Cisco ASA, Cisco ISR, Cisco ASR, Juniper SRX, Juniper SSG, etc), and we are not doing anything different there.

    So if you still have the support ticket open with WatchGuard, would you please relay this message back to them and see what they have to say?  Their current hypothesis does not seem to be valid to us for the reasons explained above.

    I will also try to see if we have some other way for reaching WatchGuard directly, but I cannot guarantee anything here as I am just a developer not a business relationship person, : )

    Wednesday, July 04, 2012 7:17 PM
    Moderator
  • Hi YuanYuan,

    Do you know what is used for the Windows Azure Gateway (Cisco, TMG, or other) it could help for debug.

    also, could the IPsec team publish the full settings for IPSEC connection instead of script dedicated to Cisco or Juniper hardware. we don't know default settings of all hardware ...

    thanks for your help.

    Christophe.


    c.girod

    Friday, July 06, 2012 8:26 AM
  • Hi, Chris:

    Unfortunately, we cannot disclose the implementation detail of the Azure gateway on the public forum for various reasons.  Hope you can understand, : )

    The second request is a great suggestion.  We will work with our documentation team to see how we can include that in the official MSDN doc for the next release.

    For now, here is the a quick summary for the IPSec settings we support:

    IKE Phase I Parameters:
        Mode: Main mode
        Encryption: AES128 or 3DES
        Integrity: SHA1
        Diffie-Hellman group: Group 2 (1024 bit)
        Authentication Method: Pre-shared key
        Security Association Lifetime: 28800 seconds


    IKE Phase II Parameters:
        Mode: ESP tunnel mode
        Encryption: AES128 or 3DES
        Integrity: SHA1
        Perfect Forward Secrecy: OFF
        Diffie-Hellman group: Group 2 (1024 bit)
        Time Rekeying: ON
        Security Association Lifetime: 3600 seconds
        Security Association Lifesize: 102400000 Kbytes


    Tuesday, July 10, 2012 10:04 AM
    Moderator
  • I had the same error and found something interesting regarding using Watchguard VPN and Azure. We've got a XTM 330 running Fireware XTM v11.7.2. By setting the gateway ID to the same IP as the remote gateway the VPN tunnel connects automatically without any errors and seems to be stable. I’ve also set both phase 1 and 2 to use 256 bit AES (this is used in the Cisco sample configuration scripts).


    Monday, April 22, 2013 1:52 PM
  • Thanks for your post, i will try from our watchguard

    c.girod

    Monday, April 22, 2013 2:53 PM