ftp conntrack - nat problem

ftp conntrack - nat problem

[Dave Strydom]

Hey :D

I have a firewall with a number of servers behind it (gentoo linux
servers with proftpd and a NT 2000 server)

Now from the internet side of things, when you try ftp files to these
servers using PASSIVE MODE (PASV) it does like 9 - 15 files and then
kicks out something like this:

===
213 223
    Remote file exist check: 'check_forged.php'.
    SIZE check_forged.php
550 check_forged.php: No such file or directory
    PASV
227 Entering Passive Mode (209,212,xxx,xxx,211,29).
    Opening data connection to 209.212.xxx.xxx Port: 54045
    STOR check_forged.php
0 Opening BINARY mode data connection for check_forged.php
    Timeout (20s).
    Active Help: http://www.smartftp.com/support/kb/index.php/74
    Client closed the connection.
    Transfer failed.
===

And just dies there.
Now if I use ACTIVE MODE (PORT) i get the same thing... my question is why?

Here is a copy of my firewall script:

-----------------------------------------------------------------------------
#!/bin/bash
# START DEFINE
###########################################

# Where Iptables is Located #
IPTABLES="/sbin/iptables"

# Local Network #
LOCAL_NETWORK_IP_RANGE="192.168.0.0/24"

# Loopback Interface #
LO_IP=" 127.0.0.1"

# Athena #
ATHENA_LO_IN_IP="192.168.0.1"
ATHENA_LO_EXT_IP="10.0.0.1"

# Hyperion #
HYPERION_LO_IP=" 192.168.0.246"

# External Interface IP's #
EXT_146_IP="209.212.xxx.xxx"

# START RULES
########################################################

# SysCtl Rule Set #
echo "1" > /proc/sys/net/ipv4/ip_forward                        #
Advanced Router Packet Forward
echo "1" > /proc/sys/net/ipv4/conf/all/forwarding               #
Enable NAT Forwarding
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter                #
Allow RP Filters
echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects           #
Don't Send Redirections
echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects         #
Don't Accept Redirections
echo "1" > /proc/sys/net/ipv4/tcp_syncookies                    #
Prevent DOS Attacks
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts       #
Ignore Echo Requests


### Default Policies ###
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -N bad_tcp_packets
$IPTABLES -N tcp_packets
$IPTABLES -N tcp_filtered_packets
$IPTABLES -N udp_packets
$IPTABLES -N icmp_packets
$IPTABLES -N rbl_packets
$IPTABLES -N tcp_allowed

### Accepting our servers INPUT RULES###
# Source Addressing #

$IPTABLES -A INPUT -p ALL -s $LO_IP -j ACCEPT
$IPTABLES -A INPUT -p ALL -s $LOCAL_NETWORK_IP_RANGE -j ACCEPT


# Destination Addressing #
$IPTABLES -A INPUT -p ALL -d $LOCAL_NETWORK_IP_RANGE  -m state --state
ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -p ALL -d $EXT_146_IP -m state --state
ESTABLISHED,RELATED -j ACCEPT

### Accepting our servers OUTPUT RULES###
$IPTABLES -A OUTPUT -p ALL -s $LOCAL_NETWORK_IP_RANGE -m state --state
NEW,ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s $EXT_146_IP -m state --state
NEW,ESTABLISHED,RELATED -j ACCEPT

### Linking the chains ###
$IPTABLES -A INPUT -p TCP -j tcp_filtered_packets
$IPTABLES -A INPUT -p TCP -j rbl_packets
$IPTABLES -A INPUT -p TCP -j tcp_packets
$IPTABLES -A INPUT -p UDP  -j udp_packets
$IPTABLES -A INPUT -p ICMP -j icmp_packets

### bad_tcp_packet chain ###

#$IPTABLES -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK -m
state --state NEW -j REJECT --reject-with tcp-reset
#$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j
LOG --log-prefix "New not syn:"
#$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j ACCEPT


### Allow Chain ###

$IPTABLES -A tcp_allowed -p TCP --syn -j ACCEPT
$IPTABLES -A tcp_allowed -p TCP -m state --state
NEW,ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A tcp_allowed -p TCP -j DROP

### TCP Filtered Packets ###

### TCP tcp_allowed Packets ###
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 20 -j ACCEPT
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 21 -j ACCEPT
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 25 -j ACCEPT
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 80 -j ACCEPT
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 110 -j ACCEPT
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 443 -j ACCEPT
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 444 -j ACCEPT
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 10000 -j ACCEPT
$IPTABLES -A tcp_packets -p TCP -j DROP

### ICMP tcp_allowed Packets ###

$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 0 -j ACCEPT
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 3 -j ACCEPT
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT
$IPTABLES -A icmp_packets -p ICMP -j DROP


# Hyperion #

$IPTABLES -A FORWARD -p TCP -s 0/0 -d $HYPERION_LO_IP --dport 20 -j ACCEPT
$IPTABLES -A FORWARD -p TCP -s 0/0 -d $HYPERION_LO_IP --dport 21 -j ACCEPT
$IPTABLES -A FORWARD -p TCP -s 0/0 -d $HYPERION_LO_IP --dport 80 -j ACCEPT
$IPTABLES -A FORWARD -p TCP -s 0/0 -d $HYPERION_LO_IP --dport 443 -j ACCEPT
$IPTABLES -A FORWARD -p TCP -s 0/0 -d $HYPERION_LO_IP --dport 444 -j ACCEPT
$IPTABLES -A FORWARD -p TCP -s 0/0 -d $HYPERION_LO_IP --dport 3306 -j ACCEPT
$IPTABLES -A FORWARD -p TCP -s $HYPERION_LO_IP -d 0/0 -j ACCEPT


