RE: [fw-wiz] VPN concentrators

From: Schouten, Diederik (Diederik) (
Date: 08/27/02

From: "Schouten, Diederik (Diederik)" <>
To: "'Brian Ford'" <>,
Date: Tue Aug 27 13:16:02 2002

> >Client software would probably depend on Device as a number
> of beneficial
> >features can be used if you match the client to the device (personal
> >firewalls,
> >autmated upgrading of clients etc...)
> >users would be about 250 initially but up to 4000
> potentially in the future.
> So here is a problem. 250 users that use one client
> operating system means
> that you will need (to add?) a person to support (given some form of
> personal Firewall and some automated updating of client
> software), and
> monitor VPN clients usage full time. That's a nasty job if you add
> additional operating systems (there will always be one platform that
> doesn't get supported as well as others). That's multiple
> bodies as you
> grow to 4000 users.

But you would always have the same issue since they are remote users.

Unless you place a SOHO VPN gateway at their premises and remotely manage
Not a real problem, but a bigger investment.

I suppose remote connections would probably be established using "company
provided" laptops in most cases.

And you are already administering these.

In case of personal stations, there are many tools that could take care of
the remote install of virusscanners etc, fully automated.
As long as you control what comes through the tunnel I don't see how that
would cause a much higher workload compared to office users.

> >Not sure what you mean by access control? Do you mean to internal
> >resources? If
> >VPN traffic could be split inot different network pools then
> internal
> >NIDS, and
> >ACLs could manage this (along with obvious host/resource
> access controls)
> Would different VPN users belong to different groups and
> would different
> groups have more or less privileges or access to resources
> than others.

Would that really make a big difference?
The big issue here was what the general thought was about "VPN
Concentrators" compared to "Firewalls" and how the should be implemented.
We added the "VPN Gateway" later on...

Depending on hopw the groups are setup, what is the deciding factor, of
course you can give them different privileges, and that is the same for a

> >What are tehses mysterious "IPSEC issues" that we are all aware of ( or
> >perhaps not in my case) ??
> No mystery. NAT handling. Getting through client side
> Firewalls or filters.

These are indeed valid points... for deciding for which Concentrator/GAteway
to go.

But which VPN Client does not have NAT traversal options now?
And the ability to pass through filters/firewalls is not decided by your
Concentrator/Gateway, but by the filter/firewall that is in the tunnel's



Relevant Pages

  • RE: Remote connectivity problems
    ... do you mean you have added a remote client to SBS ... If you have hardware VPN tunnel setup using Linksys or others, ... In this scenario you have to configure the SBS Server computer to enable ...
  • RE: Connection times to devices behind VPN are extremely slow
    ... I understand that the remote VPN client ... You have to rerun the CEICW to make sure your SBS 2003 server have right ...
  • Re: TS vs VPN
    ... Using TS, w/o VPN ... The remote client connects to your local TS via Remote Desktop. ... "Foo" accesses the SQL server, which is nearby in a protected part of the network. ...
  • [NEWS] Cisco VPN 5000 Client Multiple Vulnerabilities
    ... Multiple vulnerabilities exist in the Cisco Virtual Private Network (VPN) ... 5000 Client software. ... These vulnerabilities are documented as Cisco bug ID ... CSCdx17109 - MAC OS VPN 5000 Client password vulnerability ...
  • Re: VPN clients unable to connect to other resources.
    ... gateway matches the IP of the remote client, and DNS and WINS point to the ... remote (although it takes close to a minute to connect, ... This is just regular Windows VPN, ... VPN server, remote routing and access running on the SBS 2003 server ...