IIS 10 and host headers?
Windows 2016 - IIS 10 I'm inexperienced with using host headers. Our developers have an app that logs the ip's making a request. They've explained that they're seeing the gateway address of the server, instead of the public address being logged. Is this the normal behavior when using host headers, or should the public address be logged? The xxx is indeed the servers gateway address, not a single public ip address is being logged. If the public ip address should be logged. What might I have mis-configured? The internal users of the site have their ip address being logged correctly. Thanks
C:\Program Files (x86)\Log Parser 2.2>logparser "select c-ip, count (c-ip) as requestcount from u_ex200206.log group by c-ip order by count(c-ip) desc"
c-ip requestcount
------------- ------------
xxx.xxx.xxx.xxx 584795
C:\Program Files (x86)\Log Parser 2.2>logparser "select c-ip, count (c-ip) as requestcount from u_ex200206.log group by c-ip order by count(c-ip) desc"
c-ip requestcount
------------- ------------
xxx.xxx.xxx.xxx 584795
It sounds like you have a load balancer, in which case the web server will see the load balacer's IP. The solution is to have the load balancer I set a http header containing the public IP of the actual client.
We have had the same issue.
We have had the same issue.
ASKER
No we don't have a load balancer in play. I forgot to mention that we do have a FW in play, we are using static NAT.
Thanks
Thanks
The firewall behaves as an intermediary if it is seen as the source.
Reverse proxy?
Scanning connections, IDP, IDS
Connection, SSL or plain http?
Reverse proxy?
Scanning connections, IDP, IDS
Connection, SSL or plain http?
ASKER
@arnold - no reverse proxy. At the moment were not scanning for IDS, I turned off the UTM features. Connection is using SSL.
Thanks
Thanks
Where does the SSL terminates? on the web server or on the firewall?
ASKER
@arnold - on the web server.
it is impossible for an inbound connection that terminates on the web server to appear as though it is originating from the firewall without the firewall performing source NAT modification. though seems peculiar as it will add overhead on the firewall to then translate the response back to the..
In short, inbound traffic, the Destination NAT is updated to point to the internal system for the packet. THe source should reflect the originating system's IP address.
In your case, besides the forwarding of the packet from the public IP to the internal one, the packet originating IP is also changed to reflect the Router/firewall as the sender.
double check the port forwarding configuration and see which options are enabled there.
In short, inbound traffic, the Destination NAT is updated to point to the internal system for the packet. THe source should reflect the originating system's IP address.
In your case, besides the forwarding of the packet from the public IP to the internal one, the packet originating IP is also changed to reflect the Router/firewall as the sender.
double check the port forwarding configuration and see which options are enabled there.
ASKER
@arnold - we're not doing srcnat. we're doing dstnat. The ip addy that's being recorded is not the address of the firewall, it's not the private address of the gateway assigned to the fw. It's picking up the ip address of the private gateway assigned to that particular subnet. To further aggravate me, I setup a site with an ip address and didn't use host headers for that site, the private ip of the subnet's gateway is still being recorded in the logs.
Thanks for the confirmation that the originating systems ip address is what should be recorded even if you are using host headers.
Thanks for the confirmation that the originating systems ip address is what should be recorded even if you are using host headers.
That is not possible by the information provide, something along big the path a path enters your network, dstnat changes the destination so it can hit the webserver, sonething alters the source ip, SNAT, to reflect the internal IP of your router/firewall.
While you might not think you set it up, the information presented negates your statement.
Somewhere you nat the inbound traffic. Do you have multiple paths to the internet? Are you using sd-wan?
Client ip <nat> router lan ip
Wan ip <=>. LAN side <=> web server
Based your info this is what happens to a packet,
Double check your port forwarding rule.
While you might not think you set it up, the information presented negates your statement.
Somewhere you nat the inbound traffic. Do you have multiple paths to the internet? Are you using sd-wan?
Client ip <nat> router lan ip
Wan ip <=>. LAN side <=> web server
Based your info this is what happens to a packet,
Double check your port forwarding rule.
ASKER
@arnold - i agree with you something does alter the src_ip to reflect the internal ip.
We are not using sd-wan. We don't have multiple paths to the internet.
I've got something on the fw misconfigured.
We are not using sd-wan. We don't have multiple paths to the internet.
I've got something on the fw misconfigured.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you Arnold, I did have NAT enabled on the policy, along with VIP's assigned to NAT the addresses. We don't have a load balancer in play.
And thanks to Zaheer and Kevin for your suggestions.
And thanks to Zaheer and Kevin for your suggestions.
Are you load balanced ?