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)