I'm working with the tech support of a residential DSL modem vendor on a NAT
issue. The vendor says they use open source in their products and the logs
show all the typical iptables entries.
We're using a DSL modem for OOB management of our DSLAMs. We access the
DSLAM from the internet via the DSL modem's public IP which has been
configured with a DMZ to hit the DSLAM on its private IP. We can access the
DSLAM via telnet and http, there's no problem there.
The problem occurs when we perform a configuration backup of the DSLAM. The
DSLAM has a built-in (DSLAM vendor written?) FTP client that uploads the
configuration to our FTP server. What's unique is that the DSLAM vendor's
FTP client issues each FTP command separately from the closing CRLF
("\r\n"). For example, when the DSLAM logs in it first issues "LOGIN
username" in one packet, and then "\r\n" in the next packet. Attached to
this post is a trace (I removed the login section to protect the user
credentials) where you can see this happening in packets #1 and #3.
According to the DSLAM vendor it shouldn't matter if the FTP client sends
the command character-by-character in separate packets or in one packet.
That's no problem for non-NATed DSLAMs because the FTP server is supposed to
wait for the closing CRLF, but it appears that iptables doesn't handle the
situation well.
The issue crops up for me when the PORT command is sent. The PORT (and
PASV) command require an ALG to accomplish the NAT function because the
internal IP in the payload needs to be changed to the public IP. The ALG
doesn't (and shouldn't) send the PORT command out the WAN interface until
the "\r\n" is received from the FTP client. The LAN interface facing the
FTP client should be ACKing every TCP packet until the "\n" is received and
then process the PORT command and send out complete command out the WAN
interface. But it appears iptables doesn't handle this scenario. An older
post (http://www.kfki.hu/~kadlec/sw/netfilter/ftp_security2.html) suggests
that this is a known issue.
As you can see the attached trace, in packet #7 the PORT command is received
without the CRLF, consistent with this FTP client's behavior. But iptables
doesn't send an ACK so the FTP client resends the packet (packets #8-15).
Can anyone confirm that iptables still behaves this way, and if so, code a
fix so that no matter how many packets a PORT or PASV command are split over
(in other words, no matter how small the client's MTU) that iptables ACKs
each packet received on the LAN side and the ALG properly reassembles the
command and sends it out the WAN interface?
Regards,
Frank
Attachment:
ftp-session-2008-11-14-LAN-side-ftp-partial.pcap
Description: Binary data
