VPN client and Azure FrontDoor

Jani Honko 1

Our web app is installed as an Azure App Service and it's accessible through Azure FrontDoor Standard. This works fine.

The issue comes when using VPN client (in Windows 10) to access the web app through Azure FrontDoor. With VPN client but without Azure FrontDoor, the web app sees the company's network IP address as expected, BUT with Azure FrontDoor, the web app sees the calling client's IP address. So the company's network IP address is lost somewhere. It seems that the issue is in Azure FrontDoor.

With VPN client, without Azure FrontDoor:

X-Forwarded-For=<company's network IP address> // This is OK

With VPN client, with Azure FrontDoor:

X-Forwarded-For=<client's IP address>,<unknown IP address> // This is not OK

So, is it possible to pass through the IP address provided by the VPN client so that the web app can see it? There should not be any difference using VPN client with or without Azure FrontDoor.

GitaraniSharma-MSFT 47,696 Reputation points Microsoft Employee

2022-11-07T06:07:59.137+00:00

Hello @Jani Honko ,

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

I understand that you would like to know if it is possible to pass through the VPN Client IP address to the webapp when accessing it through Azure Front Door via VPN and not the client IP.

I will discuss this scenario with the Azure Front Door Product Group team and get back to you with an update soon.

Regards,
Gita
Jani Honko 1 Reputation point

2022-11-07T06:36:57.773+00:00

Thanks Gita and yes, I want to get the following request path working, so that the web app sees the VPN Gateway IP address 2.2.2.2.

Client (IP = 1.1.1.1) -> VPN Gateway (IP = 2.2.2.2) -> Azure FrontDoor -> Azure App Service (web app)

Without Azure FrontDoor the aforementioned request path works as expected and the web app gets the following request headers:

CLIENT-IP=2.2.2.2:<port>
X-Forwarded-For=2.2.2.2:<port>

For me, it seems that Azure FrontDoor doesn't respect the X-Forwarded-For header and thus the VPN Gateway IP address is lost.

I appreciate your help as we currently have no way forward with this one and it prevents us moving Azure FrontDoor to production.

Regards, Jani
GitaraniSharma-MSFT 47,696 Reputation points Microsoft Employee

2022-11-07T11:24:49.273+00:00
Hello @Jani Honko ,

To investigate this issue further, could you please share the below details:

Are you using Azure VPN or any other VPN?

Could you please confirm how you are checking the x-forwarded-for address when using Azure Front Door with VPN?

Did you check Azure Front Door Access logs to validate that the VPN is sending the correct x-forwarded-for address to the Azure Front Door?
Refer : https://learn.microsoft.com/en-us/azure/frontdoor/standard-premium/how-to-logs#access-log

Also, where have you restricted the VPN client IP? Is it on the Azure Front Door WAF or Web App?

Regards,
Gita
Jani Honko 1 Reputation point

2022-11-07T12:20:47.243+00:00
1) Other VPN.

2) The web app has a dedicated page that lists request details including X-Forwarded-* headers, and I can access that page using either Azure FrontDoor url or Azure App Service url (direct url). There I can see the difference whether using Azure FrontDoor or not.

3) I have checked the access logs. As per documentation, X-Forwarded-* headers are not logged at all. Am I right?

Although I can see the following headers:

originIp_s which is the VPN remote network IP address (one of those, but not the VPN gateway IP address which I'm looking for)

clientIp_s which the client IP address

socketIp_s which the client IP address

Do you have any tips which specific data I should look at?

And as mentioned before, using VPN and direct url to Azure App Service, I can see the correct X-Forwarded-* headers on the dedicated page in the web app. I think this confirms that VPN is sending the headers properly.

4) IP is restricted on the web app side, which is the reason why I need the VPN Gateway IP address there.

Feel free to ask if you need more information.

Regards, Jani
GitaraniSharma-MSFT 47,696 Reputation points Microsoft Employee

2022-11-07T13:11:56.783+00:00

Hello @Jani Honko ,

You need to check the ClientIP in the Azure Front Door Access logs.
As described in this doc,
ClientIp - is the IP address of the client that made the original request. If there was an X-Forwarded-For header in the request, then the Client IP is picked from the same.

So, if the VPN client sends the X-Forwarded-For header in the request, then the Client IP from the Access logs should contain the IP sent by the VPN client. This will confirm what IP the VPN client is sending to the Azure Front Door.

Another suggestion from my end would be to configure an IP restriction rule with a WAF for Azure Front Door. An IP address–based access control rule is a custom WAF rule that lets you control access to your web applications. There are two type of match variables in IP address match, RemoteAddr and SocketAddr. RemoteAddr is the original client IP that is usually sent via X-Forwarded-For request header.
Refer : https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction

So, configure a WAF policy and add a custom rule as below:
Custom rule name : Rulename
Status : Enabled
Rule type : Match
Priority : 100
Match type : IP address
Match variable : RemoteAddr
Operation : Does not contain
IP address or range : Your VPN client range
Then : Deny traffic

Then associate this WAF policy to your Azure Front Door frontend host and test the traffic again.

Regards,
Gita
Jani Honko 1 Reputation point

2022-11-07T14:02:03.383+00:00

There's no ClientIP, just clientIP_s and clientIp_s, but I think clientIp_s is the same as the ClientIP you mentioned.

clientIp_s is the client IP i.e. my laptop IP, not the VPN gateway IP.

Unfortunately we can't use WAF IP restrictions because of the business requirements (e.g. only few endpoints are IP protected while others are not). Thus we need to find a way to pass the VPN gateway IP address to the web app.

