FW: Problem with ftp-proxy -- additional info

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Jason
Date: Friday, September 14, 2007 - 6:14 pm

Hello all,

Ok, here is a sample.  I tried a connection from my workstation 10.0.0.103
to ftp.openbsd.org. 


Firewall's pf.conf
---BEGIN
if_loopback="lo0"	# loopback
if_public="em1"		# connected to public network
if_int="bnx1"		# connected to internal network (10.0.0.0/24)

ip_public="66.181.246.130"
set skip on $if_loopback
#scrub in
#begin NAT Rules
nat on $if_public from $if_int:network to any -> $ip_public
#Handle FTP Clients behind firewall
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
rdr pass on $if_int proto tcp from any to any port 21 -> 127.0.0.1 port 8021
#END NAT Rules

#BEGIN Filter Rules
#block all incoming
block drop in on $if_public
#ftp
anchor "ftp-proxy/*"

#allow all outbound
pass out quick on $if_public keep state

#END Filter Rules
------ END pf.conf


The firewall's experience, as seen from ftp-proxy -d
------
#4 FTP session 1/100 started: client 10.0.0.103 to server 129.128.5.191 via
proxy 66.181.246.130
#4 server: 220-\r\n
#4 server: 220-              Welcome to SunSITE Alberta\r\n
#4 server: 220-\r\n
#4 server: 220-  at the University of Alberta, in Edmonton, Alberta,
Canada\r\n
#4 server: 220-\r\n
#4 server: 220-All connections to and transfers from this server are logged.
If \r\n
#4 server: 220-you do not like this policy, please disconnect now.\r\n
#4 server: 220-\r\n
#4 server: 220-You may want to grab the index file called "ls-lR.gz" in
/pub.  It is \r\n
#4 server: 220-updated nightly with the contents of the ftp tree.  \r\n
#4 server: 220-\r\n
#4 server: 220-    If you have any questions, hints, or requests, please
email\r\n
#4 server: 220-\r\n
#4 server: 220-         sunsite@sunsite.ualberta.ca\r\n
#4 server: 220-\r\n
#4 server: 220 \r\n
#4 client reset connection
#4 ending session

The client experience, as recorded by wireshark:

-------------BEGIN
No.     Time        Source                Destination           Protocol
Info
      1 0.000000    10.0.0.103            129.128.5.191         TCP
4096 > ftp [SYN] Seq=0 Len=0 MSS=1460

Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: AsustekC_64:cd:e6 (00:1b:fc:64:cd:e6), Dst: Dell_ca:4d:de
(00:19:b9:ca:4d:de)
Internet Protocol, Src: 10.0.0.103 (10.0.0.103), Dst: 129.128.5.191
(129.128.5.191)
Transmission Control Protocol, Src Port: 4096 (4096), Dst Port: ftp (21),
Seq: 0, Len: 0
    Source port: 4096 (4096)
    Destination port: ftp (21)
    Sequence number: 0    (relative sequence number)
    Header length: 28 bytes
    Flags: 0x02 (SYN)
    Window size: 65535
    Checksum: 0xa068 [correct]
    Options: (8 bytes)

No.     Time        Source                Destination           Protocol
Info
      2 0.001938    129.128.5.191         10.0.0.103            TCP      ftp

Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: Dell_ca:4d:de (00:19:b9:ca:4d:de), Dst: AsustekC_64:cd:e6
(00:1b:fc:64:cd:e6)
Internet Protocol, Src: 129.128.5.191 (129.128.5.191), Dst: 10.0.0.103
(10.0.0.103)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: 4096 (4096),
Seq: 0, Ack: 1, Len: 0
    Source port: ftp (21)
    Destination port: 4096 (4096)
    Sequence number: 0    (relative sequence number)
    Acknowledgement number: 1    (relative ack number)
    Header length: 28 bytes
    Flags: 0x12 (SYN, ACK)
    Window size: 16384
    Checksum: 0x2671 [correct]
    Options: (8 bytes)
    [SEQ/ACK analysis]

No.     Time        Source                Destination           Protocol
Info
      3 0.001961    10.0.0.103            129.128.5.191         TCP
