Posts: 13
Joined: 9.Nov.2001
From: Philadelphia, PA
Status: offline
I am testing ISA Server 2004 on a Windows 2003 Server. I want to get the source IP address in my IIS serverĘs log. My IIS server has multiple web sites and I use different ports for each. I created a web publishing rule to redirect requests from the external NIC to the IIS Server and the port specified. For example a client requests www.mywebsite.com and that request is redirected to http://myservername:8090. I also had to create an access policy for port 8090 on the internal NIC to get this to work.
When I turn on "Requests appear to come from the Original Client" I can no longer get to the site but when I have it set to Requests appear to come from the Firewall" I can. Does anyone have any ideas to why this is?
Mark Moore
[ June 10, 2004, 11:44 PM: Message edited by: Mark Moore ]
Posts: 13
Joined: 9.Nov.2001
From: Philadelphia, PA
Status: offline
Update:
When I had "Requests appear to come from the Original Client" i couldnt get it to work because my web server was configured as a secureNat client to another proxy server....
So now it works and i am logging the original/Source IP addresses in my IIS Server logs.
You got it! You need to configure it to be a SecureNAT client if you want to retain the original host address because it uses the default gateway to reply to the Internet host.
This looks like the problem I'm having (can't connect to my web published www server when rule is set to use client IP address instead of ISA internal IP address).
With the setting "Requests appear to come from the ISA Server computer", the logic is...
The request comes into ISA and ISA sends it back to the internal web server. When ISA does this, it changes the "Source IP" address field in the IP Header to it's Internal adapter IP address. When the web server sees this request (we'll assume it's on the same logical segment as ISA), it sees the source IP is ISA. It checks it's routing table and says "Oh! This address is directly accessible to me. All I have to do is ARP for this IP and if I get a ARP response, I'll deliver it directly to that host." and the response is complete as far as the web server is concerned.
Now, with the setting "Requests appear to come from the original client", the logic is...
The request comes into ISA and ISA sends it back to the internal web server. When ISA does this, it leaves the "Source IP" address field in the IP Header alone - the external client's IP is maintained. When the web server sees this request (we'll assume it's on the same logical segment as ISA), it sees the source IP is someone on the internet. It checks it's routing table and says "Oh! This address isn't directly accessible to me. My routing table says that if I don't have a more specific route, my next hop is x.x.x.x, or my default gateway. Let me ARP for the gateway and if I get a response, I'll deliver it to that system". The request is now done as far as the web server is concerned.
With the setting for "Requests appear to come from original client" it is essential that the return path for responses from the web server honor the incoming path of the request (as far as your network is concerned - we won't get into the path that is used on the internet) - in other words, if the request came in from ISA and this setting is enabled, then the response has to go out through ISA as well.
This begs the question, why can't it go out some other device fo the response. 2 reasons - if that other device is capable of stateful inspection, it will not have any state for the response from the web server since the original packet came in through ISA. The second reason is that even if that device doesn't perform stateful inspection,, it most likley does NAT. As the response goes through that other device, the source IP will get changed to the NAT device's IP and by the time the original client gets the response, the source IP is not who the client sent it's request to and it will drop the response.
Essentially, if you have the option for "Request appears to come from original client" then the internal server must point to ISA for its default gateway.
Great explanation Clint! It cleared some confusions I had about these settings. I know you can use ARP to resolve IP-to-MAC, but I never would've imagined ISA uses it in this situation.
That's all that ARP is doing in this scenario as well. I probably gave too much information on the ARP process - it's not really relevant to the question.
What can I say, I was bored at work and got a little ahead of myself.
Following on from that I hope that either yourself or somebody can advise me.
I am in the process of building 3 ISA arrays, one of which requires the IP address to be passed through.
If I have an array comprising of 2 ISA servers with 4 NICs for front end, back end, intra array comms and external what IP address do I set the default gateway to on the Web Server?
On my original 2000 ISA server it was set to the ISAs front end address but I do not see how it can be configured for an array.
Posts: 11
Joined: 13.Jan.2004
From: PA
Status: offline
Hey all, sorry for resurrecting a dead thread, but I have this situation but I am running ISA 2000 so I don't have the "Requests appear to come from the Original Client" option. I read that it is a registry entry in ISA 2000. Does anyone know the registry settings?
With the setting "Requests appear to come from the ISA Server computer", the logic is...
The request comes into ISA and ISA sends it back to the internal web server. When ISA does this, it changes the "Source IP" address field in the IP Header to it's Internal adapter IP address. When the web server sees this request (we'll assume it's on the same logical segment as ISA), it sees the source IP is ISA. It checks it's routing table and says "Oh! This address is directly accessible to me. All I have to do is ARP for this IP and if I get a ARP response, I'll deliver it directly to that host." and the response is complete as far as the web server is concerned.
Now, with the setting "Requests appear to come from the original client", the logic is...
The request comes into ISA and ISA sends it back to the internal web server. When ISA does this, it leaves the "Source IP" address field in the IP Header alone - the external client's IP is maintained. When the web server sees this request (we'll assume it's on the same logical segment as ISA), it sees the source IP is someone on the internet. It checks it's routing table and says "Oh! This address isn't directly accessible to me. My routing table says that if I don't have a more specific route, my next hop is x.x.x.x, or my default gateway. Let me ARP for the gateway and if I get a response, I'll deliver it to that system". The request is now done as far as the web server is concerned.
With the setting for "Requests appear to come from original client" it is essential that the return path for responses from the web server honor the incoming path of the request (as far as your network is concerned - we won't get into the path that is used on the internet) - in other words, if the request came in from ISA and this setting is enabled, then the response has to go out through ISA as well.
This begs the question, why can't it go out some other device fo the response. 2 reasons - if that other device is capable of stateful inspection, it will not have any state for the response from the web server since the original packet came in through ISA. The second reason is that even if that device doesn't perform stateful inspection,, it most likley does NAT. As the response goes through that other device, the source IP will get changed to the NAT device's IP and by the time the original client gets the response, the source IP is not who the client sent it's request to and it will drop the response.
Essentially, if you have the option for "Request appears to come from original client" then the internal server must point to ISA for its default gateway.
ClintD: This is probably the best explanation I've ever read for this particular setting. One thing that I've noticed is that when you view the real-time logging tab the client and destination IP are the same regardless of which radio button is selected. The question I have is there any easy way to determine via the real-time logging feature why web publishing is broken by selecting the wrong radio button? When it's broken it just gives a cryptic error message.
The second part to my question is, if you are forced to select the first radio button (i.e. Requests appear to come from the Forefront TMG computer" due to the destination server having a default gateway that is not the TMG server, is there any way that you can retain the original client IP in the web logs?
Thanks.
< Message edited by THX -- 6.Aug.2010 11:20:32 PM >
Posts: 4663
Joined: 30.Jul.2002
From: United Kingdom
Status: offline
If your web server does not have a default gateway or routing configuration that returns the traffic back via the TMG publishing server, that option will not work.
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Printable Version
All Forums >> [ISA Server 2004 General ] >> Web Publishing >> Original IP address and Requests appear to come from the Original Client 
Original IP address and Requests appear to come from th... - !["[Confused]"](/image/smiles/confused.gif "\"\"")
RE: Original IP address and Requests appear to come fro... - ![[Razz]](/image/smiles/tongue.gif)
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread