none
Can't create Application Gateway RRS feed

  • Question

  • Hi,

    I currently have a vnet in the West-Europe region.

    I want to add an Application gateway to it, but this doesn't seem to work.

    1) Via portal

    I go to the Appplication Gateway blade and click Add.

    In step 1. Basic I fill in a name, select the WAF tier, Medium SKU Size, 2 instances, and select the same subscription, resource group and region as the vnet is in.
    Next, I click "Ok" and move on to step 2. Settings.
    First setting: "Choose a virtual network". I click it and it tells me "No virtual networks found in the selected subscription and location 'West Europe'." So I can't continue. I have double, triple and quadruple checked that my vnet is indeed also in the West Europe region.

    2) via powershell

    I tried creating via powershell:
    New-AzureApplicationGateway --> ok
    Set-AzureApplicationGatewayConfig --> ok
    Start-AzureApplicationGateway --> Gives an error: 

    Start-AzureApplicationGateway : InternalError : An internal error has occurred.
    At line:1 char:1
    + Start-AzureApplicationGateway <redacted>
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : CloseError: (:) [Start-AzureApplicationGateway], CloudException
        + FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceManagement.Network.ApplicationGateway.StartApplic
       ationGatewayCommand

    I would have expected the gateway that I just created via New-AzureApplicationGateway to appear in the portal as well, but it doesn't. There's no trace of it whatsoever.

    Please help

    Regards,
    Lorenzo Dieryckx

    Tuesday, December 13, 2016 3:38 PM

All replies

  • I notice that you are using the ASM (classic) cmdlets to create the Application Gateway.

    Is your VNet ASM (classic) or ARM based?


    Michael

    www.deployazure.com

    Tuesday, December 13, 2016 10:06 PM
  • Hi,

    As Michael said, there are two modules in Azure, ASM and ARM, if the VNet create in ASM module, we create the application gateway in Azure portal, we will not find the VNet. According to your script, your VNet is in ASM module, so you can’t use new portal can’t find the VNet in the application gateway.

    There are some preparations should consider:

    1.If you have an existing virtual network, either select an existing empty subnet or create a new subnet in your existing virtual network solely for use by the application gateway. You cannot deploy the application gateway to a different virtual network than the resources you intend to deploy behind the application gateway unless vnet peering is used.

    2. Verify that you have a working virtual network with a valid subnet. Make sure that no virtual machines or cloud deployments are using the subnet. The application gateway must be by itself in a virtual network subnet.

    3. The servers that you configure to use the application gateway must exist or have their endpoints created either in the virtual network or with a public IP/VIP assigned.

    Besides, the virtual network and public IP address must be in the same location as your gateway.

     More information about application gateway, please refer to the link below:

    https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-create-gateway

    If you still have questions, welcome to post back here. Thanks.

    Best Regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, December 14, 2016 5:57 AM
  • Thank you Michael and Jason for your replies.

    My vnet is indeed in ASM, so that explains why it can't be found when I try to create the application gateway from the portal. (It would be nice if this was stated explicitly in the documentation though, I didn't see this anywhere)

    I'll try again with your suggestions Jason.
    But just for the sake of completeness:
    1. and 2. the docs say "it is important to know that the virtual network needs an empty subnet or a subnet of only application gateway resources to be used" so I tried to add it to the same subnet as the existing vnet gateway is in now. Maybe that's the problem. I'll retry with an empty subnet.

    3. This wasn't the case either. I'll create deployments for those services first. Any chance that the cmdlet could return a more specific error message so that people don't need to go on these forums for issues this simple? :-)

    As an additional question: The back-end pool is defined via IP addresses, but if the vm's in my cloud service get an OS update, their IP address often changes. Are there any guidelines on how to avoid the need for a gateway reconfiguration in this case?

    Thanks again!

    Regards,
    Lorenzo Dieryckx

    Wednesday, December 14, 2016 10:19 AM
  • Hi Lorenzo,

    “but if the vm's in my cloud service get an OS update, their IP address often changes. Are there any guidelines on how to avoid the need for a gateway reconfiguration in this case?”

    We need a reserved IP address (classic) to stay the IP with our cloud service even across stopped or deallocated state (VMs). We can use PowerShell to associate a reserved IP, more information about reserved IP address, please refer to the Link below:

    https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-reserved-public-ip

    “Any chance that the cmdlet could return a more specific error message

    According to your description, maybe we can try to add -Debug to the cmdlet.

    If you still have questions, welcome to post back here.

    Best Regards,

    Jason Ye


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, December 15, 2016 5:28 AM
  • Hi Jason,

    Your reply concerning the reserved IP doesn't really make any sense to me. 

    The way I understand it, a reserved IP is 1) public and 2) assigned to a cloud service, so since a cloud service usually has multiple instances (vms) running inside it, I'm going to assume that the reserved IP is actually assigned to a loadbalancer that lives in front of all the instances in the cloud service.

    From what I understand about application gateway:
    1) it also provides load balancing
    2) it is meant to serve as a public endpoint to one (or multiple) cloud services (or vms) in a private virtual network
    So in that case, what's the use of the application gateway then? if my cloud service is also publicly reachable and already load balanced? This way I miss out on the WAF, ssl offloading, url based routing, health monitoring, and all the other goodies that application gateway provides.

    Clearly I'm either not getting something or misunderstanding some things (or worse: both ;-))
    Could you please elaborate a bit more? What I really want is that the application gateway is the only publicly exposed service of my vnet, and that my cloud service (and all it's vms) are only accessible through the gateway AND that I don't have to reconfigure the gateway every time my vm's are being reimaged (and change ip address)

    Thanks again!
    Regards,
    Lorenzo 

    Thursday, December 15, 2016 9:38 AM
  • Hi Lorenzo,

    Application Gateway works at the application layer (Layer 7 in the OSI network reference stack). It acts as a reverse-proxy service, terminating the client connection and forwarding requests to back-end endpoints.

    The following table helps understanding the difference between the two load balancers:

    More information about the Application gateway, please refer to the link.

    About the internal IP address, we can add a static internal IP to an existing VM, more information please refer to the link below:

    https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-reserved-private-ip

    If you still have questions, welcome to post back here. Thanks.

    Best Regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, December 15, 2016 10:49 AM
  • Thanks again for your answer Jason,

    I did get the difference between the azure load balancer and the application gateway. I just wanted to demonstrate the uselessness if the cloud service is public because of the reserved IP.

    Anyway, the static internal ip would be a great solution, but it looks like it's only supported for vm's? Is there something similar for cloud services?

    Thursday, December 15, 2016 11:52 AM
  • Hi Lorenzo,

    “Is there something similar for cloud services?”

    To prevent IP addresses from changing, you can reserve an IP address. Reserved IPs can be used only as a VIP, ensuring that the IP address for the cloud service will be the same even as resources are shutdown or deallocated. Furthermore, you can convert existing dynamic IPs used as a VIP to a reserved IP address.

    To reserve the IP address of an existing cloud service, we can use this PowerShell command:

    New-AzureReservedIP –ReservedIPName MyReservedIP –Location "Central US" -ServiceName TestService

    More information about reserved IP, please refer to the link below:

    https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-reserved-public-ip

    If you still have questions, welcome to post back here.

    Best Regards,

    Jason


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, December 16, 2016 1:02 AM
  • Dear Jason,

    We're running around in circles. You gave me this same reply yesterday.
    Reserved IP doesn't look like a good option for me since that makes my cloud service publicly available, while I want it only available through the application gateway

    Regards,
    Lorenzo

    Friday, December 16, 2016 9:05 AM
  • Remember that in ASM Virtual Machines are deployed into a Cloud Service. The Application Gateway can be public or internal facing and can expose Private Internal IP addresses without the need for there to be an external endpoint on the Cloud Service of your VMs itself.

    So even though the Cloud Service for your VMs has a public IP (dynamic or reserved) there is no access exposed via this if no endpoint is created.

    You just need to create a front end IP configuration for the Application Gateweay (Public or Internal facing), then define your back end IP addresses of the IPs in your VNet, and define the private IPs of your resources as reserved.

    Check this documentation. https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-create-gateway


    Michael

    www.deployazure.com




    Sunday, December 18, 2016 12:50 PM
  • Hi Lorenzo,

    “while I want it only available through the application gateway

    Maybe we should choose ARM module, because in ASM, every cloud service has a public IP, this is by design. In ARM module, we can deploy the VM without public IP.

    If you still have questions, welcome to post back here.

    Best Regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, December 19, 2016 10:00 AM