Hmm. Nope.
I added this rule:
iptables -vt nat -A PREROUTING -p tcp --dport 6969 -s 192.168.0.0/24 \
-d 192.168.0.100 -j SNAT --to 65.9.134.4
And I get this error:
SNAT tcp opt -- in * out * 192.168.0.0/24 -> 192.168.0.100 tcp
dpt:6969 to:65.9.252.78
iptables: Invalid argument
Seems like it doesn't like the "SNAT" target in the PREROUTING chain (if
I replace it with "DROP", the rule inserts fine). Your idea makes
sense, Rob, but seems like something's still one step away...
Regards,
Jon Heese
/dev/rob0 wrote:
On Thursday 2005-October-27 08:07, Jon Heese wrote:
Change your DNAT rule to match all the packets you want to match:
iptables -vt nat -A PREROUTING -d 65.9.134.4 -p tcp --dport 6969 \
-j DNAT --to 192.168.0.100
Except for the --verbose, that's exactly what I'm already doing to
DNAT everything from the outside through to castor's 6969. This rule
does not seem to be catching traffic from the inside. Do I have to
do something special to get internal traffic into the PREROUTING
After I sent this (and went to bed :) ) I realised what must be
happening: it's getting the original packet there, but replies are
going direct to the IP of the originator.
Suppose 192.168.0.129 connects to 65.9.134.4:6969 ... the router passes
it faithfully on to 192.168.0.100. Now 192.168.0.100 has a packet from
192.168.0.129, and it won't send the reply to 65.9.134.4. The client at
192.168.0.129 is going to be confused. This cannot be a reply to my
65.9.134.4:6969 connection attempt, go away, Castor.
Perhaps you need a SNAT rule in POSTROUTING:
iptables -vt nat -A PREROUTING -p tcp --dport 6969 -s 192.168.0.0/24 \
-d 192.168.0.100 -j SNAT --to 65.9.134.4
A cleaner solution (not sure if applicable to BitTorrent) would be an
alternate DNS view, so that external clients resolve the name to
65.9.134.4 whilst internal ones resolve to 192.168.0.100.
