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

Answer 1

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

Answer 2

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 :)

Answer 3

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

Answer 4

What's your error?  Mine is Msg 5 of 6 failed all others passed.

-King

Answer 5

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.

Answer 6

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).

Answer 7

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

Answer 8

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

Answer 9

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.

Answer 10

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

Answer 11

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.

Answer 12

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

Answer 13

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

Answer 14

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

Answer 15

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

Answer 16

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

Answer 17

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.

Answer 18

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. 

Answer 19

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

Answer 20

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

Answer 21

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

Answer 22

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

Answer 23

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. 

Answer 24

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

Answer 25

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, : )

Answer 26

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

Answer 27

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

Answer 28

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).

Answer 29

Thanks for your post, i will try from our watchguard

---

c.girod