IPTABLES NAT

IPTABLES NAT

[Matthew Mileham]

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

Hi 

I wonder if any body can help me ?

I've got 2 Redhat 9 Linux Servers purely running iptables and only using the NAT function

I want to load balance over two boxes, I want to send traffic out the one box and SNAT 57.24.224.242, 
and return traffic to return to the second box and DNAT to 172.20.128.121 

If I send traffic over the one box and receive on the same box it works, but when I split the traffic it doesn't work !

the rules are as follows 

Box1 
iptables -t nat -A POSTROUTING -o eth1 -s 172.20.128.121 -j SNAT --to 57.24.224.242

Box2 
iptables -t nat -A PREROUTING -i eth1 -d 57.24.224.242 -j DNAT --to 172.20.128.121

Thanks 




[-- Attachment #2: Type: text/html, Size: 2129 bytes --]

Re: IPTABLES NAT

[Jim Carter]

On Wed, 10 Sep 2003, Matthew Mileham wrote:
> I've got 2 Redhat 9 Linux Servers purely running iptables and only using
> the NAT function

> I want to load balance over two boxes, I want to send traffic out the one
> box and SNAT 57.24.224.242, and return traffic to return to the second
> box and DNAT to 172.20.128.121

> If I send traffic over the one box and receive on the same box it works,
> but when I split the traffic it doesn't work !

Suppose an internal machine originates a connection.  Its initial packet
goes out box 1 and a connection is recorded.  If the outside world's answer
came back to box 1, then box 1 could undo the SNAT and send the packet to
the originator.  But box 2 has no idea what's going on.  If the answer goes
through box 2, it either drops the packet if you have
    iptables -t filter -P FORWARD DROP
    iptables -t filter -A FORWARD -m state --state NEW,RELATED,ESTABLISHED \
	-j ACCEPT
because this is for a connection it has no record of, or it might forward
the packet to box 1 which maybe, possibly, could recognize and correctly
forward it, if the filter rules had the right security holes.  The effect
is similar if an outside machine originates the connection to your internal
host.

It's "accepted wisdom" that the load on the machine from forwarding packets
is very low, assuming your netfilter rules aren't too baroque and assuming
you avoid logging most packets (log only the ones you drop).  Your kind of
load sharing would only be justified if you had extreme datarates like a
fully saturated OC-12 link or something like that.  If that were really
true, I would load-share by splitting the internal subnet and giving one
gateway machine to each half.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90095-1555
Email: jimc@math.ucla.edu    http://www.math.ucla.edu/~jimc (q.v. for PGP key)

RE: IPTABLES NAT

[George Vieira]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

Can you explain your network layout on this?
 
Are these 2 independant ISPs your connected through?

-----Original Message-----
From: Matthew Mileham [mailto:matthew@postbag.co.za]
Sent: Wednesday, September 10, 2003 4:07 PM
To: Netfilter Mailing List
Subject: IPTABLES NAT

 
Box1 
iptables -t nat -A POSTROUTING -o eth1 -s 172.20.128.121 -j SNAT --to 57.24.224.242
 
Box2 
iptables -t nat -A PREROUTING -i eth1 -d 57.24.224.242 -j DNAT --to 172.20.128.121
 
 
 
 
 


[-- Attachment #2: Type: text/html, Size: 1788 bytes --]

iptables nat

[Lohan Spies]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

Hi all,
 
How can i configure a nat rule so that the original ip address is sended
to the nat server instead of the ip of the fw?
 
Thanks,
 
Lohan Spies 
Systems Administrator CSA / DBA / MCP
IQ Business  <http://www.iqgroup.net/> Group
Tel: +27 12 521 7309
Fax: +27 12 541 3441
Cell: +27 83 258 2698
l.spies@petzetakis-africa.co.za 


 

 


CONFIDENTIALITY CAUTION: If you have received this communication in error, please note that it is intended for the addressee only, is private and confidential and dissemination or copying prohibited. Please notify us immediately by e-mail and return the original message. We cannot assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. Thank you

[-- Attachment #2: Type: text/html, Size: 3937 bytes --]