Home / server / Questions / 416250
Accepted
mark
Asked: 2012-08-11 03:17:51 +0800 CST

Windows: remote network routes as normal user (with privileged script/executable?)?

  • 772

System: Windows XP SP3 Professional, part of an Active Directory

We have an obligation to work with a VPN network client (CheckPoint) on selected workstations where selected users own a certificate/password for this VPN Client. They can run and connect to the VPN as a normal user without any elevated privileges.

Problem: we have a clash of networks here. Our company uses two networks in 10.x.z.y and the remote company through which the VPN is handled does too.

Their routes are very very liberal, e.g. 10.8.0.0/255.248.0.0 which also masks our internal 10.15.x.z network.

The company providing the VPN won't or can't change the routes create by their client. So I try to remove the routes in such a way that at least connection to our internal network still works.

But I can't even remove the routes as the normal, unprivileged user. I really don't know how to solve this.

The only idea I have right now: have some software which the user can run after he connects to the VPN which modifies the routing table so internal network routes are not going to the remote VPN network. Obviously this software would need elevated rights. I don't even know how I can make it possible that a non-privileged domain user can run only a certain software/script elevated on this PC. Or if it's even a good idea ...

thanks for any hints

networking

2 Answers

  1. What I would probably do is make the VPN tunnel from some physical endpoint (a firewall in the DMZ).

    I would then set my default gateway to route traffic in a much more specific way, e.g.: 10.8.0.0/24, via the IP of the VPN endpoint.

    This would then get around routes being added to users machines.

    • 0
  2. Best Answer

    I only see four workarounds, but no clear answer:

    1. Most obvious and most unlikely to be used: Change the IP range on your internal network.
    2. Use a second host via a terminal server (not on 10.x) for normal network tasks.
    3. Use a second host via a VM (possibly run the VPN client inside the VM)
    4. Use a second host via extra hardware. Easiest but requires more hardware.

    Option 4 is the easiest workaround to set up. It might be worth it if you have to get things working right away with absolutely no time to spare. I also think it is the least elegant solution and the extra hardware costs money, power and desktop space.

    Option 3 is nice if you can get the VPN to run inside the VM.

    Option 2: If you already have a terminal server and people do not use specific local software on their desktops then this might be easy. That assume quite a lot though.

    Option 1. If you ever set up a new network then you might try normal (public) IPs (and no NAT) or the 172.16/12 range. For some reason people rarely seem to use that. Worth mentioning it for future networks and it would work. But the work required to change an existing network it a tad much.

    • 0