4096 > ftp [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0

Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: AsustekC_64:cd:e6 (00:1b:fc:64:cd:e6), Dst: Dell_ca:4d:de
(00:19:b9:ca:4d:de)
Internet Protocol, Src: 10.0.0.103 (10.0.0.103), Dst: 129.128.5.191
(129.128.5.191)
Transmission Control Protocol, Src Port: 4096 (4096), Dst Port: ftp (21),
Seq: 1, Ack: 1, Len: 0
    Source port: 4096 (4096)
    Destination port: ftp (21)
    Sequence number: 1    (relative sequence number)
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0x10 (ACK)
    Window size: 65535
    Checksum: 0x91c0 [incorrect, should be 0x9335 (maybe caused by "TCP
checksum offload"?)]
    [SEQ/ACK analysis]

No.     Time        Source                Destination           Protocol
Info
      4 0.169341    129.128.5.191         10.0.0.103            FTP
Response: 220-

Frame 4 (105 bytes on wire, 105 bytes captured)
Ethernet II, Src: Dell_ca:4d:de (00:19:b9:ca:4d:de), Dst: AsustekC_64:cd:e6
(00:1b:fc:64:cd:e6)
Internet Protocol, Src: 129.128.5.191 (129.128.5.191), Dst: 10.0.0.103
(10.0.0.103)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: 4096 (4096),
Seq: 1, Ack: 1, Len: 51
    Source port: ftp (21)
    Destination port: 4096 (4096)
    Sequence number: 1    (relative sequence number)
    [Next sequence number: 52    (relative sequence number)]
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
    Window size: 17520
    Checksum: 0x0387 [incorrect, should be 0x124b (maybe caused by "TCP
checksum offload"?)]
    [SEQ/ACK analysis]
File Transfer Protocol (FTP)

No.     Time        Source                Destination           Protocol
Info
      5 6.159114    129.128.5.191         10.0.0.103            FTP
[TCP Retransmission] Response: 220-

Frame 5 (573 bytes on wire, 573 bytes captured)
Ethernet II, Src: Dell_ca:4d:de (00:19:b9:ca:4d:de), Dst: AsustekC_64:cd:e6
(00:1b:fc:64:cd:e6)
Internet Protocol, Src: 129.128.5.191 (129.128.5.191), Dst: 10.0.0.103
(10.0.0.103)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: 4096 (4096),
Seq: 1, Ack: 1, Len: 519
    Source port: ftp (21)
    Destination port: 4096 (4096)
    Sequence number: 1    (relative sequence number)
    [Next sequence number: 520    (relative sequence number)]
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
    Window size: 17520
    Checksum: 0x2f2f [incorrect, should be 0x3df3 (maybe caused by "TCP
checksum offload"?)]
    [SEQ/ACK analysis]
File Transfer Protocol (FTP)

No.     Time        Source                Destination           Protocol
Info
      6 18.159149   129.128.5.191         10.0.0.103            FTP
[TCP Retransmission] Response: 220-

Frame 6 (573 bytes on wire, 573 bytes captured)
Ethernet II, Src: Dell_ca:4d:de (00:19:b9:ca:4d:de), Dst: AsustekC_64:cd:e6
(00:1b:fc:64:cd:e6)
Internet Protocol, Src: 129.128.5.191 (129.128.5.191), Dst: 10.0.0.103
(10.0.0.103)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: 4096 (4096),
Seq: 1, Ack: 1, Len: 519
    Source port: ftp (21)
    Destination port: 4096 (4096)
    Sequence number: 1    (relative sequence number)
    [Next sequence number: 520    (relative sequence number)]
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
    Window size: 17520
    Checksum: 0x2f2f [incorrect, should be 0x3df3 (maybe caused by "TCP
checksum offload"?)]
    [SEQ/ACK analysis]
File Transfer Protocol (FTP)

No.     Time        Source                Destination           Protocol
Info
      7 42.158544   129.128.5.191         10.0.0.103            FTP
[TCP Retransmission] Response: 220-

Frame 7 (573 bytes on wire, 573 bytes captured)
Ethernet II, Src: Dell_ca:4d:de (00:19:b9:ca:4d:de), Dst: AsustekC_64:cd:e6
(00:1b:fc:64:cd:e6)
Internet Protocol, Src: 129.128.5.191 (129.128.5.191), Dst: 10.0.0.103
(10.0.0.103)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: 4096 (4096),
Seq: 1, Ack: 1, Len: 519
    Source port: ftp (21)
    Destination port: 4096 (4096)
    Sequence number: 1    (relative sequence number)
    [Next sequence number: 520    (relative sequence number)]
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
    Window size: 17520
    Checksum: 0x2f2f [incorrect, should be 0x3df3 (maybe caused by "TCP
checksum offload"?)]
    [SEQ/ACK analysis]
File Transfer Protocol (FTP)

No.     Time        Source                Destination           Protocol
Info
      8 60.001675   10.0.0.103            129.128.5.191         TCP
4096 > ftp [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

Frame 8 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: AsustekC_64:cd:e6 (00:1b:fc:64:cd:e6), Dst: Dell_ca:4d:de
(00:19:b9:ca:4d:de)
Internet Protocol, Src: 10.0.0.103 (10.0.0.103), Dst: 129.128.5.191
(129.128.5.191)
Transmission Control Protocol, Src Port: 4096 (4096), Dst Port: ftp (21),
Seq: 1, Ack: 1, Len: 0
    Source port: 4096 (4096)
    Destination port: ftp (21)
    Sequence number: 1    (relative sequence number)
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0x14 (RST, ACK)
    Window size: 0
    Checksum: 0x9331 [correct]
-------------------END 





-----Original Message-----
From: owner-misc@openbsd.org [mailto:owner-misc@openbsd.org] On Behalf Of
Jason Calhoun
Sent: Friday, September 14, 2007 11:41 AM
To: misc@openbsd.org
Subject: Problem with ftp-proxy 

Hi,

I have an OpenBSD 4.1 system running as a NAT firewall for our office and
unfortunately I have to support a couple of active 
FTP clients on the inside of the firewall, so I've set up ftp-proxy.  I've
never used ftp-proxy before and I've run into a problem with it.

I've set up ftp-proxy and pf as described in the PF FAQ.  When the client
application tries to connect, it behaves as if it never 
gets a response from the server. The connection hangs and eventually the
client ftp application reports a time out.

What's actually happening is not as much fun.  I ran a packet sniffer on the
client computer while trying to establish the ftp connection.  
Things happen as follows:

The client (inside the firewall) initiates a connection to an FTP server on
a public IP.
The TCP handshake completes.
The FTP server sends its first FTP protocol packet containing the usual
welcome/banner string - This packet does make its way back
through the firewall to the client system.  However, (according to Wireshark
on the client) the checksum on the pack is incorrect.  
The client ftp application then seems to just ignore the packet from the
server, presumably because the checkum in the packet 
does not match the calculated checksum.


Can anyone shed some light on this?  Has anyone else had problems with
ftp-proxy like this?

Thanks a lot.
Jason
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
FW: Problem with ftp-proxy -- additional info, Jason, (Fri Sep 14, 6:14 pm)
Re: FW: Problem with ftp-proxy -- additional info, Darren Spruell, (Sat Sep 15, 2:48 am)