ISA 2004, Internal Servers and Subnets
What..........your "Internal" RDP connections are not working?
Uhh-Oooh, everyone knows that if ISA's in the network and somethings not working correctly the problem has to be with ISA 2004....right? Not necessarily...
Heres the problem. The CX has users at a remote site using the 192.168.20.x subnet. The users on the 192.168.20.x subnet need to access a Terminal Server on the 192.168.15.x subnet. ISA 2004 is running on the SBS server in the 192.168.15.x subnet. When the users from the 192.168.20.x subnet attempt to RDP into the Terminal Server. The connection starts to connect, then fails with the error "The Terminal Server is unavailable". All users are configured for SecureNat. DHCP for the 192.168.20.x subnet is being handed out by the local router on that subnet.
While Troubleshooting we find.....
The clients and server in the 192.168.15.x subnet can connect to the Terminal Server without issues.
When viewing the ISA 2004 Logging console without client filtering enabled, you can see the clients from the 192.168.20.x subnet requesting a connection, then the connection is closed. There are no denies or anything leading you to believe that there is an issue with the connection. The connection appears to complete.
If you filter logging on the Terminal Servers IP, you then see the request from the 20.x client, but then a denied is being returned from the ISA/SBS server. What...The ISA server...why is it involved? Afterall this is "internal" traffic! So why am I receiving the denies? Is it an ISA rule? Do the users have the correct permissions? Why do I only see the denies when I filter on the Terminal Servers IP? Is there something wrong with the "networks" that are configured in ISA. Do I need a special rule to do this?
While your thinking about this, here's the topology again: May need to draw it out.... :)
There are 2 subnets; the 192.168.15.x and 192.168.20.6.
- The 192.168.15.x are all using a 24 bit mask.
- The Terminal Server, ISA/SBS Server along with the clients are connected into a common switch.
- The common switch connects directly into the local router.
- The 192.168.15.x Router interface IP is 192.168.15.5
- The 2 sites are connected through site to site VPN connection.
The 192.168.20.x network:
- All servers and clients are using a 24 bit mask
- All clients are connected into a common switch which connects directly into a local router
- The router interface for this subnet is 192.168.20.5.
- All 20.x clients are receiving DHCP from their local router.
Internet Connectivity
- All users connect to the internet through the ISA/SBS server.
ISA 2004:
- Both subnets are configured for "internal" networks.
- There are no custom rules set to apply to these requests.
So whats the problem?
When a client from the 192.168.20.x subnet attempts a connection to the TS server <15.x>, the request is routed through the router directly to the TS Server, this step is fine. It is on the return where the issue comes into play. Since the request is originating from a different subnet, how would the TS Server route the request back to the client? First step would be to query its own routing table. If the needed routing information was not there, where would it go next.... it's Default Gateway. In this case what would be the TS Servers Default Gateway? The ISA/SBS server. ISA does not have the ability to route an internal request from one "internal" subnet to a second "internal" subnet. So the the return routing would fail.
So whats the fix?
You have to route the "20.x" return request back to the internal "15.x" router before it reaches the ISA/SBS server, afterall thats where it needs to go anyway... right? So how would I do that? The easiest way is to add a route to the server in questions routing table. This way if the TS server needed to query its routing table it would find an entry pertaining to this particular subnet <20.x>. It would then know to push the return request back to the internal router instead of trying to route it back through the default Gateway/ISA server.
So what would the entry look like?
Route Add 192.168.20.0 MASK 255.255.255.0 192.168.15.5 -p
So After I add the route, how does this work again? In a nutshell....
- Request for the TS Server <15.x> is made by a client on the <20.x> subnet
- Connection from the client is received and authorized by the TS Server.
- TS Server queries it's routing table for entries pertaining to the 20.x subnet for return routing.
- Finds an entry stating "20.x" IP's with a 24 bit mask are to be routed back through the internal router <192.168.15.5> - Not the Default Gateway <ISA Server>.
There are numerous other ways that this network could be reconfigured to do the same thing. I will leave that to your descretion.
So was the issue with ISA 2004 or was it with the routing configuration of the network??
FYI - this configuration did work with ISA 2000...........
>edwalt
Comments
Anonymous
January 01, 2003
Nothing new to add to this thoughtful post on ISA 2004, Internal Servers and Subnets. Definitely a worthwhile...Anonymous
January 01, 2003
This was already addressed in http://support.microsoft.com/kb/888042. this KB is ~3 years old.Anonymous
May 29, 2006
Great article :-)
This describes exactly our situation, with only one difference: we have 2 remote sites, so 3 subnets. Otherwise SBS server and TS Server in one subnet. On the remote site there are clients who need to connect to the TS and there are other remote clients (Mac clients) who need direct acces to Exchange (for email) on the SBS.
You wrote:
"There are numerous other ways that this network could be reconfigured to do the same thing. I will leave that to your descretion."
I hope someone can direct me in the right direction for the "numerous other ways", because I'm now in the middle of someone who knows a lot about Cisco routers and VPN and someone who knows a lot about SBS, but the problem is the combination of those two....Anonymous
April 10, 2007
I haven't gotten much done these days. So it goes. What can I say? I've just been letting everything pass me by. Basically not much going on lately, but it's not important. I've basically been doing nothing worth mentioning.Anonymous
May 04, 2007
Thanks for the good information. Maybe I can use it one of these days when I run into a problem like this. Lord only knows that if there is something that can go wrong with a server, it will probably happen to me. Thanks.Anonymous
February 29, 2008
G6Qplx r u crazzy? I told u! I can't read!Anonymous
March 01, 2008
SeGb1X r u crazzy? I told u! I can't read!Anonymous
March 06, 2008
oRcH4H r u crazzy? I told u! I can't read, man!Anonymous
March 06, 2008
FuUKlv r u crazzy? I told u! I can't read!Anonymous
March 07, 2008
JNSxWC r u crazzy? I told u! I can't read!Anonymous
March 07, 2008
fWKvPw r u crazzy? I told u! I can't read!Anonymous
March 07, 2008
tshut4 r u crazzy? I told u! I can't read!Anonymous
March 08, 2008
jb3MQi r u crazzy? I told u! I can't read!Anonymous
March 08, 2008
tG1gaa r u crazzy? I told u! I can't read!Anonymous
March 08, 2008
gdyXgD r u crazzy? I told u! I can't read!Anonymous
June 21, 2008
Thank you so much for this article, I had the exact same problem. Resolved by adding the route on the terminal server.