none
Azure VPN with Microsoft TMG 2010 Firewall RRS feed

  • Question

  • I need the exact configuration to connect Microsoft TMG 2010 site to site VPN with Azure:

    Based on the reverse engineering the Cisco and Juniper script (and a clarification on AES from this post), I believe the proper configuration is:

    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

    Also, based on this post, I also tried 3DES based configuration:

    IKE Phase I Parameters:
        Mode: Main mode
        Encryption: 3DES
        Integrity: SHA1
        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: 3DES
        Integrity: SHA1
        Perfect Forward Secrecy: ON
        Diffie-Hellman group: Group 2 (1024 bit)
        Time Rekeying: ON
        Security Association Lifetime: 3600 seconds

        Kbyte Rekeying: ON
        Rekey After Sending: 102400000 Kbytes

    Both configurations do not work.  Can you provide a working configuration?

    If TMG 2010 won't work with Azure, please just say so.


    Tuesday, June 12, 2012 4:03 AM

All replies

  • Did you open UDP 4500 for NAT-T?

    Jason Chen, Windows Azure PM

    Tuesday, June 12, 2012 6:00 AM
    Moderator
  • TMG has a public IP and no other firewall. 

    • Azure VPN Gateway 2.2.2.2
    • Lab Gateway 1.1.1.1

    On my firewall log, I get these 2 entries every 1 minute:

    Initiated Connection

    • TMG-01 6/12/2012 2:51:46 PM Log type: Firewall service Status: The operation completed successfully. Rule: [System] Allow VPN site-to-site traffic to Forefront TMG Source: Azure (2.2.2.2:1032) Destination: Local Host (1.1.1.1:4500) Protocol: IPsec NAT-T Client 
       

    Closed Connection

    • TMG-01 6/12/2012 2:51:35 PMLog type: Firewall service Status: A connection was gracefully closed in an orderly shutdown process with a three-way FIN-initiated handshake. Rule: [System] Allow VPN site-to-site traffic to Forefront TMG Source: Azure (2.2.2.2:1032) Destination: Local Host (1.1.1.1:4500) Protocol: IPsec NAT-T Client

    Based on these results, I would say the port 4500 is open.

    John

    Tuesday, June 12, 2012 9:56 PM
  • Hi

    Disable Use Perfect Forward Secrecy (FPS) in Phase II properties of IPSec configuration. That made the trick for me (still stuck on TCP traffic flow, but at least tunnel appears as stablished in Azure Portal)

    Regards

    Wednesday, June 13, 2012 4:01 PM
  • Still failing with this configuration without PFS (same result on my end).

    IKE Phase I Parameters:
        Mode: Main mode
        Encryption: 3DES
        Integrity: SHA1
        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: 3DES
        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

    Can Microsoft provide any guidance on their own (fairly recent) firewall product configuration with Azure?

    Thursday, June 14, 2012 2:06 AM
  • I can successfully connect using John's settings if I change 3DES to AES128.

    I now get continual request denied errors in the TMG log for a PING request from my remote Azure network to the local network. ie

    • Client IP: 10.4.0.0
    • Destination IP: 172.19.0.0
    • Protocol: PING
    • Action: Denied Connection
    • Result Code: 0xc004002d FWX_E_UNREACHABLE_ADDRESS.

    I assume this is some sort of keep-alive from the Azure network but why to the address 172.19.0.0?

    John, I hope the change to AES128 gets you as far as me and I haven't hijacked your thread.

    Glenn.

    Thursday, June 14, 2012 2:58 AM
  • Glen, are you using Microsoft TMG 2010?  I've tried AES128, still can't connect the session.

    It's so frustrating that Microsoft removed the ability in 2008 R2 to view ETL files (internal to Microsoft only) for the IKE logging.

    Thursday, June 14, 2012 5:02 AM
  • Hello John,

    We are using TMG 2010 with Service Pack 2 installed.

    Glenn.

    Thursday, June 14, 2012 5:08 AM
  • Same problem here.

    It looks like its disconnecting and connecting again in every 2-3 minutes. 

    Thursday, June 14, 2012 9:59 AM
  • Hi

    These are the settings that work for me:

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

    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

    Remote Network 'Azure VNET1 (10.1.x.x)' IP Subnets:
        Subnet: 10.1.0.0/255.255.0.0
        Subnet: 168.63.21.16/255.255.255.255

    Local Network 'Internal' IP Subnets:
        Subnet: 10.0.0.0/255.255.0.0

    Another setting that could be impacting in TCP/UDP/ICMP traffic flow is TMG's extrenal NIC MTU. Seems it has to be 1350

    Regards

    Thursday, June 14, 2012 10:01 AM
  • Everything is working now.

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


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

        Kbyte Rekeying: OFF
    Thursday, June 14, 2012 10:51 AM
  • But still something does not work.

    I cant reach servers on either side. On Azure console everything is green.

    Thursday, June 14, 2012 12:23 PM
  • Ok here is the thing,

    everything seems to be ok. Connection (Site2Site VPN) is established, server in Microsoft (or call it however you want) can reach my internal network and I can see ICMP packets, but reply is not working. Everything on TMG seems to be ok, no Denied packets, everything in log seems to ok, but no packet comes to adapter in Microsoft.

    Maybe I am wrong, but I think that there is no need for static routes on my TMG. I also tried it but it does not work.

    Will Microsoft ever have some service without problems? :)

    Thursday, June 14, 2012 1:24 PM
  • Hi, Glenn:

    You are correct the Ping request against 172.19.0.0 is the "keep-alive" (sort of) packets the Azure gateway sends periodically (you can probably tell from your log that it's once per 60 seconds).  We pick that IP address based on what you have declared when you create the virtual network.  Basically, if your local/on-premise network has a subnet of A.B.C.D, we will just send pings to A.B.C.0.  We do that just to keep the tunnel alive.

    Thursday, June 14, 2012 7:16 PM
    Moderator
  • Hi, John:

    You can still view the ETL files with Win 2K8 R2.  I don't think that functionality has been disabled or removed.  First you can take a wfp capture by running:

    netsh wfp capture start file=FILE_PATH (say FILE_PATH=wfpdiag.cab)

    then stop the capture:

    netsh wfp capture stop

    This will give you a cab file (wfpdiag.cab)

    Now you can extract the ETL file from it:

    extract /a wfpdiag.cab * /y

    If you want an easier to read doc, you can use tracefmt.exe to convert the ETL file (you may probably already know this as I can tell you have pretty good knowledge in this area, : )):

    http://msdn.microsoft.com/en-us/library/windows/hardware/ff552974(v=vs.85).aspx

    tracefmt.exe -o wfpLog.txt -tmf wfp.tmf wfpdiag.etl

    findstr -i ikeext wfpLog.txt > ikeLog.txt (this will give you all the ike related message if the raw wfpLog is too noisy)

    Thursday, June 14, 2012 7:30 PM
    Moderator
  • Hi, Vuk:

    I am sorry about the frustration you are having.  Judging from what you have achieved so far, I don't think the problem is with Windows Azure Virtual Network (+cross-premise connectivity) per se, right?  It feel more like a mis-configuration somewhere else.  Let me ask a few clarification questions first:

    1. Are you seeing ICMP echo replies leaving your TMG server?  When you said "reply is not working", I am not sure what you mean by that exactly.  Is the ping target sending out ICMP echo replies?  You said "everything in log seems to (be) ok", does that mean you saw ICMP echo replies leaving your TMG server?  

    2. I would like to understand your test setup a bit better.  Do you have a VM in the your Azure Virtual Network?  Is that where you are sending out ping tests?  Also, how is the TMG side (i.e your on-premise side) configured? 

    Thursday, June 14, 2012 7:42 PM
    Moderator
  • Hi, Glenn:

    You are correct the Ping request against 172.19.0.0 is the "keep-alive" (sort of) packets the Azure gateway sends periodically (you can probably tell from your log that it's once per 60 seconds).  We pick that IP address based on what you have declared when you create the virtual network.  Basically, if your local/on-premise network has a subnet of A.B.C.D, we will just send pings to A.B.C.0.  We do that just to keep the tunnel alive.

    Should the ping requests be successful? They are failing with FWX_E_UNREACHABLE_ADDRESS. Also they seem to be sent every 10 seconds rather than the 60 seconds you mention.
    Thursday, June 14, 2012 9:54 PM
  • Oops, my bad, Glenn, you are right, the ping is indeed once every 10 seconds.  We do not expect it to be successful because from Azure's point of view, we only know the range of your on-premise subnet, not any specific target.  Even if we somehow know the target, we do not know whether or not it is ping'able (i.e. maybe the target does not allow inbound ICMP).  Therefore we just decided to send a ping against an arbitrary IP address (in this case, A.B.C.0) such that we can keep the tunnel alive.  That's the sole purpose of this dummy ping.
    Thursday, June 14, 2012 10:08 PM
    Moderator
  • Thanks YuanYuan Yu.

    It seems unusual for a site-to-site VPN to require this sort of traffic to keep it connected. Is this because the Azure firewalls are a little strict about disconnecting idle connections?

    With respect to pricing, does this ICMP traffic count towards our Bandwidth or is it included in the Virtual Network Connection Hours?

    Thursday, June 14, 2012 10:45 PM
  • Hi, Glenn:

    During CTP time, Windows Azure Virtual Network is free so this is not gonna incur any cost for our customers.  Also, since this is a CTP release, many implementation details are still being adjusted.  So it's probably not very informative for me to discuss too much of the details in the public forum as things may just change in the future, : )

    Thursday, June 14, 2012 11:12 PM
    Moderator
  • I understand. Thanks.

    We will assume the traffic is included in the Virtual Network hours for now to simplify our cost estimates. When the final details come out we can decide whether to winge or not. :)

    Thursday, June 14, 2012 11:20 PM
  • Sounds good.  Thanks for the understanding, : )
    Friday, June 15, 2012 1:13 AM
    Moderator
  • Hi, Vuk:

    I am sorry about the frustration you are having.  Judging from what you have achieved so far, I don't think the problem is with Windows Azure Virtual Network (+cross-premise connectivity) per se, right?  It feel more like a mis-configuration somewhere else.  Let me ask a few clarification questions first:

    1. Are you seeing ICMP echo replies leaving your TMG server?  When you said "reply is not working", I am not sure what you mean by that exactly.  Is the ping target sending out ICMP echo replies?  You said "everything in log seems to (be) ok", does that mean you saw ICMP echo replies leaving your TMG server?  

    2. I would like to understand your test setup a bit better.  Do you have a VM in the your Azure Virtual Network?  Is that where you are sending out ping tests?  Also, how is the TMG side (i.e your on-premise side) configured? 

    1. Yes, I can see replies from tmg leaving my TMG. What I meant to say is, when server from Azure pings computer on my Internal network I get ICMP packet, but when my client replies, ICMP goes through TMG (PING) but it never goes back to server in Azure. I dont have any deny or some other error on TMG, everything in logs seems to be ok. I can see that tunnel is ok on VPN properties.

    2. Yes, we have VM's on Azure network. Yes, we send pings to and from VM's. On my side I have 2 TMG's, front end and back end. Back End TMG is creating the tunnel. I have multiple tunnels and I have no problems with them.

    Friday, June 15, 2012 8:37 AM
  • Here is a little update,

    I have RV042 Small Business VPN from Cisco and I managed to create VPN connection like on TMG. btw its much easier.

    Anyway, I have still the same problem. I thought that there is a problem with TMG, but its not. I can see packets passing through Cisco device in both ways, but VM in Azure just can't get my reply.

    Is there something about VM's? I just cant figure it out...


    Friday, June 15, 2012 5:46 PM
  • Hi, Vuk:

    The IaaS VMs in Azure running any Windows image have the default windows firewall turned on.  Have you disabled the firewall or added appropriate rules to it (say if you are trying to ping the Azure VM, then you need to add a rule to allow inbound ICMPv4)?  

    That said, I do realize that if you are pinging from the Azure VM to your on-premise VM, then what I said above does not apply (as outbound ICMP traffic are not blocked by default).  If that's the case, then we have to do some deep-diving.


    Friday, June 15, 2012 6:45 PM
    Moderator
  • YuanYuan, the wfp.tmf file does not exist in public Windows Server 2008 R2 (or Windows 7) and is only available internal to Microsoft.

    Please provide more clarification, because your perpetuating a myth (and a time wasteing excercise).

    http://the.techy.dstro.com/ikelogs

    http://blogs.technet.com/b/yuridiogenes/archive/2010/03/30/how-tmg-data-packager-can-assist-you-troubleshooting-vpn-site-to-site-issues.aspx(bottom of comments)

    Also, I'm afraid while the configuration seems to be working for others, but my Azure connection never becomes active in the management portal.

    Can you confirm the TMG configuration for the IPSec tunnell?  PFS needed for phase 2?

    Saturday, June 16, 2012 5:43 AM
  • Hi, Vuk:

    The IaaS VMs in Azure running any Windows image have the default windows firewall turned on.  Have you disabled the firewall or added appropriate rules to it (say if you are trying to ping the Azure VM, then you need to add a rule to allow inbound ICMPv4)?  

    That said, I do realize that if you are pinging from the Azure VM to your on-premise VM, then what I said above does not apply (as outbound ICMP traffic are not blocked by default).  If that's the case, then we have to do some deep-diving.


    Yes, firewalls on VM's in Azure are disabled.
    Monday, June 18, 2012 7:24 AM
  • YuanYuan, the wfp.tmf file does not exist in public Windows Server 2008 R2 (or Windows 7) and is only available internal to Microsoft.

    Please provide more clarification, because your perpetuating a myth (and a time wasteing excercise).

    http://the.techy.dstro.com/ikelogs

    http://blogs.technet.com/b/yuridiogenes/archive/2010/03/30/how-tmg-data-packager-can-assist-you-troubleshooting-vpn-site-to-site-issues.aspx(bottom of comments)

    Also, I'm afraid while the configuration seems to be working for others, but my Azure connection never becomes active in the management portal.

    Can you confirm the TMG configuration for the IPSec tunnell?  PFS needed for phase 2?

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


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

        Kbyte Rekeying: OFF

    This will work and your VPN connection will work. There are just few thing no one tells you.

    This article will help you. http://msdn.microsoft.com/en-us/library/windowsazure/jj156210.aspx

    And read few answers below.


    Monday, June 18, 2012 7:29 AM
  • Hi, John:

    Your TMG configuration looks correct to me.  And PFS is not needed for Phase 2.  We need to get some IKE trace to determine what's not working in the IKE negotiation.  Please email me at yuanyu NoSpamPlease microsoft.com using your work email.  I will find a way to get the IKE trace for us to take a look.

    Monday, June 18, 2012 10:17 PM
    Moderator
  • Vuk:

    Since you are running a 2k8 R2 box, have you installed this patch and see if that resolves your problem?

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;2523881

    John: 

    You can also try to install this patch to see if it helps anything although I think you should at least be able to bring up the tunnel without installing this patch.

    Tuesday, June 19, 2012 8:18 AM
    Moderator
  • Hi YuanYuan

    I can confirm the KB2523881 fix thas solved the issue in my setup, with these TMG settings:

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

    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

    Appart of tunnels's configuration, make sure you have a routing relationship between Internal and Azure networks, and review there are not access rules disallowing all protocols between Internal and Azure

    Thanks!

    Tuesday, June 19, 2012 10:57 AM
  • Tnx Yuan,

    I will try it now and let you know. Sorry for not replying I was little sick.

    cheers

    Thursday, June 21, 2012 12:55 PM
  • Vuk:

    Since you are running a 2k8 R2 box, have you installed this patch and see if that resolves your problem?

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;2523881

    John: 

    You can also try to install this patch to see if it helps anything although I think you should at least be able to bring up the tunnel without installing this patch.

    Thanks Vuk and YuanYuan this solved the problem for me. I setup the tunnel as specified in this post by a number of people. My tunnel was connecting and there was traffic stats on the gateway screen in azure telling me that down traffic was occurring but no upload bytes were recorded. After applying the hotfix and restarting the machine the issue was resolved.

    Thursday, June 21, 2012 1:11 PM
  • This is it.

    I just dont understand why we need to go through all this trouble, and nobody from MS didnt try this first.

    TNX Yuan.

    CHeers

    Thursday, June 21, 2012 1:15 PM
  • Hi Vuk

    Well, in fact we (as Microsoft) did. Internal teams tested Azure-TMG connectivity, having TMG boxes fully updated for the tests. Please note the KB article is about 10 months old.

    Yuan Yuan and me (both MSFT employees, but in very different business) were working on my own not-properly-updated TMG configuration with the idea to both show to customers and help others like people on this thread. How to create and make the IPSec tunnel work for TMG took about 5 minutes with the right configuration. Make the traffic to flow out took some additional time, just because my setup, as yours, was not properly updated. I do not blame product teams for that

    I'm pretty sure the development of an "universal" user-transparent and configuration- gateway as we have in Azure is not an easy task. The work of people like YuanYuan and his team mates is, IMHO, simply amazing. Don't forget also that TMG is not officially supported, probably because Cisco and Juniper are the main priority for development and testing during this preview (because, remember, we are in preview).

    But a TMG, propely configured and patched as shown above works *really* fine. These are the great news

    My 0,02


    Microsoft IT Pro Evangelist

    Friday, June 22, 2012 7:37 PM
  • Having same issue.

    > I see 'Initiated Connection' from Azure client IP, destination port 4500.

    > 60 seconds later the connection is terminated. (Closed Connection: A connection was gracefully closed in an orderly shutdown process with a three-way FIN-initiated handshake.)

    > 10 seconds after termination, 'Initiated Connection' from Azure client IP again.

    Running TMG 2010 with SP2. NIC MTU set to 1350. It's a VM with legacy network adapter connected to WAN.

    Phase 1 -----------------------------

    Encryption Algorithm: AES128

    Integrity Algorithm: SHA1

    Diffe-Hellman group: Group 2 (1024)

    28800 seconds

    Phase 2 -----------------------------

    Encryption Algorithm: AES128

    Integrity Algorithm: SHA1

    Diffe-Hellman group: Group 2 (1024)

    Generate new key every 3600 seconds

    28800 seconds

    PFS unchecked.


    //Also tried the hotfix... didn't do any good.
    • Edited by Wes Kroesbergen Friday, June 22, 2012 9:16 PM Added comment re: hotfix
    Friday, June 22, 2012 9:04 PM
  • Hi, Wes:

    Your problem is a actually bit different as in your case, Phase 1 negotiation did not even complete (based on what you described above).  It seems your host VM is not responding to the IKE negotiation packet from us (the Azure gateway) to your VM's UDP port 4500.  Could you please double check to make sure NAT-T is enabled and UDP 4500 is properly ACL'ed on your VM?  

    Friday, June 22, 2012 9:36 PM
    Moderator
  • This VM is connected directly to our WAN switch... the only thing between it and the outside world is our ISP's Cisco router. I'm guessing that it's blocking the UDP 4500 port? I'm seeing the initiating port as being Azure:1024, destination local:4500. I created a separate rule to explicitly allow UDP4500... didn't do any good.
    Friday, June 22, 2012 10:03 PM
  • David,

    I'm another user who is trying to get this working with TMG. By following the instructions in this thread, I think I have the IPsec tunnel setup, but traffic is not flowing between my Azure VM and local network.

    On the Azure Network page, the Virtual Network/Gateway is shown in blue. My local network is shown in green. I see non-zero numbers under data in and data out. However, I am unable to open a connection from the Azure VM to a local resource.

    On the TMG server, I have an access rule that allows all protocols through. From the TMG I am unable to ping the Azure VM (I disabled the Azure VM firewalls). Attempting to establish a RDP session from the TMG server to the private address of the Azure VM also fails.

    Using the MMC IP Security Monitor, I can see a security association under Main Mode and Quick Mode. I'm assuming (bad thing to do) this means the Phase 1 and Phase 2 connections were successful.

    I'm not sure what I'm missing and I'm new to IPsec so I'm not even sure where to go look. Any help is greatly appreciated.

    Thanks,
    Roger Wilson

    Saturday, June 23, 2012 8:07 AM
  • Some additional notes:

    • I have not modified the NIC MTU setting, is this required?
    • Do I need to create a route in TMG? (I used the Site-to-Site VPN Wizard to create the network, access rule, and network rule - routing). However "route print" doesn't show anything about the Azure network.
    • In the IP Security Monitor > Quick Mode > Statistics, Bad SPI Packets, Confidential Bytes Send, Confidential Bytes Received, Bytes Sent in Tunnels, and Bytes Received in Tunnels shows a positive numbers. Active Security Associations shows 1.

    Thanks
    Roger

    Saturday, June 23, 2012 8:11 AM
  • Hi Roger

    Here is the step by step I followed:

    1.- Apply this fix if your TMG runs Windows Server 2008 R2

    You cannot establish an IPsec tunnel to a computer that is running Windows 7 or Windows Server 2008 R2 through a NAT device

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;2523881

    This bug prevents TMG to send packages to Azure through the S2S IPSec tunnel. The tunnel was established, packages from Azure to internal network arrived fine, was responded by internal hosts but are dropped at TMG internal NIC.

    Site-to-Site Tunnel settings

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

    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

    You must add also the address spaces of al the subnets you have defined in Azure Virtual Network

    Routing relationship

    Yes you must make sure there is a routing relationship between Internal and Azure Network

    Firewall Rule

    The wizard creates access rules between Azure an Internal and vice-versa to allow all the protocols in both directions. You may want choose not creating such rules during the wizard and create one or two access rules afterwards (allow all outgoing traffic for all protocols, all users, from Internal to Azure, and form Azure to Internal)

    Looks like MTU changes is no really needed. But consider there could be some other provider devices between TMG and Azure gateway introducing extra factors in the communications

    If tunnel is shown as established in Azure portal and there is no traffic, please review if you have the fix applied, the routing relationship and the existence on access rules

    Also, you can use Logs&Reports at TMG to filter the traffic based on source or destination network to see if you can pass packages from and to Azure

    Hope this helps

    • Proposed as answer by Roger Wilson Sunday, June 24, 2012 10:37 PM
    Saturday, June 23, 2012 3:14 PM
  • Hi, Wes:

    If you saw the packet from Azure:1024 to your local:4500, then that means the Azure gateway is doing the right thing in trying to switch to NAT-T mode during the IKE negotiation (the first two packets should be exchanged over UDP 500, and the rest over UDP 4500).  Did you see a response for this packet coming out of your VM?  If so, then that packet must be getting dropped somewhere in its way back to the Azure gateway.

    Saturday, June 23, 2012 5:56 PM
    Moderator
  • David,

    Thanks for the help and response! Here's what I have:

    Hotfix Status

     

    I verified hotfix is installed

      

    Site to Site Settings

    Based on your note "You must add also the address spaces of al the subnets you have defined in Azure Virtual Network" when I try to add the individual subnets I get the following warning.

    In Azure I have defined a network, 10.69.0.0/16 with 3 subnets

    1. FrontEndSubnet  10.69.2.0/24
    2. BackEndSubnet 10.69.3.0/24
    3. ADDNSSubnet 10.69.4.0/24

    On the Remote Site Properties should I have the subnets or the larger network 10.69.0.0/16 listed? When I try to list the subnets, I get the following warning:

    "There are adjacent address ranges in the remote site networks. This will cause IPsec tunnel establishment to fail. Use non-adjacent ranges in the networks. For more information, see the document Troubleshooting Virtual Private Networking on the Microsoft Forefront TMG TechCenter Web Site. Click OK to continue, or click Cancel to change the address ranges."

    Current Site to Site Settings:

    Local Tunnel Endpoint: 75.145.120.4

    Remote Tunnel Endpoint: 157.56.164.114

     

    To allow HTTP proxy or NAT traffic to the remote site,

    the remote site configuration must contain the local

    site tunnel end-point IP address.

     

    IKE Phase I Parameters:

        Mode: Main mode

        Encryption: AES128

        Integrity: SHA1

        Diffie-Hellman group: Group 2 (1024 bit)

        Authentication Method: Pre-shared secret (removed)

        Security Association Lifetime: 28800 seconds

     

     

    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

     

    Remote Network 'Azure Infrastructure' IP Subnets:

        Subnet: 10.69.0.0/255.255.0.0

        Subnet: 157.56.164.114/255.255.255.255

     

    Local Network 'Internal' IP Subnets:

        Subnet: 192.168.100.0/255.255.255.0

     

    VPN Static Pool on Server 'DENEDGE2' IP Subnets:

        Subnet: 192.168.102.1/255.255.255.255

        Subnet: 192.168.102.50/255.255.255.255

        Subnet: 192.168.102.2/255.255.255.254

        Subnet: 192.168.102.48/255.255.255.254

        Subnet: 192.168.102.4/255.255.255.252

        Subnet: 192.168.102.8/255.255.255.248

        Subnet: 192.168.102.16/255.255.255.240

        Subnet: 192.168.102.32/255.255.255.240

     

    Routable Local IP Addresses:

        Subnet: 192.168.100.0/255.255.255.0

     

    Routing Relationship

    Regarding the routing relationship, do you mean to create a Network Topology Route in Networking > Routing? Or do you mean to have a Network Rule that routes between Azure and Internal? I currently have the latter, and no Network Topology Routes.

     

    I updated my network rule to match your image, previously I had

    Source: Azure; Destination: Internal;

    now I have

    Source: Azure, Internal; Destination: Azure, Internal) 

     

    Under the Routing Tab there is no reference to my Azure network (10.69.0.0/16). No Network Topology Routes, no Active Server Routes to 10.69.0.0/16. There are other active server routes which are correct for my environment.

     

    Firewall Rule

     

    I allowed the Site-to-Site VPN wizard to create the access rule and it matches your image.

     Still not passing traffic (ping from Azure VM to a local server fails - Request timed out)

    Here's the log from TMG capturing the ping (note, I don't see my specific ping)

    Any ideas?

    Thanks,

    Roger

     

    Saturday, June 23, 2012 8:39 PM
  • PS. Don't know if this would help, but here's the output of the command:
    netsh IPsec dynamic show all

    No currently assigned Policy

    Mainmode Policies not available.


    Quickmode Policies not available.


    Generic Mainmode Filters not available.


    Specific Mainmode Filters not available.


    Generic Quickmode Filters not available.


    Specific Quickmode Filters not available.


    IKE Main Mode SAs at 6/23/2012 3:02:32 PM
    -------------------------------------------------------------------------------
    Cookie Pair            : 99c69604a9c8824d:a22bef583547fd7b
    Sec Methods            : NONE/SHA1/2/7200
    Auth Mode              : Preshared Key
    Source                 : 75.145.120.4    , port 37905
    ID                     : 75.145.120.4   
    Destination            : 157.56.164.114  , port 4
    ID                     : 157.56.164.114 

     

    Quick Mode SAs
    --------------

    Transport Filter

    Source Address         : 75.145.120.4   
    Destination Address    : 157.56.164.114 
    Protocol               : ANY
    Source Port            : 0
    Destination Port       : 0
    Direction              : Inbound
    Encapsulation Type     : Other
    Source UDP Encap port  : 4500
    Dest UDP Encap port    : 1024
    Peer Private Addr      : 0.0.0.0        

    Offer Used 

      AH(b/r)   ESP Con(b/r) ESP Int  PFS DH Group
    ---------- ------------- -------  ------------
      None       None         SHA1    <Unassigned>    

    IPsec Configuration Parameters
    ------------------------------
    StrongCRLCheck         : 1
    IPsecexempt            : 3

     

    IPsec Statistics
    ----------------

    Active Assoc                : 1
    Offload SAs                 : 0
    Pending Key                 : 0
    Key Adds                    : 171
    Key Deletes                 : 217
    ReKeys                      : 0
    Active Tunnels              : 1
    Bad SPI Pkts                : 12
    Pkts not Decrypted          : 0
    Pkts not Authenticated      : 0
    Pkts with Replay Detection  : 0
    Confidential Bytes Sent     : 2,304
    Confidential Bytes Received : 386,280
    Authenticated Bytes Sent    : 3,168
    Authenticated Bytes Received: 386,280
    Transport Bytes Sent        : 0
    Transport Bytes Received    : 0
    Bytes Sent In Tunnels       : 3,168
    Bytes Received In Tunnels   : 386,280
    Offloaded Bytes Sent        : 0
    Offloaded Bytes Received    : 0

     

    Saturday, June 23, 2012 9:03 PM
  • I deleted everything from both the TMG server and the Azure side. Recreated the Azure VPN and recreated the remote site in TMG and now everything is working. I wonder if my initial Azure/TMG attempt ended up in a strange state in one or both of the environments.

    David, thanks for the nice write up, it was very helpful!

    Roger

    Sunday, June 24, 2012 10:37 PM
  • Hi David,

    please note that my servers are updated always.

    What Yu suggested is hotfix, yes it is year old, but it was never installed on my TMG, as you can see in posts no one got that hotfix automatically on their TMG Server.

    TMG is your product, still you give walk-throughs for CISCO and JUNIPER devices. That is silly if you ask me. You must have appropriate walkthrough for your own  product.

    Maybe I'm wrong...

    Monday, June 25, 2012 12:55 PM
  • Update: Here's a Netmon trace:

    =======================================================

    =======================================================

    Here's the output of my IPSec dump. 

    =======================================================

    No currently assigned Policy

    Mainmode Policies not available.


    Quickmode Policies not available.


    Generic Mainmode Filters not available.


    Specific Mainmode Filters not available.


    Generic Quickmode Filters not available.


    Specific Quickmode Filters not available.


    IKE Main Mode SAs at 6/25/2012 10:24:33 AM
    -------------------------------------------------------------------------------
    Cookie Pair            : 7edb73819f0b2eda:3a6cdfafb9775764
    Sec Methods            : NONE/SHA1/2/7200
    Auth Mode              : Preshared Key
    Source                 : 216.13.141.45   , port 37905
    ID                     : 216.13.141.45   
    Destination            : 168.62.104.231  , port 4
    ID                     : 168.62.104.231  


    IPsec QuickMode Security Associations not available.


    IPsec Configuration Parameters
    ------------------------------
    StrongCRLCheck         : 1
    IPsecexempt            : 3



    IPsec Statistics
    ----------------

    Active Assoc                : 0
    Offload SAs                 : 0
    Pending Key                 : 0
    Key Adds                    : 0
    Key Deletes                 : 0
    ReKeys                      : 0
    Active Tunnels              : 0
    Bad SPI Pkts                : 0
    Pkts not Decrypted          : 0
    Pkts not Authenticated      : 0
    Pkts with Replay Detection  : 0
    Confidential Bytes Sent     : 0
    Confidential Bytes Received : 0
    Authenticated Bytes Sent    : 0
    Authenticated Bytes Received: 0
    Transport Bytes Sent        : 0
    Transport Bytes Received    : 0
    Bytes Sent In Tunnels       : 0
    Bytes Received In Tunnels   : 0
    Offloaded Bytes Sent        : 0
    Offloaded Bytes Received    : 0



    • Edited by Wes Kroesbergen Monday, June 25, 2012 3:51 PM Added packet capture screenshot
    Monday, June 25, 2012 2:26 PM
  • I'm facing the very same problem as Wes, but in a real machine, no VM:

     - I see 'Initiated Connection' from Azure client IP, destination port 4500.

     - 60 seconds later the connection is terminated. (Closed Connection: A connection was gracefully closed in an orderly shutdown process with a three-way FIN-initiated handshake.)
     - 10 seconds after termination, 'Initiated Connection' from Azure client IP again.
     - Running TMG 2010 with SP2, Windows Server 2008 R2 SP1 with KB2523881.

    My summary:

    Local Tunnel Endpoint: 193.XXX.XXX.XXX (TMG public adapter)
    Remote Tunnel Endpoint: 168.YYY.YYY.YYY (Azure Gateway IP)

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

    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

    No luck, I keep getting "Connecting" from Azure network configuration.

    Monday, June 25, 2012 6:58 PM
  • Hi, Wes:

    It's kinda hard for me to determine the root cause just given this short/incomplete snippet of netmon capture.  Could you please either share the entire packet capture (at least containing two sequences of IKE negotiation) somewhere (say Skydrive) and send me the link (yuanyu NoSpamPlz microsoft.com)?  Or you can email the packet capture to me directly if it's not too big (I think you are already applying a filter "IPv4.Address == 168.62.104.231", so that should keep the size pretty small).  

    Tuesday, June 26, 2012 2:48 AM
    Moderator
  • I am glad you got it working, Garry, : )
    Tuesday, June 26, 2012 7:47 AM
    Moderator
  • YuanYuan, I sent you a packet capture. It looks absolutely similar to the Wes' one.

    Tuesday, June 26, 2012 8:51 AM
  • I just emailed you the packet capture.
    Tuesday, June 26, 2012 2:48 PM
  • Working on the same problem (but with ISA2006). Shouldn't this port be open by default due to System policy 14-15 (Allow VPN site-to-site traffic to/from ISA Server.

    These rules open IPsec NAT-T port 4500 UDP for Send Receive and Receive Send as Client and Server side.

    Thursday, June 28, 2012 9:24 AM
  • Hi, Wes & cmilanf:

    I apologized for the delayed reply.  I have been busy with (and am still) a couple high-priority tasks in the past few days so I just got around to take a look at this again.

    I looked at both of your packet captures (thanks for sending me those).  It seems to me that the P2 negotiation failed at the first message exchange, which basically indicates that your TMG box is telling the Azure gateway that it does not like some of the phase 2 parameter it specified in the first message.  Given the fact that your crypto parameters all look correct, I am suspecting that the traffic selector may be mismatching.  Would you guys please provide me the following:

    1. The local network address space and the virtual network address space you picked when creating the virtual network.  

    2. The address range you defined for your TMG rule (go to the "Addresses" tab and look for "IP address ranges included in this network").

    Friday, June 29, 2012 8:40 AM
    Moderator
  • Hi, Johan:

    I was not doubting the ACL rules on the end host.  What I was suspecting is the some other network device in the middle might be dropping packets on UDP 4500 (I have seen such cases before).  But after looking at their packet capture, the problem appears to be the Phase 2 parameters rather than ACL rules. 

    Friday, June 29, 2012 8:43 AM
    Moderator
  • Hi Yuan,

    1)

    -> Local Network Address Space: 192.168.0.0/17

    -> Virtual Network Address Space: 10.100.0.0/16

    2)

    -> TMG Address Range: 10.100.0.0 - 10.100.254.0 (plus the Azure IP)

    //Appreciate the time you're taking to look into this.
    • Edited by Wes Kroesbergen Friday, June 29, 2012 1:39 PM Added note re: Azure IP
    Friday, June 29, 2012 1:23 PM
  • Hi, Wes:

    For the TMG address range, it should match exactly with the Virtual Network Address Space.  So in your case, the TMG address range should be "Start Address: 10.100.0.0" and "End Address: 10.100.255.255" and plus the Azure gateway IP.  If you look at David's screenshot, I believe his virtual network address space is 10.1.0.0/16, so in his case, he specified "Start Address: 10.1.0.0" and "End Address: 10.1.255.255" and plus his Azure gateway IP.

    • Proposed as answer by cmilanfMVP Monday, July 2, 2012 1:50 PM
    Friday, June 29, 2012 6:14 PM
    Moderator
  • YuanYuan, after your hints I got it working, thank you so much for your time! It has been really really helpful.

    Monday, July 2, 2012 1:49 PM
  • I've tried all the hints mentioned above and still not working.

    I'm glad if someone could help.

    IKE Phase I Parameters:
         Mode: Main mode
         Encryption: AES128
         Integrity: SHA1
         Diffie-Hellman group: Group 2 (1024 bit)
         Authentication Method: Pre-shared secret (xxxxxxxxxx)
         Security Association Lifetime: 28800 secondos

    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

    In our TMG we've got 3 existing networks:
     HQ: 172.16.0.0/24
     Branch 1: 172.16.24.0/24
     Branch 2: 172.16.41.0/24

    TMG is updated with SP2 and hotfix KB2523881

    Azure's config:

     Addresses: 10.1.0.0/16
     Subnets:
      1: 10.1.1.0/24
      2: 10.1.2.0/24
      3: 10.1.3.0/24

    Local Connectivity
     Gateway subnet: 10.1.0.0/24

    Local networks
     Address space: 172.16.0.0/24
     VPN Gateway: 86.x.x.x


    In TMG's log I see almost the same that Agile IT - John
    But the protocol is IKE and port is 500 instead port 4500 and protocol IpSec NAT-T Client.

    Initiated Connection
    •TMG-01 02/07/2012 18:18:46 PM Log type: Firewall service Status: The operation completed successfully. Rule: [System] Allow VPN site-to-site traffic to Forefront TMG Source: Azure (2.2.2.2:1032) Destination: Local Host (1.1.1.1:500) Protocol: IKE Client
     
     
    Closed Connection
    •TMG-01 02/7/2012 18:19:46 PMLog type: Firewall service Status: A connection was gracefully closed in an orderly shutdown process with a three-way FIN-initiated handshake. Rule: [System] Allow VPN site-to-site traffic to Forefront TMG Source: Azure (2.2.2.2:1032) Destination: Local Host (1.1.1.1:4500) Protocol: Ike Client


    In windows Azure It's always 'connecting' and the box is yellow. I've never seen it in connected state (Green Box)

    Any help would be apprecciated

    Monday, July 2, 2012 4:33 PM
  • Yuan, that appears to have worked! The VPN is now reporting as connected in the Azure management console, and I see successful VPN connection established in the TMG logs, though it still disconnects periodically. I see a successful ping through though.
    Wednesday, July 4, 2012 1:15 PM
  • Hi, Wes:

    Hmm, the tunnel should be fairly stable because we only rekey every 3600 seconds (or 1 hour) for the P2 SA.  How often do you see the tunnel get disconnected? Does that affect the performance/reliability of your business scenario? 

    Wednesday, July 4, 2012 7:20 PM
    Moderator
  • Hi, cfr1983:

    What is the TMG log message you are exactly getting?  What you pasted above seems to be weird because the "Initiated Connection" refers to UDP port 500 whereas the "Closed Conenction" refers to UDP port 4500.  The Azure gateway will negotiate the tunnel first via UDP 500 (first 2 messages) and then switch to UDP 4500 (the next few message exchanges).  If you never see any traffic over UDP 4500 during tunnel negotiation, then something is wrong with your local network setting.  You need to make sure inbound/outbound UDP 4500 are open for NAT-T.

    Wednesday, July 4, 2012 7:24 PM
    Moderator
  • Hi, YuanYuan.


      Sorry, bad copy&paste. Here's the real log:

    Transport Source Port Processing Time Bytes Sent Bytes Received Original Client IP Log Time Client IP Destination IP Destination Port Protocol Action Rule Result Code Source Network Destination Network
    UDP 1024 0 0 0 168.63.x.x 05/07/2012 9:01 168.63.x.x 192.168.1.2 500 IKE Client Initiated Connection [System] Allow VPN client traffic to Forefront TMG 0x0 SUCCESS Azure Local Host
    UDP 1024 61000 296 84 168.63.x.x 05/07/2012 9:02 168.63.x.x 192.168.1.2 500 IKE Client Closed Connection [System] Allow VPN client traffic to Forefront TMG 0x80074e20 FWX_E_GRACEFUL_SHUTDOWN Azure Local Host
    UDP 1024 0 0 0 168.63.x.x 05/07/2012 9:02 168.63.x.x 192.168.1.2 500 IKE Client Initiated Connection [System] Allow VPN client traffic to Forefront TMG 0x0 SUCCESS Azure Local Host
    UDP 1024 61000 296 84 168.63.x.x 05/07/2012 9:03 168.63.x.x 192.168.1.2 500 IKE Client Closed Connection [System] Allow VPN client traffic to Forefront TMG 0x80074e20 FWX_E_GRACEFUL_SHUTDOWN Azure Local Host

    I never receive any traffic over UDP 4500.

    I think that all ports are open and redirected to the TMG server because it's configured as DMZ host in the modem/router. We've never problems with closed ports. But the modem/router is one provided by our ISP for home purpouses (It's a test network)

    How can we test if it supports NAT-T? I guess that it could be the problem.

    Thanks in advance.


    • Edited by cfr1983 Thursday, July 5, 2012 7:27 AM
    Thursday, July 5, 2012 7:22 AM
  • I keep experiencing issues with setting up the connection through TMG.

    lab (192.168.2.0/24) - TMG -(192.168.1.0/24) - Router - (1.1.1.1) - azure gateway (2.2.2.2) - virtual network (10.4.0.0/16)

    Router forwards 500 UDP & 4500 UDP to external nic of TMG (192.168.1.116)


    Virtual Network
    ----------------------------
    address space : 10.4.0.0/16

    Subnets
    FrontEnd 10.4.2.0/24
    Backend  10.4.2.0/24
    ADDNS    10.4.3.0/24

    Gateway  10.4.1.0/24

    ----------------------------

    Local Tunnel Endpoint: 192.168.1.116
    Remote Tunnel Endpoint: 2.2.2.2

    To allow HTTP proxy or NAT traffic to the remote site,
    the remote site configuration must contain the local
    site tunnel end-point IP address.

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


    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

    Remote Network 'AcmeCloud' IP Subnets:
        Subnet: 10.4.0.0/255.255.0.0
        Subnet: 2.2.2.2/255.255.255.255

    Local Network 'Internal' IP Subnets:
        Subnet: 192.168.2.0/255.255.255.0

    Local Network 'Perimeter' IP Subnets:
        Subnet: 192.168.3.0/255.255.255.0

    Routable Local IP Addresses:
        Subnet: 192.168.2.0/255.255.255.0

    I used auditpol to log events to the security event log. and tried to scenarios with the local address space on the azure side. the following error remain in the security log after a connection is made.

    ---------------------------------------------------------

    Local Address 192.168.2.0/24

    Event ID 4650 IPSec Main Mode:

    An IPsec main mode security association was established. Extended mode was not enabled.  Certificate authentication was not used.

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

    Remote Endpoint:
     Principal Name: -
     Network Address: 2.2.2.2
     Keying Module Port: 1032

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

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


    Event ID 4654 IPSec Quick Mode:

    An IPsec quick mode negotiation failed.

    Local Endpoint:
     Network Address: 192.168.2.0
     Network Address mask: 255.255.255.0
     Port:   0
     Tunnel Endpoint:  192.168.1.116

    Remote Endpoint:
     Network Address: 10.4.0.0
     Address Mask:  255.255.0.0
     Port:   0
     Tunnel Endpoint:  2.2.2.2
     Private Address:  0.0.0.0

    Additional Information:
     Protocol:  0
     Keying Module Name: IKEv1
     Virtual Interface Tunnel ID: 0
     Traffic Selector ID: 0
     Mode:   Tunnel
     Role:   Responder
     Quick Mode Filter ID: 114482
     Main Mode SA ID: 3

    Failure Information:
     State:   No state
     Message ID:  1
     Failure Point:  Local computer
     Failure Reason:  Invalid situation


    -----------------------------------------------------------

    Local Address 192.168.0.0/22

    Event ID 4650 IPSec Main Mode:

    An IPsec main mode security association was established. Extended mode was not enabled.  Certificate authentication was not used.

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

    Remote Endpoint:
     Principal Name: -
     Network Address: 2.2.2.2
     Keying Module Port: 1032

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

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


    Event ID 4654 IPSec Quick Mode:

    An IPsec quick mode negotiation failed.

    Local Endpoint:
     Network Address: 192.168.0.0
     Network Address mask: 255.255.252.0
     Port:   0
     Tunnel Endpoint:  192.168.1.116

    Remote Endpoint:
     Network Address: 10.4.0.0
     Address Mask:  255.255.0.0
     Port:   0
     Tunnel Endpoint:  2.2.2.2
     Private Address:  0.0.0.0

    Additional Information:
     Protocol:  0
     Keying Module Name: IKEv1
     Virtual Interface Tunnel ID: 0
     Traffic Selector ID: 0
     Mode:   Tunnel
     Role:   Responder
     Quick Mode Filter ID: 0
     Main Mode SA ID: 4

    Failure Information:
     State:   No state
     Message ID:  1
     Failure Point:  Local computer
     Failure Reason:  No policy configured


    • Edited by b.danse Monday, July 9, 2012 4:38 PM
    Monday, July 9, 2012 2:28 PM
  • Hi, cfr1983:

    If you never receive any packets heading over to UDP 4500 on your TMG box, then there is something wrong with your upstream network (in this case, very likely your modem/router).  The Azure gateway will switch to the NAT traversal mode (i.e. switching to use UDP 4500) after the first couple packet exchanges.  To test whether the packet heading over to UDP 4500 is arriving at your TMG box, you can run a simple packet capture (using wireshark or netmon) and then look for such packets.  If you upstream router does not have the proper ACL to allow inbound traffic towards UDP 4500, then these packets can be dropped before they reach your TMG box, in which case, you need to adjust the ACL settings on that device.

    Tuesday, July 10, 2012 10:32 AM
    Moderator
  • Hi, b.danse:

    It seems your TMG server is behind a NAT device (i.e. your router).  We do not support this setup (i.e. responder behind NAT) in this release.  As our MSDN doc calls out, we require the peer to have an Internet routable IP address that is directly accessible.

    Tuesday, July 10, 2012 10:40 AM
    Moderator
  • HI Guys,

    I have setup the VPN IPSEC connection between Azure and my local TMG server.

    I can ping from azure the IPs on my local network, but I can't

    * ping the TMG ip address (192.168.1.1) and use the DNS installed on the TMG box 
    * ping the azure servers (10.10.1.x) from my local network (192.168.1.0) through TMG.

    Any ideas why the ping is going only one way (AZ->TMG) and not the opposite way (local net->TMG->AZ) and why I cannot ping/... from Azure the TMG interfaces ?

    Thanks in advance for your help !

    Best regards

    Cedric

    Saturday, July 14, 2012 10:39 PM
  • Hi, cfr1983:

    If you never receive any packets heading over to UDP 4500 on your TMG box, then there is something wrong with your upstream network (in this case, very likely your modem/router).  The Azure gateway will switch to the NAT traversal mode (i.e. switching to use UDP 4500) after the first couple packet exchanges.  To test whether the packet heading over to UDP 4500 is arriving at your TMG box, you can run a simple packet capture (using wireshark or netmon) and then look for such packets.  If you upstream router does not have the proper ACL to allow inbound traffic towards UDP 4500, then these packets can be dropped before they reach your TMG box, in which case, you need to adjust the ACL settings on that device.

    Hi, YuanYuan,

    Sorry, I was out of office last week.


             I think you're right I never see anything in port UDP 4500. I think that the router doesn't support NAT-T.

             I used wireshark to log our TMG server and I only see one packet (Appended at the end of this post) I double checked all the configuration and I believe it's everything OK. I'll buy a new NAT-T compatible router.



             And here's the log:

    No.     Time        Source                Destination           Protocol Info
       2234 529.574627  168.63.x.x         192.168.1.2           ISAKMP   Identity Protection (Main Mode)

    Frame 2234: 310 bytes on wire (2480 bits), 310 bytes captured (2480 bits)
        Arrival Time: Jul 16, 2012 15:01:55.378440000 Hora de verano romance
        Epoch Time: 1342443715.378440000 seconds
        [Time delta from previous captured frame: 0.000408000 seconds]
        [Time delta from previous displayed frame: 69.996897000 seconds]
        [Time since reference or first frame: 529.574627000 seconds]
        Frame Number: 2234
        Frame Length: 310 bytes (2480 bits)
        Capture Length: 310 bytes (2480 bits)
        [Frame is marked: False]
        [Frame is ignored: False]
        [Protocols in frame: eth:ip:udp:isakmp]
        [Coloring Rule Name: UDP]
        [Coloring Rule String: udp]
    Ethernet II, Src: Comtrend_c8:6c:31 (64:68:0c:c8:6c:31), Dst: Vmware_63:5f:f1 (00:0c:29:63:5f:f1)
        Destination: Vmware_63:5f:f1 (00:0c:29:63:5f:f1)
            Address: Vmware_63:5f:f1 (00:0c:29:63:5f:f1)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        Source: Comtrend_c8:6c:31 (64:68:0c:c8:6c:31)
            Address: Comtrend_c8:6c:31 (64:68:0c:c8:6c:31)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        Type: IP (0x0800)
    Internet Protocol, Src: 167.63.x.x (167.63.x.x), Dst: 192.168.1.2 (192.168.1.2)
        Version: 4
        Header length: 20 bytes
        Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
            0000 00.. = Differentiated Services Codepoint: Default (0x00)
            .... ..0. = ECN-Capable Transport (ECT): 0
            .... ...0 = ECN-CE: 0
        Total Length: 296
        Identification: 0x22df (8927)
        Flags: 0x00
            0... .... = Reserved bit: Not set
            .0.. .... = Don't fragment: Not set
            ..0. .... = More fragments: Not set
        Fragment offset: 0
        Time to live: 114
        Protocol: UDP (17)
        Header checksum: 0xa418 [correct]
            [Good: True]
            [Bad: False]
        Source: 167.63.x.x (167.63.x.x)
        Destination: 192.168.1.2 (192.168.1.2)
    User Datagram Protocol, Src Port: 1024 (1024), Dst Port: isakmp (500)
        Source port: 1024 (1024)
        Destination port: isakmp (500)
        Length: 276
        Checksum: 0x5bdc [validation disabled]
            [Good Checksum: False]
            [Bad Checksum: False]
    Internet Security Association and Key Management Protocol
        Initiator cookie: 8ff83d18af312f60
        Responder cookie: 0000000000000000
        Next payload: Security Association (1)
        Version: 1.0
        Exchange type: Identity Protection (Main Mode) (2)
        Flags: 0x00
            .... ...0 = Encryption: Not encrypted
            .... ..0. = Commit: No commit
            .... .0.. = Authentication: No authentication
        Message ID: 0x00000000
        Length: 268
        Type Payload: Security Association (1)
            Next payload: Vendor ID (13)
            Payload length: 96
            Domain of interpretation: IPSEC (1)
            Situation: 00000001
                .... .... .... .... .... .... .... ...1 = Identity Only: True
                .... .... .... .... .... .... .... ..0. = Secrecy: False
                .... .... .... .... .... .... .... .0.. = Integrity: False
            Type Payload: Proposal (2) # 1
                Next payload: NONE / No Next Payload  (0)
                Payload length: 84
                Proposal number: 1
                Protocol ID: ISAKMP (1)
                SPI Size: 0
                Proposal transforms: 2
                Type Payload: Transform (3) # 1
                    Next payload: Transform (3)
                    Payload length: 40
                    Transform number: 1
                    Transform ID: KEY_IKE (1)
                    Transform IKE Attribute Type (t=1,l=2) Encryption-Algorithm : AES-CBC
                        1... .... .... .... = Transform IKE Format: Type/Value (TV)
                        Transform IKE Attribute Type: Encryption-Algorithm (1)
                        Value: 0007
                        Encryption Algorithm: AES-CBC (7)
                    Transform IKE Attribute Type (t=14,l=2) Key-Length : 128
                        1... .... .... .... = Transform IKE Format: Type/Value (TV)
                        Transform IKE Attribute Type: Key-Length (14)
                        Value: 0080
                        Key Length: 128
                    Transform IKE Attribute Type (t=2,l=2) Hash-Algorithm : SHA
                        1... .... .... .... = Transform IKE Format: Type/Value (TV)
                        Transform IKE Attribute Type: Hash-Algorithm (2)
                        Value: 0002
                        HASH Algorithm: SHA (2)
                    Transform IKE Attribute Type (t=4,l=2) Group-Description : Alternate 1024-bit MODP group
                        1... .... .... .... = Transform IKE Format: Type/Value (TV)
                        Transform IKE Attribute Type: Group-Description (4)
                        Value: 0002
                        Group Description: Alternate 1024-bit MODP group (2)
                    Transform IKE Attribute Type (t=3,l=2) Authentication-Method : PSK
                        1... .... .... .... = Transform IKE Format: Type/Value (TV)
                        Transform IKE Attribute Type: Authentication-Method (3)
                        Value: 0001
                        Authentication Method: PSK (1)
                    Transform IKE Attribute Type (t=11,l=2) Life-Type : Seconds
                        1... .... .... .... = Transform IKE Format: Type/Value (TV)
                        Transform IKE Attribute Type: Life-Type (11)
                        Value: 0001
                        Life Type: Seconds (1)
                    Transform IKE Attribute Type (t=12,l=4) Life-Duration : 0
                        0... .... .... .... = Transform IKE Format: Type/Length/Value (TLV)
                        Transform IKE Attribute Type: Life-Duration (12)
                        Length: 4
                        Value: 00007080
                        Life Duration: 28800
                Type Payload: Transform (3) # 2
                    Next payload: NONE / No Next Payload  (0)
                    Payload length: 36
                    Transform number: 2
                    Transform ID: KEY_IKE (1)
                    Transform IKE Attribute Type (t=1,l=2) Encryption-Algorithm : 3DES-CBC
                        1... .... .... .... = Transform IKE Format: Type/Value (TV)
                        Transform IKE Attribute Type: Encryption-Algorithm (1)
                        Value: 0005
                        Encryption Algorithm: 3DES-CBC (5)
                    Transform IKE Attribute Type (t=2,l=2) Hash-Algorithm : SHA
                        1... .... .... .... = Transform IKE Format: Type/Value (TV)
                        Transform IKE Attribute Type: Hash-Algorithm (2)
                        Value: 0002
                        HASH Algorithm: SHA (2)
                    Transform IKE Attribute Type (t=4,l=2) Group-Description : Alternate 1024-bit MODP group
                        1... .... .... .... = Transform IKE Format: Type/Value (TV)
                        Transform IKE Attribute Type: Group-Description (4)
                        Value: 0002
                        Group Description: Alternate 1024-bit MODP group (2)
                    Transform IKE Attribute Type (t=3,l=2) Authentication-Method : PSK
                        1... .... .... .... = Transform IKE Format: Type/Value (TV)
                        Transform IKE Attribute Type: Authentication-Method (3)
                        Value: 0001
                        Authentication Method: PSK (1)
                    Transform IKE Attribute Type (t=11,l=2) Life-Type : Seconds
                        1... .... .... .... = Transform IKE Format: Type/Value (TV)
                        Transform IKE Attribute Type: Life-Type (11)
                        Value: 0001
                        Life Type: Seconds (1)
                    Transform IKE Attribute Type (t=12,l=4) Life-Duration : 0
                        0... .... .... .... = Transform IKE Format: Type/Length/Value (TLV)
                        Transform IKE Attribute Type: Life-Duration (12)
                        Length: 4
                        Value: 00007080
                        Life Duration: 28800
        Type Payload: Vendor ID (13) : MS NT5 ISAKMPOAKLEY
            Next payload: Vendor ID (13)
            Payload length: 24
            Vendor ID: 1e2b516905991c7d7c96fcbfb587e46100000008
            Vendor ID: MS NT5 ISAKMPOAKLEY
            MS NT5 ISAKMPOAKLEY: Unknown (8)
        Type Payload: Vendor ID (13) : RFC 3947 Negotiation of NAT-Traversal in the IKE
            Next payload: Vendor ID (13)
            Payload length: 20
            Vendor ID: 4a131c81070358455c5728f20e95452f
            Vendor ID: RFC 3947 Negotiation of NAT-Traversal in the IKE
        Type Payload: Vendor ID (13) : draft-ietf-ipsec-nat-t-ike-02\n
            Next payload: Vendor ID (13)
            Payload length: 20
            Vendor ID: 90cb80913ebb696e086381b5ec427b1f
            Vendor ID: draft-ietf-ipsec-nat-t-ike-02\n
        Type Payload: Vendor ID (13) : Microsoft L2TP/IPSec VPN Client
            Next payload: Vendor ID (13)
            Payload length: 20
            Vendor ID: 4048b7d56ebce88525e7de7f00d6c2d3
            Vendor ID: Microsoft L2TP/IPSec VPN Client
        Type Payload: Vendor ID (13) : Unknown Vendor ID
            Next payload: Vendor ID (13)
            Payload length: 20
            Vendor ID: fb1de3cdf341b7ea16b7e5be0855f120
            Vendor ID: Unknown Vendor ID
        Type Payload: Vendor ID (13) : Microsoft Vid-Initial-Contact
            Next payload: Vendor ID (13)
            Payload length: 20
            Vendor ID: 26244d38eddb61b3172a36e3d0cfb819
            Vendor ID: Microsoft Vid-Initial-Contact
        Type Payload: Vendor ID (13) : Unknown Vendor ID
            Next payload: NONE / No Next Payload  (0)
            Payload length: 20
            Vendor ID: e3a5966a76379fe707228231e5ce8652
            Vendor ID: Unknown Vendor ID

      Thanks

    Monday, July 16, 2012 1:16 PM
  • Thanks to all the contributors here. Based on your information I have created a blog summarising the TMG configuration for Azure Virtual Networks http://blog.kloud.com.au/2012/07/25/windows-azure-virtual-network-vpn-with-tmg-2010/

    Marc Terblanche

    Wednesday, July 25, 2012 5:45 AM
  • Hello Yuan,

    Am having issues with this and i cant figure out whats up? I followed instructions on https://www.windowsazure.com/en-us/manage/services/networking/cross-premises-connectivity/

    Then since we have TMG server i went on to configure as instructed at http://blog.kloud.com.au/2012/07/25/windows-azure-virtual-network-vpn-with-tmg-2010/

    After all that, the satus remains at "connecting"

    The firewall is behind a NAT and we have allowed all UDP ports for TMG to reach Azure but we dont get any logs, cant ping the azure gateway, simply no communication between the 2 networks. Would you possibly know whats under the hood? what are we missing?


    Friday, August 17, 2012 11:09 AM
  • @Kelly358,

    VPN DEVICE IP ADDRESS: Enter the public IP address of your VPN device. The device should not be behind a NAT. (http://www.windowsazure.com/en-us/manage/services/networking/cross-premises-connectivity/)

    HTH.

    Saturday, August 18, 2012 8:58 PM
  • I just wanted to say that this whole mess of having to support NAT-T is obnoxious and extremely frustrating.  Perhaps you guys are unaware of this, but your own (Microsoft's) recommendation is never to put IPSec behind NAT.  Why are you doing it?

    http://support.microsoft.com/kb/926179
    http://support.microsoft.com/kb/885348
    http://support.microsoft.com/kb/885407

    In fact, this one (http://support.microsoft.com/kb/818043) even states:
    "The only supported and recommended scenario is when the server is not located behind a NAT device."
    Friday, October 5, 2012 1:00 AM