# Default Rule #
$IPTABLES -A FORWARD -p TCP -j DROP

### Bad Output Packets ###
$IPTABLES -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s $LOCAL_NETWORK_IP_RANGE -d 0/0 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets

# END RULES
########################################################

# START NATTING
########################################################


### Drop Rootshell Connections ###
$IPTABLES -t nat -A PREROUTING -p tcp -i eth0 --dport 1524 -j DROP

### Forwarding to $HYPERION_LO_IP ###
$IPTABLES -t nat -A PREROUTING -d $EXT_146_IP -p tcp --dport 20 -j
DNAT --to-dest $HYPERION_LO_IP:20
$IPTABLES -t nat -A PREROUTING -d $EXT_146_IP -p tcp --dport 21 -j
DNAT --to-dest $HYPERION_LO_IP:21
$IPTABLES -t nat -A PREROUTING -d $EXT_146_IP -p tcp --dport 80 -j
DNAT --to-dest $HYPERION_LO_IP:80
$IPTABLES -t nat -A PREROUTING -d $EXT_146_IP -p tcp --dport 443 -j
DNAT --to-dest $HYPERION_LO_IP:443
$IPTABLES -t nat -A PREROUTING -d $EXT_146_IP -p tcp --dport 444 -j
DNAT --to-dest $HYPERION_LO_IP:444
$IPTABLES -t nat -A PREROUTING -d $EXT_146_IP -p tcp --dport 3306 -j
DNAT --to-dest $LINUXWEB1_LO_IP:3306

$IPTABLES -t nat -A POSTROUTING -s 192.168.0.0/24 -d 0/0 -j MASQUERADE


# END NATTING
########################################################

-----------------------------------------------------------------------------


ftp_conntrack and ip_nat_ftp is built into the kernel (from what i can
tell) (kernel-2.6.11)

