What Does Application Gateway Mean?

An application gateway or application level gateway (ALG) is a firewall proxy which provides network security. It filters incoming node traffic to certain specifications which mean that only transmitted network application data is filtered. Such network applications include File Transfer Protocol (FTP), Telnet, Real Time Streaming Protocol (RTSP) and BitTorrent.

Application-level gateway  application layer gateway, application gateway, application proxy, or application-level proxy) is a security component that augments a firewall or NAT employed in a computer network.

Application gateways provide high-level secure network system communication. For example, when a client requests access to server resources such as files, Web pages and databases, the client first connects with the proxy server, which then establishes a connection with the main server.

The application gateway resides on the client and server firewall. The proxy server hides Internet Protocol (IP) addresses and other secure information on the client’s behalf. A computer’s internal system may communicate with an external computer using firewall protection. The application gateway and external computer function without client information or knowledge of the proxy server IP address.

Application Gateway background

With an Application Gateway in place, you have complete protection to safeguard your network system. What is the real purpose and why do you really need one? For starters, customers make requests for resources from databases where they need to connect to the server. This entails the customer to go even one step further to get to the main server. The Application Gateway inhabits the server’s firewall. By keeping their IP addresses and other sensitive information secure, this protects the client’s data for safekeeping.

The Application Gateway and exterior computer function without a client’s information or knowledge of the IP address. The reality is that you have two types of connections going on at the same time: one exists between the customer and the server. And the second exists between the server and the final endpoint.

How it works

Application gateways examine incoming packets at the application level and use proxies to create secure sessions with remote users. For example, when an external user with a Web browser tries to access the company’s internal web server, the application gateway runs a proxy application that simulates the internal webserver.
https://21071ec6fb177f3ae559710fc6fb7a20.safeframe.googlesyndication.com/safeframe/1-0-38/html/container.html

A session is established between the remote user and the proxy application, while a separate, independent session is established between the proxy application and the internal web server. The remote user makes a request to the proxy, the proxy acts as a go-between and obtains the information from the internal web server, and then the proxy returns the result to the remote user.

The advantage of using application gateways over packet-filtering routers is that in packet filtering, a direct network connection still exists between the remote user and the internal network resource, while an application gateway prevents the remote user from directly accessing the internal network resource.

This layer of additional security comes at some cost, namely that application gateways are generally slower and require a separate proxy application for each internal network service you want to make available through the firewall.

APPLICATION GATEWAY FEATURES

Secure Sockets Layer (SSL/TLS) termination

Application gateway supports SSL/TLS termination at the gateway, after which traffic typically flows unencrypted to the backend servers. This feature allows web servers to be unburdened from costly encryption and decryption overhead. But sometimes unencrypted communication to the servers isn’t an acceptable option. This can be because of security requirements, compliance requirements, or the application may only accept a secure connection. For these applications, application gateway supports end to end SSL/TLS encryption.

Autoscaling

Application Gateway Standard_v2 supports autoscaling and can scale up or down based on changing traffic load patterns. Autoscaling also removes the requirement to choose a deployment size or instance count during provisioning.

Zone redundancy

A Standard_v2 Application Gateway can span multiple Availability Zones, offering better fault resiliency and removing the need to provision separate Application Gateways in each zone.

Static VIP

The application gateway Standard_v2 SKU supports static VIP type exclusively. This ensures that the VIP associated with application gateway doesn’t change even over the lifetime of the Application Gateway.

Web Application Firewall

Web Application Firewall (WAF) is a service that provides centralized protection of your web applications from common exploits and vulnerabilities. WAF is based on rules from the OWASP (Open Web Application Security Project) core rule sets 3.1 (WAF_v2 only), 3.0, and 2.2.9.

Web applications are increasingly targets of malicious attacks that exploit common known vulnerabilities. Common among these exploits are SQL injection attacks, cross site scripting attacks to name a few. Preventing such attacks in application code can be challenging and may require rigorous maintenance, patching and monitoring at many layers of the application topology. A centralized web application firewall helps make security management much simpler and gives better assurance to application administrators against threats or intrusions. A WAF solution can also react to a security threat faster by patching a known vulnerability at a central location versus securing each of individual web applications. Existing application gateways can be converted to a Web Application Firewall enabled application gateway easily.

Ingress Controller for AKS

The ingress controller runs as a pod within the AKS cluster and consumes Kubernetes Ingress Resources and converts them to an Application Gateway configuration, which allows the gateway to load-balance traffic to the Kubernetes pods. The ingress controller only supports Application Gateway Standard_v2 and WAF_v2 SKUs.

