LVS-NAT with multiple RIP to VIP associations

[David M]

Oops, make that:
Incoming:
iptables -t nat -A PREROUTING -d <Public IP> -i $EXT_INTERFACE -j DNAT
--to-destination <VIP>
Outgoing:
iptables -t nat -A POSTROUTING -s <VIP> -o $EXT_INTERFACE -j SNAT
--to-source <Public IP>

David Mitchell


On 12/19/06, David M <northridgeaustin at gmail.com> wrote:
>
>
> Rob:
>
> Thank you for the recommendation.
>
> I hope that I understand you correctly.  You are running pf on a
> separate firewall, right (and not on the LVS-DR)?  "px.py.pz.1" are
> the public IPs, right?
>
> Since we are a mostly Linux shop, I would have to try to see if I could
> make this work using iptables (rather than pf).  I guess that the iptables
> rules for a separate firewall would look something like this:
> Incoming:
> iptables -t nat -A PREROUTING -d <Public IP> -i $EXT_INTERFACE -j DNAT
> --to-destination <VIP>
> Outgoing:
> iptables -t nat -A POSTROUTING -s <Public IP> -o $EXT_INTERFACE -j SNAT
> --to-source <VIP>
>
> Having a separate firewall makes sense.  Do you think that this is how
> most people are using LVS, i.e., with a separate firewall?
>
> David Mitchell
>
>
> On 12/15/06, Rob <ipvsuser at itsbeen.sent.com> wrote:
> >
> > > Our setup is currently working. I was just wondering if there is a
> > better
> > > way to do this.
> >
> > Well, the way I set up things up is different (possibly better) -
> > My goal is to make it easy to config/manage/troubleshoot, secure, fast
> > and
> > low load on the director(s):
> >
> > * I use OpenBSD and pf to separate public and private IP spaces
> > * Use LVS-DR for all the lvs work (not sure if you can do this or if you
> > need
> >   to use nat for some other reason)
> >
> > By separating the NATing from the load balancing it seems to simplify
> > the
> > configuration of both and I feel it is easier to write pf rules than
> > iptables (YMMV).
> >
> > In pf for each of the 30 email servers you need 2 rules:
> > Outgoing:
> > nat pass on $ext_if inet proto tcp from 172.16.1.1 to port 25 ->
> > px.py.pz.1
> > Incoming:
> > rdr pass on $ext_if inet proto tcp from any to px.py.pz.1 port 25 ->
> > 172.16.1.1 port 25
> >
> > The above will send incoming connections to the correct VIP and keep the
> > outgoing
> > connections/replies coming from the correct public IP.
> >
> > For the LVS config:
> > -A -t 172.16.1.1:25 -s nq
> > -a -t 172.16.1.1:25 -r 172.16.1.101:25 -g -w 100
> > -a -t 172.16.1.1:25 -r 172.16.1.102:25 -g -w 100
> > -a -t 172.16.1.1:25 -r 172.16.1.103:25 -g -w 100
> >
> > No special routing set up on the director or real servers, all machines
> > have the
> > OpenBSD firewall as their gateway. Low load on the director since it is
> > DR.
> >
> > Then to cheat on the arp issue, I hardcode the MAC Address of the
> > director into the
> > arp table on the OpenBSD firewall for each of the VIPs
> > (and run arpwatch and set the Linux machines arp sysconfig params)
> >
> > One of the cool things you can do with a set up like this is use the
> > excellent table handling in pf,
> > I have about 85,000 ips that I know are spammers and I don't want them
> > using any resources on my
> > MTA boxes so I redirect all of them to OpenBSD's spamd which tarpits
> > them at extremely low cost:
> >
> > table <spammers> persist file "/etc/spammers.txt"  {}
> > rdr pass on $ext_if inet proto tcp from {<spammers>} to any port 25 ->
> > 127.0.0.1 port 8027
> >
> > This means that the MTA boxes can service real mail more quickly since
> > slots are not
> > being used by spammers.
> >
> > I do similar things for bogons http://www.cymru.com/Bogons/ and ssh
> > brute force attackers.
> > I haven't found a reasonable way to work with any sizable tables in
> > iptables.
> >
> > pf and lvs - "Two great tastes that taste great together..."
> > _______________________________________________
> > LinuxVirtualServer.org mailing list - lvs-users at LinuxVirtualServer.org
> > Send requests to lvs-users-request at LinuxVirtualServer.org
> > or go to http://www.in-addr.de/mailman/listinfo/lvs-users
> >
>
>