What am I missing, because this is seriously starting to annoy me, i
cant find anything wrong, even if i setup a simple DNAT for ftp, with
no filtering or anything, it transfers a few files, and then bombs out
:(


thanks
Dave

Re: ftp conntrack - nat problem

[/dev/rob0]

On Tuesday 2005-November-08 01:03, Dave Strydom wrote:
>     Active Help: http://www.smartftp.com/support/kb/index.php/74
>     Client closed the connection.
>     Transfer failed.
> ===
>
> And just dies there.
> Now if I use ACTIVE MODE (PORT) i get the same thing... my question
> is why?

I don't know. I'm not convinced it's a netfilter issue, though. I did 
not try to follow your script. Perhaps if you post your rules 
(iptables-save(8)) we could see if anything looks wrong. Please note 
that you didn't describe where you were sitting when you got this 
error, so we could not possibly guess what is happening. I imagine that 
this "smartftp" is some kind of Windows thing, so it probably was not 
running on the firewall?

> Here is a copy of my firewall script:

Did you write all this yourself?

> ### Accepting our servers OUTPUT RULES###
> $IPTABLES -A OUTPUT -p ALL -s $LOCAL_NETWORK_IP_RANGE -m state
> --state NEW,ESTABLISHED,RELATED -j ACCEPT

Above you had:
> $IPTABLES -P OUTPUT ACCEPT
so why are you adding ACCEPT rules to OUTPUT?

> ### Drop Rootshell Connections ###
> $IPTABLES -t nat -A PREROUTING -p tcp -i eth0 --dport 1524 -j DROP

This is not appropriate in the nat table.

> ftp_conntrack and ip_nat_ftp is built into the kernel (from what i
> can tell) (kernel-2.6.11)

"From what [you] can tell?" You would know more about it than we would. 
Also, netfilter drivers really should not be built-in unless it's an 
embedded device which should reboot to make any changes.

> What am I missing, because this is seriously starting to annoy me,
> i cant find anything wrong,

Nor can I. It could be many things.

> even if i setup a simple DNAT for ftp, with no filtering or
> anything, it transfers a few files, and then bombs out

This suggests that the problem is not netfilter at all, but yes, more 
simple iptables rules would help in ruling it out.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: ftp conntrack - nat problem

[Dave Strydom]

Ok, I have setup a test setup which is doing the same thing, here is
the output of my iptables-save:


===================================
Calypso ~ # iptables-save
# Generated by iptables-save v1.2.11 on Wed Nov  9 13:26:17 2005
*raw
:PREROUTING ACCEPT [145071395:67094999750]
:OUTPUT ACCEPT [97318433:51529211890]
COMMIT
# Completed on Wed Nov  9 13:26:17 2005
# Generated by iptables-save v1.2.11 on Wed Nov  9 13:26:17 2005
*nat
:PREROUTING ACCEPT [90:6706]
:POSTROUTING ACCEPT [69:5701]
:OUTPUT ACCEPT [91:6487]
-A PREROUTING -d 209.212.xxx.xxx -p tcp -m tcp --dport 20 -j DNAT
--to-destination 192.168.0.220:20
-A PREROUTING -d 209.212.xxx.xxx -p tcp -m tcp --dport 21 -j DNAT
--to-destination 192.168.0.220:21
-A POSTROUTING -s 192.168.0.0/255.255.255.0 -j MASQUERADE
COMMIT
# Completed on Wed Nov  9 13:26:17 2005
# Generated by iptables-save v1.2.11 on Wed Nov  9 13:26:17 2005
*mangle
:PREROUTING ACCEPT [650:323498]
:INPUT ACCEPT [567:316916]
:FORWARD ACCEPT [10:2047]
:OUTPUT ACCEPT [606:234459]
:POSTROUTING ACCEPT [616:236506]
COMMIT
# Completed on Wed Nov  9 13:26:17 2005
# Generated by iptables-save v1.2.11 on Wed Nov  9 13:26:17 2005
*filter
:INPUT ACCEPT [2:246]
:FORWARD ACCEPT [6:1109]
:OUTPUT ACCEPT [44:16200]
:bad_tcp_packets - [0:0]
:icmp_packets - [0:0]
:rbl_packets - [0:0]
:tcp_allowed - [0:0]
:tcp_filtered_packets - [0:0]
:tcp_packets - [0:0]
:udp_packets - [0:0]
-A INPUT -s 127.0.0.1 -j ACCEPT
-A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT
-A INPUT -d 192.168.0.0/255.255.255.0 -m state --state
NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -d 209.212.xxx.xxx -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -j tcp_filtered_packets
-A INPUT -p tcp -j rbl_packets
-A INPUT -p tcp -j tcp_packets
-A INPUT -p udp -j udp_packets
-A INPUT -p icmp -j icmp_packets
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -j DROP
-A FORWARD -p tcp -m tcp --dport 20 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 21 -j ACCEPT
-A FORWARD -s 192.168.0.220 -p tcp -j ACCEPT
-A OUTPUT -s 192.168.0.0/255.255.255.0 -m state --state
NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -s 209.212.xxx.xxx -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A udp_packets -p udp -m udp --dport 53 -j ACCEPT
-A udp_packets -s 196.36.10.xxx -p udp -j ACCEPT
-A udp_packets -p udp -j ACCEPT
COMMIT
# Completed on Wed Nov  9 13:26:17 2005
Calypso ~ #
===================================

And here is the output of my tethereal:

=================================
 25.628044 196.41.xxx.xxx -> 209.212.xxx.xxx FTP Request: SIZE LANDING_15.jpg
 25.628282 209.212.xxx.xxx -> 196.41.xxx.xxx FTP Response: 550
LANDING_15.jpg: No such file or directory
 25.676900 196.41.xxx.xxx -> 209.212.xxx.xxx FTP Request: PASV
 25.677159 209.212.xxx.xxx -> 196.41.xxx.xxx FTP Response: 227
Entering Passive Mode (209,212,112,162,135,189).
 25.733362 196.41.xxx.xxx -> 209.212.xxx.xxx TCP 4419 > 34749 [SYN]
Seq=0 Ack=0 Win=16384 Len=0 MSS=1360
 25.733465 209.212.xxx.xxx -> 196.41.xxx.xxx TCP 34749 > 4419 [SYN,
ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
 25.743650 196.41.xxx.xxx -> 209.212.xxx.xxx FTP Request: STOR LANDING_15.jpg
 25.752877 196.41.xxx.xxx -> 209.212.xxx.xxx TCP 4419 > 34749 [ACK]
Seq=1 Ack=1 Win=17680 Len=0
 25.753020 209.212.xxx.xxx -> 196.41.xxx.xxx FTP Response: 150 Opening
BINARY mode data connection for LANDING_15.jpg
 25.840307 196.41.xxx.xxx -> 209.212.xxx.xxx FTP-DATA FTP Data: 1360 bytes
 25.840552 209.212.xxx.xxx -> 196.41.xxx.xxx TCP 34749 > 4419 [ACK]
Seq=1 Ack=1361 Win=8160 Len=0
 25.847856 196.41.xxx.xxx -> 209.212.xxx.xxx FTP-DATA FTP Data: 257 bytes
 25.847869 196.41.xxx.xxx -> 209.212.xxx.xxx TCP 4419 > 34749 [FIN,
ACK] Seq=1618 Ack=1 Win=17680 Len=0
 25.847964 209.212.xxx.xxx -> 196.41.xxx.xxx TCP 34749 > 4419 [ACK]
Seq=1 Ack=1618 Win=8160 Len=0
 25.848092 209.212.xxx.xxx -> 196.41.xxx.xxx TCP 34749 > 4419 [FIN,
ACK] Seq=1 Ack=1619 Win=8160 Len=0
 25.848497 209.212.xxx.xxx -> 196.41.xxx.xxx FTP Response: 226
Transfer complete.
 25.870373 196.41.xxx.xxx -> 209.212.xxx.xxx TCP 4419 > 34749 [ACK]
Seq=1619 Ack=2 Win=17680 Len=0
 25.874183 196.41.xxx.xxx -> 209.212.xxx.xxx TCP 4391 > ftp [ACK]
Seq=1785 Ack=5525 Win=17680 Len=0
 25.910130 196.41.xxx.xxx -> 209.212.xxx.xxx FTP Request: SIZE LANDING_15.jpg
 25.910382 209.212.xxx.xxx -> 196.41.xxx.xxx FTP Response: 213 1617
 26.034473 196.41.xxx.xxx -> 209.212.xxx.xxx FTP Request: SIZE LANDING_16.jpg
 26.034723 209.212.xxx.xxx -> 196.41.xxx.xxx FTP Response: 550
LANDING_16.jpg: No such file or directory
 26.174579 196.41.xxx.xxx -> 209.212.xxx.xxx FTP Request: PASV
 26.174852 209.212.xxx.xxx -> 196.41.xxx.xxx FTP Response: 227
Entering Passive Mode (209,212,112,162,135,190).
 26.264491 196.41.xxx.xxx -> 209.212.xxx.xxx TCP 4420 > 34750 [SYN]
Seq=0 Ack=0 Win=16384 Len=0 MSS=1360
 26.264623 209.212.xxx.xxx -> 196.41.xxx.xxx TCP 34750 > 4420 [SYN,
ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
 26.304471 196.41.xxx.xxx -> 209.212.xxx.xxx FTP Request: STOR LANDING_16.jpg
 26.344573 196.41.xxx.xxx -> 209.212.xxx.xxx TCP 4420 > 34750 [ACK]
Seq=1 Ack=1 Win=17680 Len=0
 26.344727 209.212.xxx.xxx -> 196.41.xxx.xxx FTP [TCP Out-Of-Order]
Response: 150 Opening BINARY mode data connection for LANDING_16.jpg
 26.512422 196.41.xxx.xxx -> 209.212.xxx.xxx TCP 4391 > ftp [ACK]
Seq=1854 Ack=5694 Win=17511 Len=0
 26.646760 209.212.xxx.xxx -> 196.41.xxx.xxx FTP [TCP Previous segment
lost] Response:
 26.822581 196.41.xxx.xxx -> 209.212.xxx.xxx TCP 4391 > ftp [ACK]
Seq=1854 Ack=5696 Win=17509 Len=0
=================================

What I do notice is this:

FTP [TCP Out-Of-Order] Response: 150 Opening BINARY mode data
connection for LANDING_16.jpg
and
FTP [TCP Previous segment lost] Response:

I hope this makes sense to someone...

thanks
Dave

Re: ftp conntrack - nat problem

[Dave Strydom]

Ok, I have just compiled a new kernel on this box, and compiled all
iptables things as modules... same problem... I have also removed all
PAX and GRsecurity stuff just to write those out of the equation.

-----------------------------------------
Calypso firewall # lsmod
Module                  Size  Used by
iptable_filter          3200  1
ipt_MARK                2688  0
ipt_NETMAP              2432  0
iptable_mangle          3072  0
ipt_ttl                 2176  0
ipt_tos                 1792  0
ipt_tcpmss              2560  0
ipt_state               2176  4
ipt_geoip               4356  0
ipt_conntrack           2688  0
ipt_connmark            1920  0
ipt_SAME                2944  0
ipt_LOG                 7424  0
ipt_CONNMARK            2432  0
ipt_REJECT              6784  0
ipt_MASQUERADE          4744  1
ip_nat_snmp_basic      11908  0
ip_nat_ftp              3328  0
iptable_nat            26460  5 ipt_NETMAP,ipt_SAME,ipt_MASQUERADE,ip_nat_ftp
ip_queue               11800  0
ip_tables              25600  17
iptable_filter,ipt_MARK,ipt_NETMAP,iptable_mangle,ipt_ttl,ipt_tos,ipt_tcpmss,ipt_state,ipt_geoip,ipt_conntrack,ipt_connmark,ipt_SAME,ipt_LOG,ipt_CONNMARK,ipt_REJECT,ipt_MASQUERADE,iptable_nat
ip_conntrack_ftp       73488  1 ip_nat_ftp
ip_conntrack           54592  7
ipt_state,ipt_conntrack,ipt_MASQUERADE,ip_nat_snmp_basic,ip_nat_ftp,iptable_nat,ip_conntrack_ftp
Calypso firewall #

-----------------------------------------

I'm at a serious loss here, i dont know what else to do :(

Dave

================================

On 11/9/05, Dave Strydom <strydom.dave@gmail.com> wrote:
> Ok, I have setup a test setup which is doing the same thing, here is
> the output of my iptables-save:
>
>

Re: ftp conntrack - nat problem

[/dev/rob0]

On Wednesday 2005-November-09 05:31, Dave Strydom wrote:
> -A PREROUTING -d 209.212.xxx.xxx -p tcp -m tcp --dport 20 -j DNAT
> --to-destination 192.168.0.220:20
> -A PREROUTING -d 209.212.xxx.xxx -p tcp -m tcp --dport 21 -j DNAT
> --to-destination 192.168.0.220:21

If you're running an FTP server behind NAT, you would only DNAT 21. 
Ftp-data (tcp/20) is used for outgoing connections to the client. I 
doubt this is your problem, though. Nothing will match that rule unless 
you're connecting an FTP client on the firewall to a remote site.

> -A POSTROUTING -s 192.168.0.0/255.255.255.0 -j MASQUERADE

In general if you have a static IP (as in "not changing ever", not "you 
pay the ISP more and get custom rDNS") the SNAT target is better.

> *filter
>
> :INPUT ACCEPT [2:246]
> :FORWARD ACCEPT [6:1109]

ACCEPT policies can be fine, but you generally should have rules to 
REJECT or DROP the traffic you don't want.

> :OUTPUT ACCEPT [44:16200]
> :bad_tcp_packets - [0:0]
> :icmp_packets - [0:0]
> :rbl_packets - [0:0]
> :tcp_allowed - [0:0]
> :tcp_filtered_packets - [0:0]
> :tcp_packets - [0:0]
> :udp_packets - [0:0]
>
> -A INPUT -s 127.0.0.1 -j ACCEPT

First rule? Maybe "-i lo", but not "-s 127.0.0.1". An attacker could 
route packets to you which claim to have a source address of 127.0.0.1, 
and you're accepting them.

It's a minor weakness, but perhaps it can help you understand the 
difference between specifying an input interface ("lo" is always 
secure, at least insofar as you trust your own users) or a source IP 
address. Packet headers can be spoofed! But outsiders can only come in 
on your external interface.

> -A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT

Same issue here. Packets claiming to be from your LAN are accepted.

> -A INPUT -d 192.168.0.0/255.255.255.0 -m state --state
> NEW,RELATED,ESTABLISHED -j ACCEPT

Huh? This looks like it might belong in FORWARD. But "-d"? What did you 
think this rule would do?

> -A INPUT -d 209.212.xxx.xxx -m state --state RELATED,ESTABLISHED -j
> ACCEPT

I will assume 209.212.xxx.xxx is this machine's external IP. Please be 
explicit when you are munging information.

This rule means that your firewall machine gets replies to the 
connections it initiates.

> -A INPUT -p tcp -j tcp_filtered_packets 
> -A INPUT -p tcp -j rbl_packets
> -A INPUT -p tcp -j tcp_packets
> -A INPUT -p udp -j udp_packets
> -A INPUT -p icmp -j icmp_packets

> -A INPUT -p tcp -m tcp --dport 20 -j ACCEPT

Why? See above about ftp-data.

> -A INPUT -p tcp -m tcp --dport 21 -j ACCEPT

You have DNAT'ed port 21 above. This rule won't be matched.

> -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

This machine is running public SMTP, HTTP and HTTPS servers.

> -A INPUT -p tcp -j DROP

This overrides the default ACCEPT policy but only for TCP.

> -A FORWARD -p tcp -m tcp --dport 20 -j ACCEPT
> -A FORWARD -p tcp -m tcp --dport 21 -j ACCEPT

These should ensure the NAT'ed FTP server is accessible from outside.

> -A FORWARD -s 192.168.0.220 -p tcp -j ACCEPT

And any TCP connections from that machine are allowed.

> -A OUTPUT -s 192.168.0.0/255.255.255.0 -m state --state
> NEW,RELATED,ESTABLISHED -j ACCEPT
> -A OUTPUT -s 209.212.xxx.xxx -m state --state NEW,RELATED,ESTABLISHED
> -j ACCEPT

Explained yesterday why this is pointless.

> -A udp_packets -p udp -m udp --dport 53 -j ACCEPT 
> -A udp_packets -s 196.36.10.xxx -p udp -j ACCEPT
> -A udp_packets -p udp -j ACCEPT

This is jumped to from INPUT, and all it does is ACCEPT, which is the 
same as your default policy.

> COMMIT

The other chains you defined are not used!

> And here is the output of my tethereal:
snip
> What I do notice is this:
>
> FTP [TCP Out-Of-Order] Response: 150 Opening BINARY mode data
> connection for LANDING_16.jpg
> and
> FTP [TCP Previous segment lost] Response:

Yes, I would guess that is the problem, but I don't know what would 
cause it. Again from yesterday, I doubt it's a netfilter issue.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

SNAT vs MASQUERADE ... RE: ftp conntrack - nat problem

[Pablo Sanchez]

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org
> [mailto:netfilter-bounces@lists.netfilter.org]On Behalf Of /dev/rob0
> Sent: Wednesday, November 09, 2005 10:18 AM
> To: netfilter@lists.netfilter.org
> Subject: Re: ftp conntrack - nat problem
> 
> In general if you have a static IP (as in "not changing ever", not "you 
> pay the ISP more and get custom rDNS") the SNAT target is better.

Hi Rob,

When you say the SNAT target is better.  Can you quantify 'better?'  Are there any functional limitations overcome by SNAT over the MASQUERADE target?

Cheers,
-pablo

Re: ftp conntrack - nat problem

[Dave Strydom]

After trying this for a while and watching the tethereal output i have
noticed something:

a Successful upload:

=======
 37.406692 196.41.186.226 -> 192.168.0.220 FTP Request: PASV
 37.406913 192.168.0.220 -> 196.41.186.226 FTP Response: 227 Entering
Passive Mode (192,168,0,220,137,132).
 37.455288 196.41.186.226 -> 192.168.0.220 TCP ms-sql-s > 35204 [SYN]
Seq=0 Ack=0 Win=16384 Len=0 MSS=1360
 37.455310 192.168.0.220 -> 196.41.186.226 TCP 35204 > ms-sql-s [SYN,
ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
 37.465549 196.41.186.226 -> 192.168.0.220 FTP Request: STOR LANDING_17.jpg
 37.490491 196.41.186.226 -> 192.168.0.220 TCP ms-sql-s > 35204 [ACK]
Seq=1 Ack=1 Win=17680 Len=0
 37.490618 192.168.0.220 -> 196.41.186.226 FTP Response: 150 Opening
BINARY mode data connection for LANDING_17.jpg
 37.664991 196.41.186.226 -> 192.168.0.220 FTP-DATA FTP Data: 1360 bytes
 37.665008 192.168.0.220 -> 196.41.186.226 TCP 35204 > ms-sql-s [ACK]
Seq=1 Ack=1361 Win=8160 Len=0
 37.670007 196.41.186.226 -> 192.168.0.220 FTP-DATA FTP Data: 305 bytes
 37.670020 192.168.0.220 -> 196.41.186.226 TCP 35204 > ms-sql-s [ACK]
Seq=1 Ack=1666 Win=8160 Len=0
 37.675092 196.41.186.226 -> 192.168.0.220 TCP ms-sql-s > 35204 [FIN,
ACK] Seq=1666 Ack=1 Win=17680 Len=0
 37.675222 192.168.0.220 -> 196.41.186.226 TCP 35204 > ms-sql-s [FIN,
ACK] Seq=1 Ack=1667 Win=8160 Len=0
 37.675713 192.168.0.220 -> 196.41.186.226 FTP Response: 226 Transfer complete.
=======

A Unsuccessful upload:

=======
37.921391 196.41.186.226 -> 192.168.0.220 FTP Request: PASV
 37.921611 192.168.0.220 -> 196.41.186.226 FTP Response: 227 Entering
Passive Mode (192,168,0,220,137,133).
 37.961478 196.41.186.226 -> 192.168.0.220 TCP ms-sql-m > 35205 [SYN]
Seq=0 Ack=0 Win=16384 Len=0 MSS=1360
 37.961501 192.168.0.220 -> 196.41.186.226 TCP 35205 > ms-sql-m [SYN,
ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
 37.967146 196.41.186.226 -> 192.168.0.220 FTP Request: STOR LANDING_18.jpg
 37.982217 196.41.186.226 -> 192.168.0.220 TCP ms-sql-m > 35205 [ACK]
Seq=1 Ack=1 Win=17680 Len=0
 37.982349 192.168.0.220 -> 196.41.186.226 FTP Response: 150 Opening
BINARY mode data connection for LANDING_18.jpg
 38.189397 196.41.186.226 -> 192.168.0.220 TCP 1407 > ftp [ACK]
Seq=2306 Ack=6579 Win=16535 Len=0
 38.309509 192.168.0.220 -> 196.41.186.226 FTP [TCP Out-Of-Order] Response:
 38.493193 196.41.186.226 -> 192.168.0.220 TCP 1407 > ftp [ACK]
Seq=2306 Ack=6581 Win=16533 Len=0
 53.301514 196.41.186.226 -> 192.168.0.220 TCP 1407 > ftp [FIN, ACK]
Seq=2306 Ack=6581 Win=16533 Len=0
=======

If you check the first one, it Opens the BINARY connection and the you
have a FTP-DATA command which gives it the file size

in the 2nd one, it Opens the Binary connection and there is no FTP-DATA issued?

Re: ftp conntrack - nat problem

[Dave Strydom]

Ok, so this is what it has all been reduced to, and I'm still getting
the same problem:

===============
Calypso ~ # iptables-save
# Generated by iptables-save v1.3.2 on Wed Nov  9 17:39:58 2005
*filter
:INPUT ACCEPT [56:29177]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [342:312699]
-A INPUT -s 127.0.0.1 -j ACCEPT
-A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT
-A FORWARD -d 192.168.0.0/255.255.255.0 -m state --state
NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.0.0/255.255.255.0 -j ACCEPT
COMMIT
# Completed on Wed Nov  9 17:39:58 2005
# Generated by iptables-save v1.3.2 on Wed Nov  9 17:39:58 2005
*mangle
:PREROUTING ACCEPT [423:64196]
:INPUT ACCEPT [284:54362]
:FORWARD ACCEPT [20:3170]
:OUTPUT ACCEPT [391:326702]
:POSTROUTING ACCEPT [411:329872]
COMMIT
# Completed on Wed Nov  9 17:39:58 2005
# Generated by iptables-save v1.3.2 on Wed Nov  9 17:39:58 2005
*nat
:PREROUTING ACCEPT [136:9143]
:POSTROUTING ACCEPT [17:1649]
:OUTPUT ACCEPT [22:1499]
-A PREROUTING -d 209.212.112.162 -p tcp -m tcp --dport 21 -j DNAT
--to-destination 192.168.0.220:21
-A POSTROUTING -s 192.168.0.0/255.255.255.0 -j MASQUERADE
COMMIT
# Completed on Wed Nov  9 17:39:58 2005
Calypso ~ #
===============

Eish :(

Re: SNAT vs MASQUERADE ... RE: ftp conntrack - nat problem

[/dev/rob0]

On Wednesday 2005-November-09 09:23, Pablo Sanchez wrote:
> When you say the SNAT target is better.  Can you quantify 'better?' 
> Are there any functional limitations overcome by SNAT over the
> MASQUERADE target?

Ooooh, I was afraid someone might ask that. Unfortunately I am only 
parroting the party line. From "MASQUERADE" in "man iptables":
  MASQUERADE
       This target is only valid in the nat table, in the POSTROUTING
       chain.  It  should  only  be used with dynamically assigned IP
       (dialup)  connections:  if you have a static IP  address,  you
       should use the SNAT target.

Perhaps someone else can explain why. I think one benefit of SNAT is 
that a SNAT'ed TCP connection can survive a router reset. That's 
important to me, because sometimes I leave ssh sessions open for weeks 
at a time.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: ftp conntrack - nat problem

[/dev/rob0]

On Wednesday 2005-November-09 09:40, Dave Strydom wrote:
> Ok, so this is what it has all been reduced to, and I'm still
> getting the same problem:

What more can I say?

> Calypso ~ # iptables-save

This is like not having a firewall at all. The only functional part is 
the NAT, DNAT FTP inbound, MASQUERADE LAN clients outbound.

Not having a firewall is not necessarily a disaster, BTW. A properly 
configured system should still be safe without it.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: ftp conntrack - nat problem

[Dave Strydom]

So if it isnt the firewall, then what on earth could it be?

Because from the tethereal output, you can see that FTP-DATA isnt
being sent, any idea of what could cause this?

If i remove the nat, and ftp things direct the firewall it works fine,
it's only if I nat stuff to a ftp behind the firewall.


----------------------------------
On 11/9/05, /dev/rob0 <rob0@gmx.co.uk> wrote:
> On Wednesday 2005-November-09 09:40, Dave Strydom wrote:
> > Ok, so this is what it has all been reduced to, and I'm still
> > getting the same problem:
>
> What more can I say?
>
> > Calypso ~ # iptables-save
>
> This is like not having a firewall at all. The only functional part is
> the NAT, DNAT FTP inbound, MASQUERADE LAN clients outbound.
>
> Not having a firewall is not necessarily a disaster, BTW. A properly
> configured system should still be safe without it.
> --
>     mail to this address is discarded unless "/dev/rob0"
>     or "not-spam" is in Subject: header
>
>

RE: SNAT vs MASQUERADE ... RE: ftp conntrack - nat problem

[Pablo Sanchez]

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org
> [mailto:netfilter-bounces@lists.netfilter.org]On Behalf Of /dev/rob0
> Sent: Wednesday, November 09, 2005 10:52 AM
> To: netfilter@lists.netfilter.org
> Subject: Re: SNAT vs MASQUERADE ... RE: ftp conntrack - nat problem
> 
> 
> On Wednesday 2005-November-09 09:23, Pablo Sanchez wrote:
> > When you say the SNAT target is better.  Can you quantify 'better?' 
> > Are there any functional limitations overcome by SNAT over the
> > MASQUERADE target?
> 
> Ooooh, I was afraid someone might ask that. 

:)

> I think one benefit of SNAT is 
> that a SNAT'ed TCP connection can survive a router reset. That's 
> important to me, because sometimes I leave ssh sessions open for weeks 
> at a time.

I just switched from the SNAT to the MASQUERADE target and so far (knock on wood - my head in this case!) I haven't seen an issue with router resets.

I'm very curious to know if there are any differences (aside from knowing the IP ahead of time versus not).

Cheers,
-pablo

Re: ftp conntrack - nat problem

[Dave Strydom]

woohoo I found the problem.


in the proftpd.conf on the server behind the firewall you need to add
something like this to the proftpd.conf file:

---
MasqueradeAddress         209.212.xxx.xxx
PassivePorts                    60000 65535
---

then in the iptables:

$IPTABLES -t nat -A PREROUTING -d 209.212.xxx.xxx -p tcp --dport
60000:65535 -j DNAT --to-dest 192.168.0.xxx


Now it's working perfectly.

Dave

RE: SNAT vs MASQUERADE

[Pablo Sanchez]

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org
> [mailto:netfilter-bounces@lists.netfilter.org]On Behalf Of /dev/rob0
> Sent: Wednesday, November 09, 2005 10:52 AM
> To: netfilter@lists.netfilter.org
> Subject: Re: SNAT vs MASQUERADE ... RE: ftp conntrack - nat problem
> 
> 
> On Wednesday 2005-November-09 09:23, Pablo Sanchez wrote:
> > When you say the SNAT target is better.  Can you quantify 'better?' 
> > Are there any functional limitations overcome by SNAT over the
> > MASQUERADE target?
> 
> Ooooh, I was afraid someone might ask that. Unfortunately I am only 
> parroting the party line.

Hi,

I discovered a case where SNAT'ing is necessary over the MASQUERADE target.  

I have an environment where I'm peering and I send traffic via one IP (when my primary ISP is down and they're providing backup) and they send me traffic via another IP (when they're down and I'm providing backup).  The IP's are associated with one interface so I assign one IP to the NIC's if-cfg file and I IP alias the second IP.

Pictorially, here's what I have:

           DSL               DSL
            |                 |
       [ router A ]<---->[ router B ]
        172.16.1.x         10.1.1.x

When [A] is failed over to [B], [A]'s routing table looks like so:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.1.101      0.0.0.0         255.255.255.255 UH    0      0        0 eth2 <-- IP alias
172.16.1.128    0.0.0.0         255.255.255.252 U     0      0        0 eth2 <-- ifcfg'd
172.32.1.0      0.0.0.0         255.255.255.248 U     0      0        0 eth1
172.16.1.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         10.1.1.101      0.0.0.0         UG    0      0        0 eth2

On [A], here are how the IP's are assigned to 'eth2':

ip addr show dev eth2
4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc tbf qlen 3
    link/ether 00:09:5b:1a:82:72 brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.129/30 brd 172.16.1.131 scope global eth2
    inet 10.1.1.105/32 scope global eth2
    inet6 fe80::209:5bff:fe1a:8272/64 scope link 
       valid_lft forever preferred_lft forever

What I have found is when I use the MASQUERADE target, [B] sees the traffic as if it came via IP 172.16.1.129.

If I SNAT to 10.1.1.105, then the traffic comes to [B] looks like it's coming from 10.1.1.105

I thought intuitively, since I had defaulted the gateway to 10.1.1.101, [B] would see the traffic originating from 10.1.1.105.

Funky eh?  Perhaps I don't fully understand the underpinnings of the MASQUERADE target however it seems it picks the IP based on the ifcfg value, not the value of how traffic is being directed (via a default gateway).

Cheers,
---
Pablo Sanchez - Blueoak Database Engineering, Inc
Ph:    819.459.1926          Toll free:  888.459.1926
Cell:  819.664.9118                Pgr:  pablo_p@blueoakdb.com
Fax:   603.720.7723 (US)           Fax:  514.371.1255 (Canada)

Re: SNAT vs MASQUERADE

[Alexander Samad]

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

On Thu, Nov 10, 2005 at 10:05:24PM -0500, Pablo Sanchez wrote:
> 
> 
> > -----Original Message-----
> > From: netfilter-bounces@lists.netfilter.org
> > [mailto:netfilter-bounces@lists.netfilter.org]On Behalf Of /dev/rob0
> > Sent: Wednesday, November 09, 2005 10:52 AM
> > To: netfilter@lists.netfilter.org
> > Subject: Re: SNAT vs MASQUERADE ... RE: ftp conntrack - nat problem
> > 
> > 
> > On Wednesday 2005-November-09 09:23, Pablo Sanchez wrote:
> > > When you say the SNAT target is better.  Can you quantify 'better?' 
> > > Are there any functional limitations overcome by SNAT over the
> > > MASQUERADE target?
> > 
> > Ooooh, I was afraid someone might ask that. Unfortunately I am only 
> > parroting the party line.
> 
> Hi,
> 
> I discovered a case where SNAT'ing is necessary over the MASQUERADE target.  
> 
> I have an environment where I'm peering and I send traffic via one IP (when my primary ISP is down and they're providing backup) and they send me traffic via another IP (when they're down and I'm providing backup).  The IP's are associated with one interface so I assign one IP to the NIC's if-cfg file and I IP alias the second IP.
> 
> Pictorially, here's what I have:
> 
>            DSL               DSL
>             |                 |
>        [ router A ]<---->[ router B ]
>         172.16.1.x         10.1.1.x
> 
> When [A] is failed over to [B], [A]'s routing table looks like so:
> 
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 10.1.1.101      0.0.0.0         255.255.255.255 UH    0      0        0 eth2 <-- IP alias
> 172.16.1.128    0.0.0.0         255.255.255.252 U     0      0        0 eth2 <-- ifcfg'd
> 172.32.1.0      0.0.0.0         255.255.255.248 U     0      0        0 eth1
> 172.16.1.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
> 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
> 0.0.0.0         10.1.1.101      0.0.0.0         UG    0      0        0 eth2
> 
> On [A], here are how the IP's are assigned to 'eth2':
> 
> ip addr show dev eth2
> 4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc tbf qlen 3
>     link/ether 00:09:5b:1a:82:72 brd ff:ff:ff:ff:ff:ff
>     inet 172.16.1.129/30 brd 172.16.1.131 scope global eth2
>     inet 10.1.1.105/32 scope global eth2
>     inet6 fe80::209:5bff:fe1a:8272/64 scope link 
>        valid_lft forever preferred_lft forever
> 
> What I have found is when I use the MASQUERADE target, [B] sees the traffic as if it came via IP 172.16.1.129.
> 
> If I SNAT to 10.1.1.105, then the traffic comes to [B] looks like it's coming from 10.1.1.105
> 
> I thought intuitively, since I had defaulted the gateway to 10.1.1.101, [B] would see the traffic originating from 10.1.1.105.
> 
> Funky eh?  Perhaps I don't fully understand the underpinnings of the MASQUERADE target however it seems it picks the IP based on the ifcfg value, not the value of how traffic is being directed (via a default gateway).

There was a thread on this earlier, MASQ looks at the IP addresses early
in the route disission process and picks the first one that meets the
criteria.....  or something along those lines

> 
> Cheers,
> ---
> Pablo Sanchez - Blueoak Database Engineering, Inc
> Ph:    819.459.1926          Toll free:  888.459.1926
> Cell:  819.664.9118                Pgr:  pablo_p@blueoakdb.com
> Fax:   603.720.7723 (US)           Fax:  514.371.1255 (Canada)
> 
> 
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: SNAT vs MASQUERADE

[Pablo Sanchez]

> I discovered a case where SNAT'ing is necessary over the 
> MASQUERADE target.  
> 
> What I have found is when I use the MASQUERADE target, [B] sees 
> the traffic as if it came via IP 172.16.1.129.

Hi everyone,

Following up on my own post above ... I believe to get around the above issue, you can use the 'SRC' arg to 'ip route add':

	ip route add 172.16.4.0/24 src 172.16.4.2 dev eth0 protocol static

Cheers!
-pablo