How to use two DSL Internet connections for VPN and Terminal Server access - for load splitting
Wanting to provide good performance for outside users accessing the Terminal Server, I have provisioned two 1+ meg DSL Internet lines with static IP and connected each to a VPN Router (Netgear FVS338). The intention is to provide Terminal Server access to about 25 outside users - splitting them into two groups and providing a different static IP address to each group - but both will access the same Terminal Server. In addition, inside users (on the office LAN) also use the Terminal Server and have the regular email and Internet browser traffic needs of an office user. The Terminal Server is Windows 2003 Enterprise with gigabit NIC.
Things are presently set up with VPN Router A providing service to some external users already, and the second Router B is only providing default-route NAT access to the Internet for the inside users email and web browsing. Before this scheme was set up, there was only one DSL connection for both VPN and inside users and the conflicting traffic needs of each group caused a lot of grumbling.
Now I would like to start using the second DSL Internet (Router B) and provide its static IP to the second group of outside users. But initial tests have failed to achieve a connection to the Terminal Server through the second IP - I guess it is a routing or default route issue, because the Terminal Server has to be able to route it's reply traffic back through the router the connection came in on.
I've researched this enough to realize that maybe I need to have a dual-WAN router, but surely I could add a third router between the Terminal Server and the two Netgears to accomplish the same thing? I favour this approach, because actually I would like to provide a *third* DSL Internet connection for the inside-originated Internet traffic, and restrict the other two routers to incoming Terminal Server traffic only.
There are other networking requirements including some Frame Relay in the mix too, but I am leaving that out for simplicity.
I would love some advice on setting this up!
Things are presently set up with VPN Router A providing service to some external users already, and the second Router B is only providing default-route NAT access to the Internet for the inside users email and web browsing. Before this scheme was set up, there was only one DSL connection for both VPN and inside users and the conflicting traffic needs of each group caused a lot of grumbling.
Now I would like to start using the second DSL Internet (Router B) and provide its static IP to the second group of outside users. But initial tests have failed to achieve a connection to the Terminal Server through the second IP - I guess it is a routing or default route issue, because the Terminal Server has to be able to route it's reply traffic back through the router the connection came in on.
I've researched this enough to realize that maybe I need to have a dual-WAN router, but surely I could add a third router between the Terminal Server and the two Netgears to accomplish the same thing? I favour this approach, because actually I would like to provide a *third* DSL Internet connection for the inside-originated Internet traffic, and restrict the other two routers to incoming Terminal Server traffic only.
There are other networking requirements including some Frame Relay in the mix too, but I am leaving that out for simplicity.
I would love some advice on setting this up!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks Robwill - it works fine.
I didn't add any static routes to the TS though, I put them into Router A. There was already a static route from Router B to Router A for a different reason.
Thanks for your help, and quick response!
Mike
I didn't add any static routes to the TS though, I put them into Router A. There was already a static route from Router B to Router A for a different reason.
Thanks for your help, and quick response!
Mike
Thanks mluckham.
Adding to the router will work fine, and likely not to be accidentally changed as well. I didn't think to suggest putting there, as not all smaller routers allow static routes.
Cheers.
--Rob
Adding to the router will work fine, and likely not to be accidentally changed as well. I didn't think to suggest putting there, as not all smaller routers allow static routes.
Cheers.
--Rob
ASKER
I consider these medium-range routers, with quite a few features. For example, in addition to static routes and dial backup, the FVS-338 even has multi-home IP addressability - which came in handy when I ran out of DHCP addresses and added a new overlay subnet on top of the smaller existing one.
My only complaints about them are sluggish web interface, and Netgear's habit of releasing new products that require several firmware releases to get right.
My only complaints about them are sluggish web interface, and Netgear's habit of releasing new products that require several firmware releases to get right.
I am not familiar with that model but it sounds like it has some nice features. I have worked with a few of there units and quite like them but I must say some have their share of problems and tech support is none existent.
ASKER
The other thing I wondered about was whether the TS should have another NIC and an internal subnet with only one of the VPN routers on it ... but I would still need to add the static routes as you recommend - so no gain from doing so, other than keeping the traffic separated.
The bottlenecks are not due to the Terminal Server, but the relatively low-bandwidth pipeline (DSL Internet) between the TS and the remote users, complicated by not having QoS routers ... so bursty Internet traffic (large emails and web pages) cause frequent and annoying delays for the TS session users.
I will configure some test VPN circuits and the TS routes as you suggest, and let you know what happens.