In article <OZGSPqdEGHA.2912@tk2msftngp13.phx.gbl>,
w2k@onthemove.freeuk.com says...
> A good topic for discussion!
>
> We used to use VPN (before we implemented Terminal Server) and now we don't.
> Instead we open a (non-standard) port on the firewall and use
> port-forwarding to point incoming traffic from specific, permitted client
> computers and users (both must be correctly identified) to port 3389 on the
> TS.
>
> The reason that we ended up dropping VPN was that we had no control over the
> remote computers. When they become compromised and VPN to the network then
> we had endless problems with the compromised machines being part of the LAN.

If you didn't have control then you didn't have your firewall setup
properly.

We use VPN to the Firewall Appliance, not the server, and then a
firewall rule that permits ONLY 3389 to the Terminal Server or 3389 to
their work computer, nothing else.

This means that users with compromised machines don't expose their home
computers to any more than your solution, BUT they have a double
authentication method, first the firewall, then the RD connection to the
server/workstation and neither have the same user/password.

I would never expose RD/TS directly to the Internet.

--

spam999free@rrohio.com
remove 999 in order to email me

A good topic for discussion!

We used to use VPN (before we implemented Terminal Server) and now we don't.
Instead we open a (non-standard) port on the firewall and use
port-forwarding to point incoming traffic from specific, permitted client
computers and users (both must be correctly identified) to port 3389 on the
TS.

The reason that we ended up dropping VPN was that we had no control over the
remote computers. When they become compromised and VPN to the network then
we had endless problems with the compromised machines being part of the LAN.

So far, since we switched to using native RDP/port-forwarding and no VPN we
have had no problems. It's also much, much easier for the end user to
manage for themselves! This approach has also enabled us to add an extra
layer of redundancy in that we now have two separate internet connections
from different providers and the client can access the TS via either
connection.

Regards,
Simon.

"Leythos" <void@nowhere.lan> wrote in message
news:KpGqf.219923$tD4.24549@tornado.ohiordc.rr.com ...
> In article <MPG.1e14a78519389f3098999f@msnews.microsoft.com>,
> kiln@brick-like.com says...
>> Hi thanks for taking the time to write all of that, it's very
>> educational.
>
> That's what we're here for - I've learned a lot in my 20+ years on
> Usenet, always like to give back when I can.
>
>> So your point is that TS is special in that it's a newer technology, and
>> thus has less or no mindshare with firewall vendors etc. If exposed to
>> the public via the internet, your take is that VPN and IP address level
>> auth is the only way to operate with confidence. Is that a fair summary?
>
> Sort of - my position is that TS should never, new or not, be exposed
> where there are proven means to access the server without exposing the
> TS services.
>
> Sort of like the old HTTP/RPC email access for Outlook that was used for
> years until a worm trashed that method - then all the ASP's that were
> providing Exchange over HTTP were screwed as they scrambled to implement
> VPN solutions (and then later HTTPS methods).
>
> There is just no valid reason to expose the TS service.
>
>> "Are you using this box as a cheap Application Server and hosting apps
>> for customers?"
>>
>> Yes, it's more of a potential, there is no such box at this time, just
>> exploring. If you have a suggestion re the sensible route for a newbie
>> like me to look into, I'd like to hear about it. (I do have one ts app
>> exposed via firewall/vpn endpoint, but I'm only the app provider, not
>> very involved in the network part of that)
>
> What you need to do is make Security a clear part of your business plan,
> so that you account for it's needs and methods, before you build a
> business and then have to re-do things because of problems you didn't
> expect - hence, why we don't expose TS outside of the LAN.
>
> --
>
> spam999free@rrohio.com
> remove 999 in order to email me

In article <OZGSPqdEGHA.2912@tk2msftngp13.phx.gbl>,
w2k@onthemove.freeuk.com says...
> A good topic for discussion!
>
> We used to use VPN (before we implemented Terminal Server) and now we don't.
> Instead we open a (non-standard) port on the firewall and use
> port-forwarding to point incoming traffic from specific, permitted client
> computers and users (both must be correctly identified) to port 3389 on the
> TS.
>
> The reason that we ended up dropping VPN was that we had no control over the
> remote computers. When they become compromised and VPN to the network then
> we had endless problems with the compromised machines being part of the LAN.

If you didn't have control then you didn't have your firewall setup
properly.

We use VPN to the Firewall Appliance, not the server, and then a
firewall rule that permits ONLY 3389 to the Terminal Server or 3389 to
their work computer, nothing else.

This means that users with compromised machines don't expose their home
computers to any more than your solution, BUT they have a double
authentication method, first the firewall, then the RD connection to the
server/workstation and neither have the same user/password.

I would never expose RD/TS directly to the Internet.

--

spam999free@rrohio.com
remove 999 in order to email me