On 09.08.2006, at 14:35, Marek Zachara wrote:
Maybe these lines will help you... :) But if not.... :D
$IPT -t nat -A POSTROUTING -j SNAT -p tcp --dport www -d $WWW
--to-source $MY_IP
$IPT -t nat -A POSTROUTING -j SNAT -p tcp --dport www -d $WWW
--to-source $MY_IP
well, the packets can be send out with two different IPs - depending
on which
ISP the connection came from - so this would just bind all connections
to one
of the IPs making it impossible to have a connection from the other
one.
no, i am pretty sure the snatting must be done automatically based on
contrack
entries.
I agree. These rules don't make much sense. Actually, the second rule
won't ever get hit as the first one gets all the traffic.
What _can_ be done, while not solving our problem, is rewriting of the
outgoing traffic to the IP of that interface:
# iptables -t nat -A POSTROUTING -o ${extif1} -s ! ${extnet1}/29 -j
SNAT --to ${extip1}
# iptables -t nat -A POSTROUTING -o ${extif2} -s ! ${extnet2}/29 -j
SNAT --to ${extip2}
Which makes sense, however does not discharge conntrack of the duty to
handle
reply packets, as these rules left alone would just lead into the
replies
having the wrong IP address in addition to going out on the wrong
interface.
Conntrack should, at least that's my understanding, SNAT (or should I
say de-DNAT) the
replies before they enter the routing mechanism.
Is anybody who know the code well enough to tell why the packets don't
hit
the conntrack snat 'rules' or aren't rewritten out on the list? Thanx!
Baltasar
--
Baltasar Cevc
_____ former 03 gmbh
_____ infanteriestraße 19 haus 6 eg
_____ D-80797 muenchen
_____ http://www.former03.de
