Table of Contents

Description

This will NOT be a 5 min reading article.
It will require more time but it will cover all areas of interest :)
Most importantly, at the end, your Setup will WORK.

Kudos to Adam, my colleague, who first tested this in his lab.
It served as a basis for both me and the customer later on.

To start things off, a little while back someone asked me how he can have:
Incoming Traffic from Outside -> Azure Aviatrix Environment with FW Inspection -> Spoke with his Application
and also Preserve the source IP address when it hits the FW Rules.

Why this ?

He wanted to use the real source IP for logging and filtering purposes on Aviatrix FireNet attached FWs.
Pretty understandable and reasonable.

He read our article from here:
Spoke Ingress with Application Gateway
He saw the Diagram:

but noticed that the Azure Application Gateway does SNAT and as such his Firenet Firewalls are not seeing the original User IP of the request.

One could argue that the X-Forwarded-For header added by the Azure Application Gateway can be used to preserve the original IP…

Do you see a corner case here ?
I for one did not at the beginning. I always rush through things.

What if your Application is NOT a WebApp and as such there is NO HTTP Header where to add the X-Forwarded-For to?

Continue reading

Author's picture

Mihai Tanasescu

All Rounder and Jack of all trades (master of none? :) ).
Sailing the Cloud world with my fantastic team@Aviatrix, former Network, Systems Engineer (Cisco, Juniper, Linux, Openshift, Openstack).
A flavor of Security added to the mix (Offensive Security OSCE).
If there’s anything new and cool, then I like to learn about it. I’m also a fan of deep diving under the hood of a product to see what makes it tick as well as what breaks it.

Solutions Architect @ Aviatrix

Switzerland