[ale] Stupid question time: PAT vs NAT

[JK]

Jim Popovitch wrote:
> On Tue, 2007-05-08 at 12:46 -0600, JK wrote:
> 
>>I think your problem is here.  Because you're redirecting in
>>the PREROUTING chain, by the time the packet gets into the
>>FORWARD chain, the destination has already been changed. So
>>you need the second rule to be:
>>
>>   iptables -A FORWARD -p tcp -i tap0 -d some.other.host --dport 587
>>             -j ACCEPT
> 
> 
> (resend, first time never made it)
> 
> Opps, I actually made a mistake in my earlier example.  I use a script
> to setup iptables,  the script reads a config file.  I inserted the IP
> addresses wrong when translating the script contents into the email.
> Here is the actual rules but for a different port:
> 
>   iptables -t nat -A PREROUTING -p tcp -i tap0 -d 10.0.1.1 \
>           --dport 1110 -j DNAT --to 206.190.53.11:110
>   iptables -A FORWARD -p tcp -i tap0 -d 206.190.53.11 --dport \
>            110 -j ACCEPT

You might try inserting (-I) rather than appending (-A) these
rules.  iptables uses the first matching rule for a particular
packet, so when you append rules, they may never see the packets
you expect them to, since an earlier rule might drop them.
(This is in contrast to netfilter, which uses the *last* applicable
rule.  I tripped over this when moving from OpenBSD to Linux for
my firewall.)

If that doesn't work, then I'm baffled.  My approach when confronting
this kind of problem is to start by simplifying the rules as much as
possible.  While for security purposes we want to reject everything by
default and allow only specific stuff in/out, for troubleshooting I
usually proceed from the opposite side of the security spectrum: open
everything up, then figure out which restriction stops things from
working properly.  In this case, that might mean telling your FORWARD
chain to simply accept *everything* destined for 206.190.53.11:

   iptables -I FORWARD -p tcp -d 206.190.53.11 -j ACCEPT

and then add back in the port and ingress interface specifiers and
see which one breaks.

-- JK

> Still, connections are dropped.  While telnet'ing to 10.0.1.1 port 1110
> from 10.0.1.100, tcpdump on 10.0.1.1 shows traffic to 10.0.1.1 port
> 1110, and a response back to the remote client (10.0.1.100), but nothing
> after that.
> 
> Here's the output of "tcpdump -i any port 1110 or port 110" 
> 
> 15:24:44.316073 IP 10.0.1.100.56064 > 10.0.1.1.1110: S
> 4040879985:4040879985(0) win 5840 <mss 1336,sackOK,timestamp 20883399
> 0,nop,wscale 2>
> 15:24:44.316119 IP 10.0.1.1.1110 > 10.0.1.100.56064: R 0:0(0) ack
> 4040879986 win 0
> 15:24:47.315995 IP 10.0.1.100.56064 > 10.0.1.1.1110: S
> 4040879985:4040879985(0) win 5840 <mss 1336,sackOK,timestamp 20884149
> 0,nop,wscale 2>
> 15:24:47.316036 IP 10.0.1.1.1110 > 10.0.1.100.56064: R 0:0(0) ack 1 win
> 0
> 15:24:53.314805 IP 10.0.1.100.56064 > 10.0.1.1.1110: S
> 4040879985:4040879985(0) win 5840 <mss 1336,sackOK,timestamp 20885649
> 0,nop,wscale 2>
> 15:24:53.314846 IP 10.0.1.1.1110 > 10.0.1.100.56064: R 0:0(0) ack 1 win
> 0
> 15:25:05.316635 IP 10.0.1.100.56064 > 10.0.1.1.1110: S
> 4040879985:4040879985(0) win 5840 <mss 1336,sackOK,timestamp 20888649
> 0,nop,wscale 2>
> 15:25:05.316678 IP 10.0.1.1.1110 > 10.0.1.100.56064: R 0:0(0) ack 1 win
> 0

-- 
"What can be asserted without evidence can also be
dismissed without evidence." -- Christopher Hitchens