Retrieving IP of request for HTTP triggered function

Question

Hi

I've got an HTTP triggered function for which I'm looking to limit access to a range of known IP addresses.

This has been working for a little while, but seemingly in recent weeks the behaviour has changed.

I've got this code.

private static string GetRequestingIp(HttpRequestMessage req)
{
    // With Azure functions, client IP can be found in the MS_HttpContext header.
    // Hat-tip: https://stackoverflow.com/a/37583005/489433
    const string MsHttpContextPropertyKey = "MS_HttpContext";
    if (!req.Properties.ContainsKey(MsHttpContextPropertyKey))
    {
        return "127.0.0.1";
    }

    return ((HttpContextBase)req.Properties[MsHttpContextPropertyKey]).Request.UserHostAddress;
}

As I say, pretty sure this has been working as expected for several months.

Recently though I've noticed the return value of this function isn't the IP of the caller, but something like 100.72.*.* which isn't a public IP, rather one used in private address space.

Could anyone shed any light on whether I have found a change in behaviour here, or if there's a more reliable way of getting the requesting caller's IP?

Thanks

Andy

Answer 1

> I'm looking to limit access to a range of known IP addresses.

You can add IP Restrictions to the Function itself.

Application Settings -> Networking -> Configure IP Restrictions (all the way to the right, in small print).

Answer 2

Thanks, never spotted that before!  Will switch to using that method.  

Answer 3

Go to the Function -> Select the Platform features tab -> Select Networking under Networking heading -> Click on Configure IP restrictions under IP Restrictions

Answer 4

Thanks for the replies both.  I've tried this method though and it seems not to be working for me.

Having confirmed my external IP:

I've firstly confirmed I can access my function over HTTP before I add any restrictions.

Then added one:

And now find I get a 403 forbidden response.

I've also tried with a sub-net mask of 255.255.255.255 though the portal indicates this is the default, but with the same result.

Clearing the IP restrictions means I can access the function over HTTP again.

Could I ask if anyone has had success with this or can see what I might be missing?

I wonder if the issue I've originally noted about the seeming behaviour change in recent days with regard to obtaining the client's IP in my custom code is related, and also breaking this platform feature?

Andy