Regards, Jani
GitaraniSharma-MSFT 47,696 Reputation points Microsoft Employee

2022-11-07T14:19:57.833+00:00

Hello @Jani Honko ,

Could you please let me know what is the SocketIp address logged in the Azure Front Door access logs?

Regards,
Gita
Jani Honko 1 Reputation point

2022-11-08T11:07:30.387+00:00

It's the same as the ClientIp address.

I also tested to create a WAF rule to block VPN gateway IP address (using both RemoteAddress and SocketAddress), but it didn't blocked anything. Probably because it sees only my laptop IP address.

Is there any way to see the raw data of incoming requests on Azure FrontDoor (at least headers)?

Regards, Jani
GitaraniSharma-MSFT 47,696 Reputation points Microsoft Employee

2022-11-10T14:54:25.53+00:00
Hello @Jani Honko ,

Thank you for the update.

You have to create a WAF policy custom rule to allow only the VPN gateway IP address and NOT block it.

If you use WAF, and the traffic has the XFF header, then IP restriction with RemoteAddr match will work for you.
The rule should be as below:

Custom rule name : Rulename

Status : Enabled

Rule type : Match

Priority : 100

Match type : IP address

Match variable : RemoteAddr

Operation : Does not contain

IP address or range : Your VPN client range

Then : Deny traffic

The above rule implies that if the IP address doesn't contain the VPN client IP/range, then the traffic will be denied. If it does contain your VPN client IP/range, then it will be allowed. Could you please make sure that you have configured the rule as described above?

Could you also confirm if you do not want to use WAF at all and just want the traffic to go to web app directly via AFD?

I will check regarding this and get back - "Is there any way to see the raw data of incoming requests on Azure FrontDoor (at least headers)?"

Regards,
Gita
Jani Honko 1 Reputation point

2022-11-11T12:52:35.497+00:00

I created a new WAF rule using the details you provided, and set our VPN gateway IP address to "IP address or range" field. As a result, all connections are blocked no matter if I'm using VPN or not. So, obviously AFD or WAF doesn't see the VPN gateway IP address.

I don't want to use WAF for IP blacklisting/whitelisting, but for other purposes. I just wanted to verify whether WAF can see the VPN gateway IP address or not. In real scenario, I want the traffic to go to web app via AFD/WAF and all IP blacklisting/whitelisting is done on the web app side.

So, to recap my original issue:

"I want to use Azure App Service (web app) via non-Azure VPN ja AFD/WAF. Web app itself does IP blacklisting/whitelisting. The issue is that the web app cannot see the VPN gateway IP address. Without AFD/WAF the web app can see the VPN gateway IP address. And the whole point of the VPN is to route traffic via some other network so that the target system sees the VPN gateway IP address."

I'm so confused with this and have no more ideas to way forward.

If raw data of incoming AFD requests are visible somewhere, it might help us to verify the headers sent by the VPN to AFD. Otherwise AFD is a kind of black box for us.

Have a nice weekend and lets get back to this next week.

Regards, Jani
GitaraniSharma-MSFT 47,696 Reputation points Microsoft Employee

2022-11-11T17:52:05.973+00:00

Hello @Jani Honko ,

Thank you for the update.

I've reached out to the Azure Front Door & Azure WAF Product Group team to discuss your issue and will update you on this as soon as I get a response.

In the meantime, could you also try to edit the WAF rule and make the Match variable : SocketAddr and try again?

There is no way to see the raw data of incoming requests on Azure FrontDoor (at least headers) via logs. The only available option is to use Fiddler when accessing the URL and filter the data to find the XFF header in that trace.

Also, if you could send us an email as advised in the private message, we can discuss this issue further in detail.

Regards,
Gita
Jani Honko 1 Reputation point

2022-11-14T13:05:20.933+00:00

Changed the WAF rule to use SocketAddr and the result is the same as with RemoteAddr (i.e. all connections blocked).

Regards, Jani
GitaraniSharma-MSFT 47,696 Reputation points Microsoft Employee

2022-12-06T12:42:23.167+00:00

Hello @Jani Honko ,

I'm adding the summary of our offline discussion and the root cause of this issue that you were able to find out, as this can be beneficial to other community members.

Regards,
Gita

1 answer

GitaraniSharma-MSFT 47,696 Reputation points Microsoft Employee

2022-12-06T12:43:34.513+00:00

Hello @Jani Honko ,

I understand that you wanted to know if it is possible to pass through the VPN Client IP address to the webapp when accessing it through Azure Front Door via VPN and not the client IP.

We discussed this issue in detail and collected various logs and traces but were unable to find anything concrete from the logs, so we decided to open a support request, however, you did some deeper investigations on your side and found that your VPN is configured to use split tunneling which means that not all traffic goes though it.
And because Azure Front Door IP address was not on your VPN’s remote network list, traffic to Azure Front Door was not routed through the VPN. Hence, you were seeing your local IP address and not the VPN gateway IP address when accessing the webapp through Azure Front Door via VPN.

You can allow the Azure Front Door's IP address on VPN’s remote network list to make it work.

The AzureFrontDoor.Backend service tag provides a list of the IP addresses that Front Door uses to connect to your origins.
You can download the Azure IP Ranges and Service Tags data set, which is updated regularly with the latest IP addresses for Azure Front Door and use them for whitelisting the traffic.

Kindly let us know if the above helps or you need further assistance on this issue.

----------------------------------------------------------------------------------------------------------------

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment