<p>I have a web application that should behave differently for internal users than external ones. The web application is available over the Internet, and therefore obviously to the internal users as well.</p>

<p>All the users are anonymous, not authenticated, but the page should render differently for internal users than external. What I'm doing in my code is use <code>Request.UserHostName</code> and then <code>Dns.GetHostEntry</code>. The result is then compared to a setting in my <code>web.config</code> (that holds something like <code>*.mydomain.local</code>) . If the comparison gives a positive result then I render the HTML that the internal user should see otherwise I render the HTML the external user should see.</p>

<p>However, my problem is that I don't always get the expected value from <code>Request.UserHostName</code>. on the development site I get the <code>IP-number</code> (?) of the machine running the browser but on the customer site I don't get the <code>IP-number</code> of the user machine, I get some other <code>IP-number</code>. The browsers don't have any proxies set or anything like that.</p>

<p>Should I be using something else than <code>Request.UserHostName</code>?</p>

[{'answer_id': 45559, 'author': 'Espo', 'author_id': 2257, 'author_profile': 'https://Stackoverflow.com/users/2257', 'pm_score': 0, 'selected': False, 'text': '<p>There might be a firewall that is doing some sort of NAT, to enable inside clients to use the external dns-name to reach the server.</p>\n\n<p>Is the IP-number you get on customer site the same at the external customer-server ip? In that case you can hard code for that one IP-address. All internal computers behind that firewall will appear to have to same ip-address and you can classify them as "internal".</p>\n'}, {'answer_id': 45561, 'author': 'seanyboy', 'author_id': 1726, 'author_profile': 'https://Stackoverflow.com/users/1726', 'pm_score': 0, 'selected': False, 'text': '<p>It looks like you\'re being returned a public facing IP Address. Get the user to go to <a href="http://www.myipaddress.com" rel="nofollow noreferrer">http://www.myipaddress.com</a> . If this is the same as the IP Address returned to your software, then this is definitely the case. </p>\n\n<p>The only solution I can see to get around this is to either get them to connect to the machine holding the asp.net application via a VPN, or to use some other kind of authentication. The latter is probably the best option. </p>\n'}, {'answer_id': 45570, 'author': 'frizz', 'author_id': 1003, 'author_profile': 'https://Stackoverflow.com/users/1003', 'pm_score': 2, 'selected': False, 'text': "<p>Try Request.UserHostAddress, which returns the client's IP address. Assuming your internal network uses IP addresses reserved for LANs, it should be relatively simple to check if an IP is internal or external.</p>\n"}, {'answer_id': 45591, 'author': 'Robin Minto', 'author_id': 1456, 'author_profile': 'https://Stackoverflow.com/users/1456', 'pm_score': 0, 'selected': False, 'text': "<p>It does sound like there is a proxy between users and the server on the customer site (it doesn't need to be configured in the browser). It may be an internal or external proxy depending on your network configuration.</p>\n\n<p>I would avoid using the UserHostName for what is effectively authentication as it is presented by the browser duing the request and would be easy to spoof. IP address would be much more effective as it's difficult to spoof an IP address in a TCP/IP connection (and maintain a connection). It's still weak authentication but may be sufficient in this scenario.</p>\n\n<p>Even if you are using IP address, if there's a NAT proxy between client and server, you may have to accept that anything coming through that proxy is trusted (I'm assuming that external/untrusted clients don't come through that proxy).</p>\n\n<p>If that isn't acceptable, you're back to other methods of authentication. Rather than requiring a logon or VPN connection, you might consider a permanent cookie or client certificates and only give those to internal clients but you would need some way of delivering those to the client. You could certainly deliver a permanent cookie based on a one-time logon. Cookies can be spoofed in a similar way in that the UserHostName can be however you've got a better opportunity to create a cookie value that is less guessable than a domain name.</p>\n"}, {'answer_id': 45641, 'author': 'dagorym', 'author_id': 171, 'author_profile': 'https://Stackoverflow.com/users/171', 'pm_score': 3, 'selected': True, 'text': "<p>I recommend using IP addresses as well.  I'm dealing with this exact same situation setting up an authentication system right now as well and the conditions described by Epso and Robin M are exactly what is happening.  External users coming to the site give me their actual IP address while all internal users provide the IP of the gateway machine(router) on to the private subnet the webservers sit on.</p>\n\n<p>To deal with it I just check for that one IP.  If I get the IP of the gateway, I provide the internal access.  If I get anything else they get the external one which requires additional authentication in my case.  In yours, it would just mean a different interface.</p>\n"}]
['https://Stackoverflow.com/questions/45553', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/3379/']