URL-based routing

URL Path Based Routing allows you to route traffic to back-end server pools based on URL Paths of the request. One of the scenarios is to route requests for different content types to different pool.

For example, requests for http://contoso.com/video/* are routed to VideoServerPool, and http://contoso.com/images/* are routed to ImageServerPool. DefaultServerPool is selected if none of the path patterns match.

Multiple-site hosting

With Application Gateway, you can configure routing based on host name or domain name for more than one web application on the same application gateway. It allows you to configure a more efficient topology for your deployments by adding up to 100+ websites to one application gateway. Each website can be directed to its own backend pool. For example, three domains, contoso.com, fabrikam.com, and adatum.com, point to the IP address of the application gateway. You’d create three multi-site listeners and configure each listener for the respective port and protocol setting.

Requests for http://contoso.com are routed to ContosoServerPool, http://fabrikam.com are routed to FabrikamServerPool, and so on.

Similarly, two subdomains of the same parent domain can be hosted on the same application gateway deployment. Examples of using subdomains could include http://blog.contoso.com and http://app.contoso.com hosted on a single application gateway deployment.

You can also define wildcard host names in a multi-site listener and up to 5 host names per listener.

Redirection

A common scenario for many web applications is to support automatic HTTP to HTTPS redirection to ensure all communication between an application and its users occurs over an encrypted path.

In the past, you may have used techniques such as dedicated pool creation whose sole purpose is to redirect requests it receives on HTTP to HTTPS. Application gateway supports the ability to redirect traffic on the Application Gateway. This simplifies application configuration, optimizes the resource usage, and supports new redirection scenarios, including global and path-based redirection. Application Gateway redirection support isn’t limited to HTTP to HTTPS redirection alone. This is a generic redirection mechanism, so you can redirect from and to any port you define using rules. It also supports redirection to an external site as well.

Application Gateway redirection support offers the following capabilities:

