I suspect my ISP has rather poor peering arrangements, causing slow access to several sites that I regularly visit. I determined that fact by proxying my web traffic to a server that I've placed in a data center somewhere nearby and seeing tremendous improvement in my surfing experience. So I'm pretty sure that my last mile is relatively clean, giving me as much as is advertised, while it's the uplinks from my ISP that is causing issues.

I'd like to take the proxy one step forward and route all my home traffic through my server, as the data center's peering arrangements seem to be much better. How should I accomplish this? I've figured on 2 possible ways:

  1. Configure a static route from my home router to the server. I assume I'd have to configure the server's IPTable stack to act as a router as well?
  2. Configure OpenVPN on my server and configure OpenVPN clients on all the PCs in my house.

I'd like some feedback on which approach would be better. My server is running Debian, my home router is running Tomato firmware on top of the Linksys WRT54GL and the PCs at home are running Ubuntu variants.

Thanks! Wong

  • May seem a bit obvious, but can't you change ISP? Why give money to a company that can't get their stuff right? :-) Sep 14, 2012 at 20:29

3 Answers 3


Option 1 is out of the question, there is no way (that will work) to tell your ISP to route your packets differently.

Option 2 will work. Just set up an openvpn connection, set a static route to your server through the ISP's default gateway (the one your normally have for all traffic), then set your default gateway to your server's openvpn endpoint IP. You might want to take some services out (for example DNS servers), by adding additional static routes to the target IP's (the DNS servers) through your ISP's gateway.


The Tomato firmware is probably better, but normal crappy router firmwares often don't allow you to configure routing properly. And sometimes when they appear to do so, they don't, because they insert their default routes in places that you can't change, and therefore have no control.

However, aside from that, I think you should just set your server as default gateway on your router and enable IP forwarding on the server (/etc/sysctl.conf). Using OpenVPN is basically the same, except that it also encrypts it; openVPN alters your routing table in the same way you would do manually.

One of the reasons I wouldn't opt for OpenVPN, is because when you configure it so that all internet traffic is routed over it (with push 'redirect-gateway def1' and push "dhcp-option DNS x.x.x.x"), is that it creates some annoyances. For example, local DHCP servers are no longer reachable, so that your connection my fail when your lease ends.

Also, a special route is made to redirect all trafic to your server's IP address to go over the TUNx device. This means your server is no longer reachable by its original IP. Normally that's no problem, because you can use your VPN'ed address to reach it (the VPN server is available on a special address), but if you have a webserver running on it, it has to be available on the IP address in your DNS A records, otherwise the virtual hosts won't work.


You'll need some sort of IP tunnel to guarantee that the traffic ends up at your co-located server, this MAY be easier using OpenVPN or similar.

If there are routers between your home router and the data centre (most probable), just setting the default gateway on your home router to be your data centre server will result in your home router being unable to send ANY traffic (as the "next hop" would not be locally connected).


The need for some sort of encapsulating is that intermediate routers will not know that you want the packet to go via your server. By using any tunnel encapsulation (IP-in-IP, GRE, a full-fledged IPSEC VPN, SOCKS or something else), the outermost packet is destined for your server, where the encapsulated frame can then be extracted and sent on.

You may need to NAT the packets at your server, to ensure that return packets go the same route, by-passing the peering arrangements of your ISP (I have assumed that you have decent throughput to your co-located server, here).

By using your server as a web proxy, there are two TCP sessions established. One is from your workstation to your server, the second is from your server to the web server.

  • That is not always the case. My home IP-address is on subnet However, the gateway is Linux machines can't handle this information as passed in the DHCP response by default, so I had to adjust my routing table manually. Windows machines can handle it. If you just make a route that says that to connect the IP of the server, say, it has to use interface eth0, wouldn't that work? That's what I did with that router not being on the same subnet problem.
    – Halfgaar
    Jul 25, 2010 at 12:10
  • You'll get the packets sent in the right direction, but after that, they'll be routed based on the destination IP address, not what you want as a next hop. A tunnel encapsulates your IP datagram as a payload in another IP packet, with the tunnel termination point as the DST address in the encapsulating traffic.
    – Vatine
    Jul 27, 2010 at 12:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.