On 9/14/07, Jason <[EMAIL PROTECTED]> wrote: > 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
Strange that you don't have any firewall rules allowing traffic in/out of your internal interface, short of the rdr pass for your FTP -> proxy traffic. Is that the only stuff that should be going out? [snip] > 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"?)] You said originally that the packet from the server / firewall (ftp-proxy) contained the invalid checksum, but in this capture the syn-ack from your client at the end of the handshake is the first one reported with an incorrect checksum. It's also the one that ungraciously tears down the connection below. > 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] A few ideas: - test using same internal host, but different FTP client. - test using different internal host, same FTP client and different FTP client. (Preferably one with a different NIC model; e.g. certain hardware checksum offloading features have been known to cause frame corruption. Maybe you've got something like that? - any really good reason you can't use passive mode FTP? - enable debugging in PF to see if you can get any errors that might be occurring. I wouldn't imagine any, but: # pfctl -x loud ...and look for debug output in /var/log/messages. When you're done: # pfctl -x urgent DS
