From: Andy Furniss <andy.furniss@dsl.pipex.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Packet Level Load Balance inbound/outbound success with
Date: Tue, 08 Feb 2005 00:58:21 +0000 [thread overview]
Message-ID: <42080EAD.9020402@dsl.pipex.com> (raw)
In-Reply-To: <cfc690b705020207426dccd65d@mail.gmail.com>
Joe Nuts wrote:
> First of all, I'd like to thank Andy Furniss for his direction and for
> helping me get a working example up and running.
>
> For the following set up to work, you will need a linux computer at
> the ISP (server), a linux computer at the client location (client),
> and some a public range of IP's you plan to send down to your client.
>
> (as this configuration involves patching the linux kernel, I assume
> you have already downloaded it, and have previously compiled a kernel)
> steps to set up the linux computers are )
> make sure both computers have forwarding allowed (i do this with a
> 'net.ipv4.ip_forward = 1' line in my /etc/sysctl.conf)
> download iptables source, and patch-o-matic files from netfilter.org
> unzip those files. run the patch-o-matic script. when you get to the
> 'nth' and 'ROUTE' packages, select Y.
> then, in the kernel config, under networking options, under netfilter
> configuration, under iptables support, select nth, and under packet
> mangling, select ROUTE.
> compile the kernel, reboot with new kernel.
> compile iptables, make && make install.
> even after running make install, on my system, the two iptables
> libraries didnt make it to /lib/iptables, so i had to copy them
> manually. (copy libipt_nth.so and libipt_ROUTE.so from the iptables
> source to /lib/iptables)
>
> now, I use GRE tunnels from the server to the client to send inbound
> traffic, I assume you can use any kind of tunnel, just make sure
> support for whatever you want to use is installed in to the kernel.
>
> for the sake of the example, IP's will be defined as follows :
> Local IP at client : 66.81.23.1 (eth0)
> DSL #1 at client : 64.20.12.46 (eth1) (64.20.12.45 is gateway)
> DSL #2 at client : 64.20.12.50 (eth2) (64.20.12.49 is gateway)
>
> Public IP of server : 66.80.22.30
> Public IP Range sent to client : 66.81.23.0/24
>
> the tunnels need to be set up on both the client and the server
> --server--
> ip tunnel add client_tun1 mode gre remote 66.20.12.46 local 66.80.22.30 ttl 255
> ip tunnel add client_tun2 mode gre remote 66.20.12.50 local 66.80.22.30 ttl 255
> ip link set client_tun1 up
> ip link set client_tun2 up
> ip addr add 172.16.0.1/30 dev client_tun1
> ip addr add 172.16.0.5/30 dev client_tun2
> --client--
> ip tunnel add client_tun1 mode gre remote 66.80.22.30 local 66.20.12.46 ttl 255
> ip tunnel add client_tun2 mode gre remote 66.80.22.30 local 66.20.12.50 ttl 255
> ip link set client_tun1 up
> ip link set client_tun2 up
> ip addr add 172.16.0.2/30 dev client_tun1
> ip addr add 172.16.0.6/30 dev client_tun2
>
> traffic outbound from the client doesnt need to go out the tunnel, but
> it does need to be split
> --client--
> iptables -A POSTROUTING --source 66.81.23.0/24 -t mangle -m nth
> --counter 0 --every 2 --packet 0 -j ROUTE --oif eth1 --gw 64.20.12.45
> iptables -A POSTROUTING --source 66.81.23.0/24 -t mangle -m nth
> --counter 0 --every 2 --packet 1 -j ROUTE --oif eth2 --gw 64.20.12.49
>
> traffic inbound to the client will go to the server, and come to
> client through the tunnel
> --server--
> iptables -A POSTROUTING --destination 66.81.23.0/24 -t mangle -m nth
> --counter 0 --every 2 --packet 0 -j ROUTE --oif client_tun1 --gw
> 172.16.0.2
> iptables -A POSTROUTING --destination 66.81.23.0/24 -t mangle -m nth
> --counter 0 --every 2 --packet 1 -j ROUTE --oif client_tun2 --gw
> 172.16.0.6
>
>
> Of course this set up can be used to divide across more than two
> links, just duplicate / modify the lines as needed.
> Computers behind the client can now be given public IP's in that
> range, set their gateway to 66.81.23.1, and they're up and running on
> both lines.
>
> I hope this helps someone like me!
> Sincerely,
> Joe Comeaux
Glad you got it working and thanks for posting the solution - all credit
to you for that setup - all my suggestions were untested and a bit
vague, you did all the work :-)
Andy.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2005-02-08 0:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-02 15:42 [LARTC] Packet Level Load Balance inbound/outbound success with nth and route Joe Nuts
2005-02-08 0:58 ` Andy Furniss [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42080EAD.9020402@dsl.pipex.com \
--to=andy.furniss@dsl.pipex.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.