Application Gateway Merge.

Jessie 85 Reputation points
2023-09-11T02:13:00.0333333+00:00

We have a Hub and Spoke network architecture.

Application gateway-1 and DNS for Application A has been deployed in the Hub network.

Traffic flow for Application A:

Internet > Firewall > Application Gateway-1

*application gateway will be placed in front of firewall around October.

i.e Internet > AppGW-1 > Firewall.

Application B is now in the pipeline.

I have created Application Gateway-2 for Application B.

Traffic flow for Application B;

Internet > Application Gateway-2 > Firewall (End-to-end TLS encryption)

*The Plan is to have both Applications share the same AppGW and delete Application Gateway-1.

Question:

  1. Will I run into problems if traffic flow for both Application gateways is set to

Internet > AppGW > Firewall?

  1. What effects will sharing the same Application Gateway have?
  2. Any advice on how to achieve merging the application gateways without problems.
Azure DNS
Azure DNS
An Azure service that enables hosting Domain Name System (DNS) domains in Azure.
627 questions
Azure Virtual Network
Azure Virtual Network
An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.
2,264 questions
Azure Application Gateway
Azure Application Gateway
An Azure service that provides a platform-managed, scalable, and highly available application delivery controller as a service.
1,001 questions
Azure Load Balancer
Azure Load Balancer
An Azure service that delivers high availability and network performance to applications.
420 questions
Accepted answer
  1. Salah 241 Reputation points
    2023-09-21T06:05:40+00:00

    Hi @Jessie

    I am summarizing my comments as well and i highly appreciate if you could Accept the answer

    A hub and spoke design deploys shared network components in the hub virtual network and application-specific components in the spokes. In most systems, Azure Firewall Premium is a shared resource. But Web Application Firewall can be a shared network device or an application-specific component. it's usually best to treat Application Gateway as an application component and deploy it in a spoke virtual network:

    • It can be difficult to troubleshoot Web Application Firewall alerts. You generally need in-depth knowledge of the application to decide whether the messages that trigger those alarms are legitimate.
    • If you treat Application Gateway as a shared resource, you might exceed Azure Application Gateway limits.
    • You might face role-based access control problems if you deploy Application Gateway in the hub. This situation can come up when teams manage different applications but use the same instance of Application Gateway. Each team then has access to the entire Application Gateway configuration.

    Reference: https://video2.skills-academy.com/en-us/azure/architecture/example-scenario/gateway/application-gateway-before-azure-firewall

    application-gateway-before-azure-hub-spoke-external

    regarding your queries

    1. it is limited to only one certificate per HTTP listener, however you can generate SAN certificate and have a single certificate for multiple domains.

    https://video2.skills-academy.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#application-gateway-limits

    Single Listener:

    • If the inbound traffic to all your applications can be handled with the same WAF rules and SSL termination requirements.
    • Only one place you need to go to make changes, reducing the administrative overhead.

    Multiple Listeners:

    • If you have different domains with unique SSL certificates, you will need separate listeners.
    • If different applications or services have varying WAF rules or routing requirements.
    • If you want to isolate the impact of changes or incidents to one of your services, using multiple listeners can be beneficial.

    With per-site WAF policies, you will be able to protect multiple sites with differing security needs behind a single WAF. For example, if there are five sites behind your WAF, you can have five separate WAF policies (one for each listener) to customize the exclusions, custom rules, managed rule sets, and all other WAF settings for each site.

    1. End-to-end TLS with the v2 SKU

    Authentication Certificates have been deprecated and replaced by Trusted Root Certificates in the Application Gateway v2 SKU.

    • Certificates signed by well known CA authorities whose CN matches the host name in the HTTP backend settings don't require any additional step for end to end TLS to work.
    1 person found this answer helpful.
    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. KapilAnanth-MSFT 39,446 Reputation points Microsoft Employee
    2023-09-18T13:10:34.1666667+00:00

    @Jessie

    Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

    I shall summarize the comments from myself and Salah to post a complete answer.

    A hub and spoke design deploys shared network components in the hub virtual network and application-specific components in the spokes. In most systems, Azure Firewall Premium is a shared resource. But Web Application Firewall can be a shared network device or an application-specific component. it's usually best to treat Application Gateway as an application component and deploy it in a spoke virtual network:

    • It can be difficult to troubleshoot Web Application Firewall alerts. You generally need in-depth knowledge of the application to decide whether the messages that trigger those alarms are legitimate.
    • If you treat Application Gateway as a shared resource, you might exceed Azure Application Gateway limits.
    • You might face role-based access control problems if you deploy Application Gateway in the hub. This situation can come up when teams manage different applications but use the same instance of Application Gateway. Each team then has access to the entire Application Gateway configuration.

    Reference: https://video2.skills-academy.com/en-us/azure/architecture/example-scenario/gateway/application-gateway-before-azure-firewall

    application-gateway-before-azure-hub-spoke-external

    To provide more context,

    • Host Multiple sites : https://video2.skills-academy.com/en-us/azure/application-gateway/create-multiple-sites-portal
    • You must consider scenarios for end-to-end, where the Azure Firewall applies TLS inspection to do IDPS on the encrypted traffic between the Application Gateway and the web backend, with Azure Firewall Premium.
    • The Application Gateway encrypts traffic following zero-trust principles (End-to-End TLS encryption), and the Azure Firewall will receive encrypted traffic. Still, Azure Firewall Standard will be able to apply inspection rules, such as layer 3 & layer 4 filtering in network rules, or FQDN filtering in application rules using the TLS Server Name Indication (SNI) header. Azure Firewall Premium provides deeper visibility with IDPS, such as URL-based filtering.
    • If the Application Gateway is sending unencrypted traffic to the application servers, the Azure Firewall will see inbound traffic in clear text. TLS inspection isn't needed in the Azure Firewall.
    • In the above case, you must make sure that the certificate you provide for TLS inspection must support both the sites (by using a wildcard one)

    Now, to address your queries,

    1.What effects will sharing the same Application Gateway have?

    2.Any advice on how to achieve merging the application gateways without problem:

    • I would suggest to have a lower test environment and do the lab scenarios.
    • Once this is verified, you can move to making the changes in Production environment.

    Thanks,

    Kapil

    Please Accept an answer if correct.

    Original posters help the community find answers faster by identifying the correct answer.

    1 person found this answer helpful.