InIT4theMoney
IS-IT--Management
Our network consists of a SBS 2000 server in our (single location) office and 4 PCs running Win2k Pro and Win XP Pro. The Server is connected to the internet via an ADSL router (non-NAT) connected to a second network adapter. The installation is mostly standard SBS-2000. All the PCs and the server have all the latest Service Packs installed
One of our employees now works from home and needs access to the network. He has a Win2k Pro PC (again with all the latest service packs installed) connected to the internet via a non-NAT ADSL router at home. So far everything on the network works perfectly well.
To enable our remote user to connect to the network we enabled RRAS on the server following the KB article Q320697, “HOW TO: Turn on and configure inbound VPN access in Small Business Server 2000”. This worked fine and our remote user could both log onto the network and access files and e-mail. BUT!
Every time he connected to the server via VPN, he lost his Internet connection. No problem we thought – KB article Q317025 – “You cannot connect to the Internet after you connect to a VPN server” to the rescue. Except it DOESN’T WORK!!
We re-configured RRAS to a static address pool (192.168.15.1 – 192.168.15.10; our internal network is on subnet 192.168.16.0 / 255.255.255.0) and checked IP forwarding is enabled on the server. We then removed the ‘Use default gateway on remote network’ setting from the VPN connectoid on the remote PC, fired up the VPN connection (logged on fine) and went to put in the necessary routing statement to give the user access to our internal network exactly as detailed in Q317025. In our case this was “ route –p add 192.168.16.0 mask 255.255.255.0 192.168.15.1” Trouble is, Windows 2000 Pro won't let you put in such a routing statement! Every time we try to do so we get the following error message:
“The route addition failed: Either the interface index is wrong or the gateway does not lie on the same network as the interface. Check the IP Address Table for the machine”
Can anyone help? We have no idea what the problem is and there is nothing on the Microsoft KB whatsoever. This is a valid route yet Windows simply won't allow us to use it! We have tried the same with another client computer at another employee's homes and get the same there too.
Thanks
Ian W
One of our employees now works from home and needs access to the network. He has a Win2k Pro PC (again with all the latest service packs installed) connected to the internet via a non-NAT ADSL router at home. So far everything on the network works perfectly well.
To enable our remote user to connect to the network we enabled RRAS on the server following the KB article Q320697, “HOW TO: Turn on and configure inbound VPN access in Small Business Server 2000”. This worked fine and our remote user could both log onto the network and access files and e-mail. BUT!
Every time he connected to the server via VPN, he lost his Internet connection. No problem we thought – KB article Q317025 – “You cannot connect to the Internet after you connect to a VPN server” to the rescue. Except it DOESN’T WORK!!
We re-configured RRAS to a static address pool (192.168.15.1 – 192.168.15.10; our internal network is on subnet 192.168.16.0 / 255.255.255.0) and checked IP forwarding is enabled on the server. We then removed the ‘Use default gateway on remote network’ setting from the VPN connectoid on the remote PC, fired up the VPN connection (logged on fine) and went to put in the necessary routing statement to give the user access to our internal network exactly as detailed in Q317025. In our case this was “ route –p add 192.168.16.0 mask 255.255.255.0 192.168.15.1” Trouble is, Windows 2000 Pro won't let you put in such a routing statement! Every time we try to do so we get the following error message:
“The route addition failed: Either the interface index is wrong or the gateway does not lie on the same network as the interface. Check the IP Address Table for the machine”
Can anyone help? We have no idea what the problem is and there is nothing on the Microsoft KB whatsoever. This is a valid route yet Windows simply won't allow us to use it! We have tried the same with another client computer at another employee's homes and get the same there too.
Thanks
Ian W
