FW: port forwarding and load balancing redux (Repost)

Tim Coleman tcoleman@b2bscene.com
Thu, 14 Sep 2000 12:28:22 -0400


I don't think my last email got through to the list, so I'm
trying again.

-----Original Message-----
From: Tim Coleman [mailto:tcoleman@b2bscene.com]
Sent: Thursday, September 14, 2000 9:17 AM
To: Harald Welte
Cc: netfilter@lists.samba.org
Subject: RE: port forwarding and load balancing redux




> -----Original Message-----
> From: Harald Welte [mailto:laforge@gnumonks.org]
> Sent: Tuesday, October 03, 2000 6:12 AM
> To: Tim Coleman
> Cc: netfilter@lists.samba.org
> Subject: Re: port forwarding and load balancing redux
>
>
> On Wed, Sep 13, 2000 at 05:30:51PM -0400, Tim Coleman wrote:
> > Just another interesting tidbit in my search for load balancing.
> > I'm doing SNAT so that clients on the local network can talk
> > to the load balanced servers.
> >
> > iptables -t nat -A PREROUTING -p tcp -d 192.168.131.98 --dport 80
> > -j DNAT --to 192.168.131.89 --to 192.168.131.99
> >
> > As I previously mentioned, all the packets go to the first host
> > which isn't so hot.
> >
> > I noticed that if I remove the SNAT rules, packets seem to go
> > out both ways (of course, none of their replies are acknowledged
> > by clients, but it's interesting nonetheless).
>
> If You insert a DNAT rule, the reply packets should get NATed
> automagically by
> the NAT subsystem. Just think about the semantics of a MASQUERADE rule -
> you only have to insert it once to do alter request AND reply packets.

Not if the server is on the same network as the client.  I'm not using
a MASQUERADE rule.  From the Linux 2.4 NAT HOWTO:

<URL:http://netfilter.kernelnotes.org/unreliable-guides/NAT-HOWTO-10.html>

   10. Destination NAT Onto the Same Network

   If you are doing portforwarding back onto the same network, you need to
   make sure that both future packets and reply packets pass through the
   NAT box (so they can be altered). The NAT code will now (since
2.4.0-test6),
   block the outgoing ICMP redirect which is produced when the NAT'ed packet
   heads out the same interface it came in on, but the receiving server will
   still try to reply directly to the client (which won't recognize the
reply).

   [...]

   The other way is to have the NAT box also map the source IP address to
its own
   for these connections, fooling the server into replying through it. In
this
   example, we would do the following (assuming the internal IP address of
the
   NAT box is 192.168.1.250):


   # iptables -t nat -A POSTROUTING -d 192.168.1.1 -s 192.168.1.0/24 \
           -p tcp --dport 80 -j SNAT --to 192.168.1.250

   Because the PREROUTING rule gets run first, the packets will already be
   destined for the internal web server: we can tell which ones are
internally
   sourced by the source IP addresses.

This is what I'm trying to do with the SNAT rules.  It seems that if I
remove
the SNAT rules, each request alternates between the two destination hosts.
If I add them, requests always go to the first one.

I don't think that the POSTROUTING chain should affect the PREROUTING
decision, so I'm at a loss for an explanation.

Tim
_________________________________________

Putting the Web to Work

Tim Coleman
Web Developer

tcoleman@b2bscene.com
http://www.b2bscene.com/
519.888.7111 x2619
888.450.2547