Corporate Network - Forcing a RAS client to only access a Terminal Server

[Jeff]

Hi All,

I have a requirement as follows:

* Corporate Network
* RAS is on Windows 2003 Server
* RAS clients can only access a Terminal Server

The Terminal Server will provide access to a mainframe through a 3270
session. The server has been locked down per Microsoft's whitepaper,
'Locking Down Windows Server 2003 Terminal Server Sessions'.

What we _do not_ want is using Corporate as an ISP - that is,
establishing a RAS connection, and then cruising the internet from the
laptop. Currently users are doing this and running up tremendous phone
bills.

Incidently, the RAS Server and Terminal Server are the same machine.

We prefer a solution which employs Group Policy. I've grepped various
newsgroups, but I keep drawing a blank on this situation.

Thanks in Advance,
Jeff

 

[Bill Grant]

I doubt that you will be able to use group policy for this. Remote
clients are not like LAN clients. They are controlled by remote access
policies, not AD group policies. The other thing you could look at would be
CMAK (Connection Manager Admin Kit). This allows you to control the RAS
configuration of your remote clients from the server end.

 

[Jeff]

Hi Bill,

Thanks for the response. I took a quick look at CMAK. It does not
appear to fit our needs (IMHO).

What do you think of the feasibility of the following:

* Assign an IP in a known range. For example, 10.20.1.xxx
* Filter at the RAS server based on IP - drop anything other than
traffic to the Terminal Server when the IP is in the above range.

Thanks Again,
Jeff

 

[Jeff]

Hi Bill,

Digging a little further (with much better luck!), it appears that it
is the case that it cannot be done through GPO. A DHCP range provided
to dial up users which is filetered on Outbound Connections based upon
the IP address appears to be the solution.

However, I don't agree with the SBS 2003 solution provided below (I
don't want ISA server, Proxy server, etc involved - it seems to be too
complex).

http://groups.google.com/group/micr...internet+access&rnum=2&hl=en#ef18e1285c5cd8de

Jeff

 

[Bill Grant]

I would go futher than using a DHCP range. I would put the remotes in
their own IP subnet (using a static address pool on the RRAS server). They
will them only have access to the RRAS/TS server if you don't enable IP
routing on that server.

 

[Bill Grant]

On reading that back it sounds a bit convoluted. If you put the remote
machines in their own subnet, they will only have access to the RRAS server.
Access to the rest of the network would require enabling IP routing on the
RRAS server and also modifying the routing on the LAN to route traffic for
the remotes to RRAS server. If you don't do that, the clients are restricted
to the server alone.

 

[Jeff]

Hi Bill,

Thanks again for the feedback.

in their own IP subnet (using a static address pool on the RRAS server).

I agree - RAS gets a static pool and the DHCP server gets an excluded
range.

will then only have access to the RRAS/TS server if you don't
enable IP routing on that server.

This is what is frustrating! They do at this point.

What is really killing me at this point is I'm tweaking a new box, but
I do not have a field laptop or test dial in lines. I have to run
between the cracks and switch over the phone lines when they are least
likely to be used.

 

[Bill Grant]

If you just use a static pool in the same IP subnet, the clients will be
able to see the LAN without routing being enabled on the server. The server
acts as a proxy for the remotes and does proxy ARP on the LAN for them. You
need to put them in their own IP subnet to stop this happening.

 

[Jeff]

Thank you very much.