Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Admin <netfilter-info@internode.com.au>
To: netfilter@lists.netfilter.org
Subject: troublesome load balancing and iptables to the rescue...maybe
Date: Tue, 27 Jun 2006 19:47:38 +0930	[thread overview]
Message-ID: <200606271947.38079.netfilter-info@internode.com.au> (raw)

Hi all

We have a load balanced set of web servers (behind an alteon AD3) which all 
work fine - except when the real servers (the webserver instances on the load 
balanced machines) try to access the virtual ip (vip) on the alteon.

Here's how it works

clientIP=AA
VIP=BB
RealServerIP=CC
SourceIP=sip
DestinationIP=dip

The vip and real_server ips are all on the same network.

# client request from the outside
(client) -> (vip) - sip=AA, dip=BB
(vip) -> (real_server) - sip=AA, dip=CC
# return traffic (real server on CC responds to client on AA)
(real_server) -- sip=CC, dip=AA --> (alteon) -- sip=BB, dip=AA --> client

So the alteon substitutes the virtual server ip with the real server one and 
back again for the load balancing to work.

Now the problem, we need the real servers to be able to access the service 
provided on the VIP also. The ports on the alteon are configured properly 
(client and server enable and so on) but the problem seems to be a routing 
one.

Here's the flow of traffic when the real server tries to access the vip

# client request
(client) -> (vip) - sip=CC, dip=BB
(vip) -> (real_server) - sip=CC, dip=CC
# return traffic (real server on CC responds to client on CC - oops that's me)
(real_server) -- sip=CC, dip=CC --> straight back to the real server, no dice.

Now this is a common problem, usually solved by using proxy-ips, however the 
alteon proxy-ips don't add X-Forwarded-For headers meaning our servers won't 
get the correct client IPs - which is unacceptable.

I have been trying to find a way to mangle the packets with iptables (on the 
real servers) to make this work.

The obvious (well...kinda obvious) way is to change the sip (to something 
outside the local network)  on the incoming packet somewhere in the 
PREROUTING or INPUT phase, then modify the dip in the response packet in the 
POSTROUTING phase back to that of the real server.

Unfortunately this is pretty much the reverse of what DNAT and SNAT are used 
for.

We want SNAT on the PREROUTING or INPUT phase and DNAT in the POSTROUTING (or 
possibly OUTPUT, but I don't think so) one.

Or perhaps - is there any way to force traffic from one IP to the same IP to 
go through a remote router? Perhaps mark traffic from the real server to the 
vip then act on that mark when the alteon directs it back?

Can anyone offer any ideas how to solve this issue?

Many thanks
Admin


             reply	other threads:[~2006-06-27 10:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-27 10:17 Admin [this message]
2006-06-27 16:24 ` troublesome load balancing and iptables to the rescue...maybe Pascal Hambourg
2006-06-28  8:58   ` Admin
2006-06-28 11:44     ` Pascal Hambourg

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=200606271947.38079.netfilter-info@internode.com.au \
    --to=netfilter-info@internode.com.au \
    --cc=netfilter@lists.netfilter.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox