Site-to-site vpn using remote gateway for internet traffic?

Question

We're moving a small remote office to a new location which means a new internet connection and a new router. I noticed that they are configured currently to use the remote gateway through the VPN, thus all their internet traffic goes through the connection in the central office which just seems to be slow and inefficient to me.

I'm thinking of configuring them to use their local gateway for non-VPN traffic. Is there a reason why I should not be doing this? Seems to me that's the best way to go about this. Unfortunately, the guy who set this up is long gone and I'm not sure what justification you would have to do this.

Answer 1

Typically there are two reasons I see this done.

• As Robert Kaucher mentioned, content filtering, logging, and enforcement at the "hub site" is one big reason. Many content filtering products allow "slave" servers to be deployed at remote sites to perform filtering and logging based on a central "policy server". For a remote site where there isn't any server computer, though, and organization might just opt to route all that traffic back to a central filtering server.

• Centralized firewall rules and monitoring are another common reason I've seen this done (for user-to-site VPNs in particular, but I've seen it with site-to-site, too). "Split tunneling" (that is, allowing the remote VPN endpoint to directly communicate with the Internet and sending only traffic to the corporate network down the VPN pipe) is seen by some as a major security risk. In a site-to-site environment, you could make the call that the firewall in the remote office should be configured to allow safe direct Internet access, but I've seen situations where it was considered "better" (I suppose because the firewall rules at the remote site ended up being, basically, "allow VPN traffic only") to route all that Internet traffic to the "hub" site.

You should see an improvement in bandwidth utilization at the "hub" site, and improved responsiveness at the remote site by moving to a split tunnel. As long as you've got solid firewall rules in the remote site (and whatever monitoring infrastructure, content filter, etc that you want) there shouldn't be any reason not to allow it to have direct Internet access and save bandwidth at the "hub" site.

Answer 2

The only real reasson that you might want to do that is for content filtering - at least as far as I know. It would be easier to manage for you as there is only one content filter to worry about.

Answer 3

These probably aren't likely, but as things to rule out:

• Hide branch at which individuals are located
• Hide low-end connections at branch site
• Public IPs allocated out of main site pool
• Some server there needs to be accessed from outside, and that NAT needs to happen at main site
• Access to some resource linked to source IP (unfortunately common in education)

Like Evan mentioned, I suspect the real cause is firewall rules, possibly because old gear didn't have a good stateful firewall. Assuming that there's one now, I don't see any general reasons not to have their Internet traffic be sent out direct. That's how my workplace's remote sites have always operated.