Application Gateway Merge.

Question

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?

2. What effects will sharing the same Application Gateway have?
3. Any advice on how to achieve merging the application gateways without problems.

Answer 1

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://learn.microsoft.com/en-us/azure/architecture/example-scenario/gateway/application-gateway-before-azure-firewall

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://learn.microsoft.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.

Answer 2

@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://learn.microsoft.com/en-us/azure/architecture/example-scenario/gateway/application-gateway-before-azure-firewall

To provide more context,

• Host Multiple sites : https://learn.microsoft.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?

• The two factors I can think of is bandwidth and wildcard listeners for TLS
• You can meet bandwidth requirements by leveraging App gateway auto scaling
• And in case of multi site hosting, make sure
• you meet the conditions for wildcard or multiple host names in a listener
• and consider Request Routing rules evaluation order

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.