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.
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…
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.
- All users connect to the internet through the ISA/SBS server.
- 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………..