• Global redirection from one port to another port on the Gateway. This enables HTTP to HTTPS redirection on a site.
• Path-based redirection. This type of redirection enables HTTP to HTTPS redirection only on a specific site area, for example a shopping cart area denoted by /cart/*.
• Redirect to an external site.

Session affinity

The cookie-based session affinity feature is useful when you want to keep a user session on the same server. By using gateway-managed cookies, the Application Gateway can direct subsequent traffic from a user session to the same server for processing. This is important in cases where session state is saved locally on the server for a user session.

Websocket and HTTP/2 traffic

Application Gateway provides native support for the WebSocket and HTTP/2 protocols. There’s no user-configurable setting to selectively enable or disable WebSocket support.

The WebSocket and HTTP/2 protocols enable full duplex communication between a server and a client over a long running TCP connection. This allows for a more interactive communication between the web server and the client, which can be bidirectional without the need for polling as required in HTTP-based implementations. These protocols have low overhead, unlike HTTP, and can reuse the same TCP connection for multiple request/responses resulting in a more efficient resource utilization. These protocols are designed to work over traditional HTTP ports of 80 and 443.

Connection draining

Connection draining helps you achieve graceful removal of backend pool members during planned service updates. This setting is enabled via the backend http setting and can be applied to all members of a backend pool during rule creation. Once enabled, Application Gateway ensures all deregistering instances of a backend pool don’t receive any new request while allowing existing requests to complete within a configured time limit. This applies to both backend instances that are explicitly removed from the backend pool by a user configuration change, and backend instances that are reported as unhealthy as determined by the health probes. The only exception to this are requests bound for deregistering instances, which have been deregistered explicitly, because of gateway-managed session affinity and continues to be proxied to the deregistering instances.

Custom error pages

Application Gateway allows you to create custom error pages instead of displaying default error pages. You can use your own branding and layout using a custom error page.

Rewrite HTTP headers and URL

HTTP headers allow the client and server to pass additional information with the request or the response. Rewriting these HTTP headers helps you accomplish several important scenarios, such as:

• Adding security-related header fields like HSTS/ X-XSS-Protection.
• Removing response header fields that can reveal sensitive information.
• Stripping port information from X-Forwarded-For headers.

Application Gateway and WAF v2 SKU supports the capability to add, remove, or update HTTP request and response headers, while the request and response packets move between the client and back-end pools. You can also rewrite URLs, query string parameters and host name. With URL rewrite and URL path-based routing, you can choose to either route requests to one of the backend pools based on the original path or the rewritten path, using the re-evaluate path map option.

It also provides you with the capability to add conditions to ensure the specified headers or URL are rewritten only when certain conditions are met. These conditions are based on the request and response information.

APPLICATION GATEWAY IMPORTANCE

Benefits

Benefits are abundant. Thanks to their filtering capabilities, you have the same outcome as a firewall. Additionally, it helps to keep information hidden from the network, and the authentication feature is supported to the full extent of protection necessary.

The Application Gateway gives the user a thorough itinerary of log-in traffic that details what goes in and out of the network. When you break down this ability, you now have a complete record that can show any nefarious attempts at hacking into the network. Without this beneficial feature, it’s complicated to decipher how or when someone made a break-in attempt without the Application Gateway in place.

Shortcomings

With pluses come minuses. An Application Gateway can have a slower effect than a packet filter. Also, going one step further, not every available connection can support this type of technology leading to a less effective outcome. At the end of the day, having an Application Gateway far outweighs not having one for your enterprise.

Configuring an Azure Application Gateway

1. Create a new Application Gateway
   1. It needs to have access to your HDP Nodes on ports 8080, 11280 and 40501 via the internal private IP
   2. Basics
      1. Name: HDPGateway
   3. Settings
      1. Put into a Virtual Network or Create one
      2. Public IP
      3. Choose Public IP or create existing one
      4. Set Idle Timeout to 5 min
      5. Listener – HTTP on Port 80
      6. Leave rest of settings as default
   4. Wait until Gateway is fully created before continuing.

BACK TO TOP 

Configuring the Application Gateway Frontend Listener

1. Create Listener (Basic)
   1. Name: HTTPS
   2. Frontend IP Config: appGatewayFrontendIP
   3. Frontend port:
      1. Name: HTTPS
      2. Port: 443
   4. Protocol: HTTPS
   5. Certificate:
      1. Load in PFX Cert
      2. Name: <domain name>
      3. Password: <password used when PFX was created>
   6. Wait until listener is fully created before proceeding

BACK TO TOP 

Configuring the Backend Pools and Health Probe

1. Create Backend Pools
   1. Name: HDPServerPool
      1. Add all HDP Nodes to this pool
   2. Name: HDPNode1
      1. Add 1^st HDP node to this pool
   3. Name: HDPNode2
      1. Add 2^nd HDP node to this pool
   4. Add additional nodes for each HDP instance 
   
2. Configure Health Probe
   1. Name: HDPHealthProbe
   2. Protocol: HTTP
   3. Select “Pick host name from backend settings”
   4. Path: /api/healthcheck
   5. Interval: 30
   6. Timeout: 30
   7. Unhealthy: 3 
   
3. Configure HTTP Settings
   1. Edit existing “appGatewayBackendHttpSettings”
      1. Port: 8080
      2. Protocol: HTTP
      3. Cookie based affinity: Enabled
      4. Connection draining: Disabled
      5. Request timeout: 30
   2.  Add “OPA”
      1. Port 40501
      2. Protocol: HTTP
      3. Cookie based affinity: Disabled
      4. Connection draining: Disabled
      5. Request timeout: 20
   3. Add “Notification”
      1. Port 11280
      2. Protocol: HTTP
      3. Cookie based affinity: Disabled
      4. Connection draining: Disabled
      5. Request timeout: 20

BACK TO TOP 

Configuring Routing Rules

1. Configure Rules
   1. Create Path-Based Rule
   2. Name: HDPRules
   3. Listener: HTTPS
   4. Default backend pool: HDPServerPool
   5. Default HTTP Settings: appGatewayBackendHttpSettings
   6. Add Configuration:
      1. HDPNode1 (Create one of these rules for EVERY node)
         1. Name: HDPNode1
         2. Path: /connect/opa_<hostname provided during HDP install>_40501
            1. BE SURE TO REPLACE dots with underscores in hostname
         3. Backend pool: HDPNode1
         4. HTTP Settings: OPA_Node1
      2. Notification
         1. Name: Notification
         2. Path: /connect/X_DataDirect_Notification_Server
         3. HTTP Settings: Notification_Pool
   
2. Delete default listener
   1. appGatewayHttpListener on port 80 can be removed.
3. Delete default backend pool
   1. appGatewayBackendPool
4. Add the front-end IP address of the Application Gateway to DNS as an A-Record. This will vary depending on where your DNS records are managed.

We hope this tutorial assisted in creating a cloud-based solution to OData enable both your on-premises and cloud data sources using Progress Hybrid Data Pipeline and Azure’s Application Gateway. Now you can have security, scalability and reliability all together in a single data access solution which lets you bring sources such as Oracle, Postgres, MySQL, DB2 and SQL Server out from behind the firewall. If you have any question, please feel free to contact us.

Drop your comment