Azure Application Gateway x-forwarded-for remove port information
x-forwarded-for header set by Azure Application Gateway now will have random port information along with client ip. It makes no sense. Please help to remove that.
Anonymous
shared this idea
The port information can now be removed by rewriting the X-Forwarded-For header using the Header Rewrite capability (https://azure.microsoft.com/en-us/blog/rewrite-http-headers-with-azure-application-gateway) available with Application Gateway’s V2 SKU. Please see details here:
https://docs.microsoft.com/en-us/azure/application-gateway/rewrite-http-headers#remove-port-information-from-the-x-forwarded-for-header.
Thanks,
Abhave
9 comments
-
MikeN
commented
Are there any plans to address this for the V1 SKU? Many organizations have a security requirement that all traffic must flow through a virtual network security appliance. Since the V2 SKU doesn't support user defined routes to force traffic through a network security appliance it's not an option to use it.
-
Rick Tham
commented
Just wanted to follow-up that we addressed this issue with a URL Rewrite rule within the application.
-
Rick Tham
commented
I just want to follow-up on this as the original post has been over a year old. Any feedback from the Azure Networking Team on if this can only be IP versus IP:Port?
This is a show stopper for us to be able to use the Azure Application Gateway.
-
Peter Speden
commented
If the Application Gateway forwards it with the port, it is breaking some of my Rewrite rules in IIS which are not expecting a port (I am using rewritemaps for the IP addresses - so wildcards are not allowed).
Hoping this gets a quick turnaround or at the very least a configuration option.
-
Anonymous
commented
I totally agree.
If you need IP:PORT, use x-forwarded-port. -
Anders Johan Holmefjord
commented
Yes, like user 3rd Sept said, make this configurable. We are migrating to Azure, but the port causes problems for us.
Azure Networking Team, do you have a response? -
Anonymous
commented
There are products out in the market that checks for user session based on the client IP as well and if the port is present, then it is treated as a new session request since the port number keeps on changing. This leads to user session issues.
Instead of removing port numbers. you can keep it configurable. That way anyone who wants with port number can have with port number and those who do not want with port number can select that option as well.
This way everyone's requirements will be met as well. -
Anonymous
commented
we agree
-
Anonymous
commented
It makes sense because multiple connections may come from the same IP address and the corresponding IP:PORT combination is how one can identify those separate connections.