Supply route to VPN clients

  • Thread starter Thread starter Massimo
  • Start date Start date
Massimo said:
"Of course, but then they're going to route any packet through the office
LAN, and this slows down any other Internet connection and generates a lot
of unnecessary traffic on the VPN, the office LAN and the main RRAS
server.

I think this is one of those situations where "it is the way it is". I
don't think the impact of the traffic is going to be as bad as you think.
Besides, when they no longer need resources on the system they are supposed
to disconnect, that's what "Remote Access VPN" is all about. They are only
supposed to connect to your system when they actually need something from
it. Your firewall, or whatever you use to control Internet access, can
typically be set to not allow the VPN client internet access via it. This
will stop any traffic that wasn't meant for your LAN,...if the connection is
being prvented from occuring then the traffic for such a connection never
happens. So if they want to run around on the Internet then they must break
the VPN connection first.
 
It looks like the Dial-in--> static routes button adds the static route to
the server when the user connects, and not to the VPN client computer.
Still, I have not tested this. Let me know how it works out.

Another Solution:
You could specify a static IP address in AD users and computer Dial-In tab,
and configure a persistent static route on the VPN client. This way the
route will remain even when the computer is reset.

Again, not an ideal solution but it should work.

What about a login script? Adds the route via login script when a user
creates a VPN connection?

Mike
 
I think this is one of those situations where "it is the way it is". I
don't think the impact of the traffic is going to be as bad as you think.
Besides, when they no longer need resources on the system they are
supposed to disconnect, that's what "Remote Access VPN" is all about.
They are only supposed to connect to your system when they actually need
something from it. Your firewall, or whatever you use to control
Internet access, can typically be set to not allow the VPN client
internet access via it. This will stop any traffic that wasn't meant for
your LAN,...if the connection is being prvented from occuring then the
traffic for such a connection never happens. So if they want to run
around on the Internet then they must break the VPN connection first.

I know this, but I think they could want to access the office LAN to work
with some documents, and in the meantime be able to use their PC as usual
(with web, e-mail and anything else); btw, this is the way I use my computer
when connected to the office LAN. This can be obtained by simply adding a
route to the client's routing table, so I don't see any reason not to want
it.
Anyway, I solved it (supplying the route from the DHCP server).

Massimo
 
Another Solution:
You could specify a static IP address in AD users and computer Dial-In
tab, and configure a persistent static route on the VPN client. This way
the route will remain even when the computer is reset.

Again, not an ideal solution but it should work.

What about a login script? Adds the route via login script when a user
creates a VPN connection?

Yes, I think both of them could work, but they are quite ugly (and difficult
to mantain for large number of remote users); besides, they would break the
advantages of using DHCP, by requiring to assign a static IP address to any
user... and this would also put a maximum limit on the number of users, even
if only some of them connect at the same time.
I think the DHCP solution is the best, here.

Massimo
 
Mike said:
What about a login script? Adds the route via login script when a user
creates a VPN connection?

VPN connections don't trigger login scripts because they aren't considered
"logins". The credentials only allow the connection to be created. To get a
true login requires the "checkbox" to be checked at the Ctrl-Alt-Del prompt
that says "Login using Dialup Connection" at the time the person logs into
thier machine, and the machine of course must be a domain member,...and I'm
still not sure if that will trigger the login script like it would on the
LAN or not.
 
Back
Top