This is a piece I wrote a while back and lost when my hard drive died. Just found it again in one of the backups
These days, it’s not uncommon to have multiple ways to access the Internet. It is quite likely that you have a home DSL connection and another wireless connection via your mobile device, albeit a lot slower than the DSL. But if you’re anything like me, you had better keep a backup connection or two.
Until the recent disaster that wiped out most of my devices, I had DSL (from PTCL), a fiber-to-the-home connection (Nayatel) and a trial WiMax one (from Wi-Tribe that I’ll soon have to start paying for), all without any limits on how much I could download (at least after 8pm). (I wrote the above part right after the burnout, but things have fully recovered since then)
The simple way to deal with that is to maybe use your laptop with one link and your PC with the other (assuming you have more than one system). However, there’s another, geekier way which I discovered after going through a number of howtos and lots of experimentation.
I’ve configured my systems to route the traffic, first according to the destination, and secondly the system user. This means that I can fire up two separate browsers on the same system (more on that some other time), each using a different connection for the non-essential bandwidth usage.
Now for the nitty gritty (tested with Ubuntu 8.xx, but should work with any recent Linux distro):
- Firstly, make sure that the iproute package is installed
apt-get install iproute
(
yum install iproute
for RedHat based systems)
- Next, add your own definitions for your connections in /etc/iproute2/rt_tables (just a unique number and a descriptive string should do):
101 nayatel 102 ptcl 103 witribe
- Then associate each table with a number so that packets marked by iptables can find their way:
ip rule add fwmark 1 table nayatel ip rule add fwmark 2 table ptcl ip rule add fwmark 3 table witribe
- Delete any existing default route and add the relevant routes for each connection. I chose to have the PTCL connection as the new default route:
ip route del default ip route add default via 192.168.0.200 table ptcl ip route add default via 192.168.0.100 table nayatel ip route add default via 192.168.0.300 table witribe ip route add default via 192.168.0.200
- Now simply use the mangle table and add iptable rules to segregate the traffic. In the example, I route all my important traffic through the Nayatel FTTH connection (mark 1) and the rest depending on the userid, but you can be as creative as you like:
iptables -t mangle -A OUTPUT -d 66.240.221.0/255.255.255.0 -j MARK --set-mark 1 iptables -t mangle -A OUTPUT -m owner --uid-owner 1020 -j MARK --set-mark 1 iptables -t mangle -A OUTPUT -m owner --uid-owner 1034 -j MARK --set-mark 2 iptables -t mangle -A OUTPUT -m owner --uid-owner 1043 -j MARK --set-mark 3
That’s it. Sit back and let loose the fury.
The above steps are only valid for TCP or UDP traffic. ICMP (pings) will still use the default route so don’t be surprised to have excellent ping times when you think the traffic should be going over wireless.
You can also go for a more sophisticated approach. Set a cronjob or your rc.local script to set the routes according to the time of day.
current_hour=`date +%H` if [ $current_hour -gt 8 ] && [ $current_hour -lt 20 ]; then ip route add default via 192.168.0.200 table nayatel ip route add default via 192.168.0.200 else ip route add default via 192.168.0.100 table nayatel ip route add default via 192.168.0.100 fi
I’ll leave the other possibilities up to your imagination, but it took a lot of digging just to get enough information to do the above. Hope it comes in handy to someone.
3 thoughts on “Using multiple broadband links from one system”
Makes for some interesting experimentation… Cool!
Really intriguing. I once wanted to do such mangling based on protocols (so that all IRC traffic would go through the GPRS cellphone link while the rest would go through ADSL). I tried for a while and later forgot about the thing because I no longer required the particular setup. Your post brought back the itch though. Perhaps you can shed some light on achieving protocol-based filtering?
Thanks a lot for sharing good piece of information.
Comments are closed.