From owner-freebsd-pf@FreeBSD.ORG Mon Jan 4 11:07:03 2010 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E63C106568B for ; Mon, 4 Jan 2010 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 23D118FC15 for ; Mon, 4 Jan 2010 11:07:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o04B73UR064976 for ; Mon, 4 Jan 2010 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o04B72nU064974 for freebsd-pf@FreeBSD.org; Mon, 4 Jan 2010 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Jan 2010 11:07:02 GMT Message-Id: <201001041107.o04B72nU064974@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2010 11:07:03 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty o kern/140697 pf [pf] pf behaviour changes - must be documented o kern/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 38 problems total. From owner-freebsd-pf@FreeBSD.ORG Wed Jan 6 16:33:11 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEC3B106568B for ; Wed, 6 Jan 2010 16:33:11 +0000 (UTC) (envelope-from m.keith.thompson@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 559DD8FC0C for ; Wed, 6 Jan 2010 16:33:10 +0000 (UTC) Received: by bwz5 with SMTP id 5so11083885bwz.3 for ; Wed, 06 Jan 2010 08:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=iFuXeD5SGktvH/kPp/7ItsPo0JbHlSj4ZVd5rJny4Ok=; b=GnoAA14Al0OChLO324lLbeORMYK1SGDHxbYMf0rCgCxAk19x8k+vaNtPH25nXk2Mye fPFyP8amu1FNimPtMaoUZV4px5aZGCca6kcQ8orhe/nSn/S4l98xk7VfehGrrrfX9xAS IQMA40rW4y8eppcFRrhkU4vreLyBpPPAYrkKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jgOFH610SiqtxKJISoUjJvPcnLAdihXLhBADRRfMb6vxK0Tm+vQP2ip7TMla7Og1i+ loH/gqw9bzq/NKfj0A7tTZrH2HORyDi9nCp4G5ri72LAkvDjL7+rr0GvBI83RcmlUdQ3 KKeQx58U9KzR6DnUVfnY6wKSswwx1rmsODxRY= MIME-Version: 1.0 Received: by 10.204.7.88 with SMTP id c24mr949592bkc.17.1262794151860; Wed, 06 Jan 2010 08:09:11 -0800 (PST) Date: Wed, 6 Jan 2010 10:09:11 -0600 Message-ID: From: "M. Keith Thompson" To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 16:33:11 -0000 I have a very screwy problem. I have a pure-ftp server running pf on FreeBSD 7.0. For the most part the server works fine; users upload and download multi-megabyte files daily. However, I have one client (HP-UX) that can not get files larger that 98K. If I turn off pf, it works fine. The pflog does not show any packets from the IP that does not work. I am totally lost; any ideas? From owner-freebsd-pf@FreeBSD.ORG Wed Jan 6 17:23:15 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7AB010656A3 for ; Wed, 6 Jan 2010 17:23:15 +0000 (UTC) (envelope-from allicient3141@googlemail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 3A11E8FC12 for ; Wed, 6 Jan 2010 17:23:14 +0000 (UTC) Received: by ewy26 with SMTP id 26so15672318ewy.3 for ; Wed, 06 Jan 2010 09:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=rfS42H7YYBR9eHYUQXGf2ssQBwjIGQRBPznaox2gilY=; b=MLPZEVCygdNfBVsh+93KurEsv9oLCKXFOJPEiOJBjujd1s1Yq2jB8+fND9Hsr9m0yt 0bpnOFWW4iinKng03NtQivjbG+bOHLwYYgVQq/+lL5UFKndXJF5hmGwPGZeMhGVJ5XxP Sm7bnm8sKw/LZNZMYN9xUAwBUqWe7LLom+aKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=X62JE5ccHw0Vy059tmTI3GJ4U1nQSCIKW3/gz0l8B3ZLdUNBwDvKOp11WlqymqVn+d ueGTRD1Q5Oduh7EijgTjSiRIHh4cOlak1FmUlXEXQxFFYT6xjx4dD0OuPlCO3Iq67vP5 f5r/0HI5JNpK70qQetOWGfKY9A4LaBIEpT7ME= MIME-Version: 1.0 Sender: allicient3141@googlemail.com Received: by 10.213.40.147 with SMTP id k19mr9063803ebe.33.1262798586757; Wed, 06 Jan 2010 09:23:06 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Jan 2010 17:23:03 +0000 X-Google-Sender-Auth: f1663a442936fbc0 Message-ID: <7731938b1001060923n5de4b511of07b8c63cff4e011@mail.gmail.com> From: Peter Maxwell To: "M. Keith Thompson" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:23:15 -0000 2010/1/6 M. Keith Thompson : > I have a very screwy problem. =A0I have a pure-ftp server running pf on > FreeBSD 7.0. =A0For the most part the server works fine; users upload > and download multi-megabyte files daily. =A0However, I have one client > (HP-UX) that can not get files larger that 98K. =A0If I turn off pf, it > works fine. =A0The pflog does not show any packets from the IP that does > not work. =A0I am totally lost; any ideas? Off the top of my head: packet normalisation/scrub directives, the other one would be to post your ruleset and a tcpdump of the session so folk have something to work with. Also, what happens to the FTP data and control connections - do they just stall or are the RSTs, etc? What does your state table show? From owner-freebsd-pf@FreeBSD.ORG Wed Jan 6 17:57:49 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F51D106566C for ; Wed, 6 Jan 2010 17:57:49 +0000 (UTC) (envelope-from m.keith.thompson@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 6B35E8FC1C for ; Wed, 6 Jan 2010 17:57:48 +0000 (UTC) Received: by bwz5 with SMTP id 5so11152920bwz.3 for ; Wed, 06 Jan 2010 09:57:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BHCh32bhztYu/Q19vlI+cTaiJtYkY+lIayVCvMT1qMg=; b=fyPEeOt93rpvpDJ/xpTyl8ta2d1DUfyMHcmcu6pPu5EMWzSdfHCmBRAByawryRvClI 0o9wWeVqMGMiAKaNAHEjsILH4dow4kM6vQF5H9aiRvT7z/bniox2uvh8qo7nVMjZdniV btrYAGddeIEuBKg0SPIQQWIGujRNMxMNf3rD8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WXPMpovvOVCAORGEXOkIfCD06K0yHPE66ZGc2+I4I/KIrAMltv4DiChBbFzXqqzsR1 jFTkZQInGx3sqgTQkmtwHUbCSnSRCTW71wfoqdrH4z8qP2Yclf875AnnzmtRTyYE4lB0 Z/4l5u9ImQDhd5ruqtHNnHKsmeDHQNtmbp/Nc= MIME-Version: 1.0 Received: by 10.204.48.194 with SMTP id s2mr3723371bkf.210.1262800661992; Wed, 06 Jan 2010 09:57:41 -0800 (PST) In-Reply-To: <7731938b1001060923n5de4b511of07b8c63cff4e011@mail.gmail.com> References: <7731938b1001060923n5de4b511of07b8c63cff4e011@mail.gmail.com> Date: Wed, 6 Jan 2010 11:57:41 -0600 Message-ID: From: "M. Keith Thompson" To: Peter Maxwell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:57:49 -0000 The states and tcpdump are with scrub turned off. I tried that and it did not change things. ---- Begin of pf.conf ------- ext_if=3D"em0" ext_IP=3D"xxx.yyy.15.125" local_if=3D"lo0" net_eng=3D"{xxx.yyy.103.224/27 xxx.yyy.203.248/29 aaa.bbb.44.62/32}" pingers=3D"{xxx.yyy.24.13/32 xxx.yyy.24.119/32}" # Normalization: reassemble fragments and resolve or reduce traffic ambigui= ties. scrub in all block in log all pass on $local_if all # SSH from NetEng subnet pass in quick log on $ext_if proto tcp from $net_eng to $ext_if port 22 keep state # Allow inside network to ping the server pass in quick on $ext_if proto icmp from $pingers to $ext_IP keep state # Allow DNS lookups pass out quick on $ext_if proto udp to any port 53 pass out quick on $ext_if proto tcp to any port 53 keep state # Allow ftp pass in quick on $ext_if proto tcp from any to $ext_IP port 21 keep state pass in quick on $ext_if proto tcp from any to $ext_IP port > 49151 keep st= ate pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP port 20 keep state --- end of pf.conf ---------------------- Unsuccessful: self tcp xxx.yyy.15.125:21 <- vvv.zzz.226.92:50187 TIME_WAIT:TIME_WAI= T self tcp xxx.yyy.15.125:20 <- vvv.zzz.226.92:59433 FIN_WAIT_2:FIN_WAI= T_2 self tcp xxx.yyy.15.125:20 <- vvv.zzz.226.92:59434 FIN_WAIT_2:FIN_WAI= T_2 Successful: self tcp xxx.yyy.15.125:21 <- vvv.zzz.226.92:50188 FIN_WAIT_2:FIN_WAI= T_2 self tcp xxx.yyy.15.125:20 <- vvv.zzz.226.92:59435 FIN_WAIT_2:FIN_WAI= T_2 tcpdump: tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 byt= es 11:40:28.950507 IP (tos 0x0, ttl 52, id 52212, offset 0, flags [none], proto: TCP (6), length: 60) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: S, cksum 0x57c6 (correct), 1708289474:1708289474(0) win 16384 11:40:28.950547 IP (tos 0x0, ttl 64, id 13399, offset 0, flags [DF], proto: TCP (6), length: 60) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: S, cksum 0xea7a (correct), 2617007767:2617007767(0) ack 1708289475 win 65535 11:40:29.118537 IP (tos 0x0, ttl 52, id 52343, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: ., cksum 0xd12f (correct), ack 1 win 17680 11:40:29.119874 IP (tos 0x10, ttl 64, id 13400, offset 0, flags [DF], proto: TCP (6), length: 311) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: P 1:260(259) ack 1 win 33026 11:40:29.288183 IP (tos 0x0, ttl 52, id 52368, offset 0, flags [none], proto: TCP (6), length: 65) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: P, cksum 0xd78f (correct), 1:14(13) ack 260 win 17680 11:40:29.288327 IP (tos 0x10, ttl 64, id 13401, offset 0, flags [DF], proto: TCP (6), length: 91) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: P 260:299(39) ack 14 win 33026 11:40:29.455835 IP (tos 0x0, ttl 52, id 52406, offset 0, flags [none], proto: TCP (6), length: 67) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: P, cksum 0xd592 (correct), 14:29(15) ack 299 win 17680 11:40:29.462032 IP (tos 0x10, ttl 64, id 13402, offset 0, flags [DF], proto: TCP (6), length: 134) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: P 299:381(82) ack 29 win 33026 11:40:29.631357 IP (tos 0x0, ttl 52, id 52434, offset 0, flags [none], proto: TCP (6), length: 57) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: P, cksum 0x2f25 (correct), 29:34(5) ack 381 win 17680 11:40:29.631411 IP (tos 0x10, ttl 64, id 13403, offset 0, flags [DF], proto: TCP (6), length: 86) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: P 381:415(34) ack 34 win 33026 11:40:29.798759 IP (tos 0x0, ttl 52, id 52477, offset 0, flags [none], proto: TCP (6), length: 58) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: P, cksum 0x3814 (correct), 34:40(6) ack 415 win 17680 11:40:29.798802 IP (tos 0x10, ttl 64, id 13405, offset 0, flags [DF], proto: TCP (6), length: 246) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: P 415:609(194) ack 40 win 33026 11:40:29.969658 IP (tos 0x0, ttl 52, id 52598, offset 0, flags [none], proto: TCP (6), length: 63) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: P, cksum 0x7df9 (correct), 40:51(11) ack 609 win 17680 11:40:29.969697 IP (tos 0x10, ttl 64, id 13406, offset 0, flags [DF], proto: TCP (6), length: 169) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: P 609:726(117) ack 51 win 33026 11:40:30.139809 IP (tos 0x0, ttl 52, id 52620, offset 0, flags [none], proto: TCP (6), length: 80) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: P, cksum 0x0f2f (correct), 51:79(28) ack 726 win 17680 11:40:30.139943 IP (tos 0x10, ttl 64, id 13407, offset 0, flags [DF], proto: TCP (6), length: 81) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: P, cksum 0xd391 (correct), 726:755(29) ack 79 win 33026 11:40:30.307710 IP (tos 0x0, ttl 52, id 52658, offset 0, flags [none], proto: TCP (6), length: 77) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: P, cksum 0x3d00 (correct), 79:104(25) ack 755 win 17680 11:40:30.307785 IP (tos 0x0, ttl 64, id 13408, offset 0, flags [DF], proto: TCP (6), length: 64) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59433: S, cksum 0x28f0 (correct), 996672625:996672625(0) win 65535 11:40:30.407095 IP (tos 0x10, ttl 64, id 13409, offset 0, flags [DF], proto: TCP (6), length: 52) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: ., cksum 0x8c30 (correct), ack 104 win 33026 11:40:30.475112 IP (tos 0x0, ttl 52, id 52691, offset 0, flags [none], proto: TCP (6), length: 60) vvv.zzz.226.92.59433 > xxx.yyy.15.125.ftp-data: S, cksum 0x4e22 (correct), 425829165:425829165(0) ack 996672626 win 17680 11:40:30.475147 IP (tos 0x0, ttl 64, id 13410, offset 0, flags [DF], proto: TCP (6), length: 52) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59433: ., cksum 0x3ce9 (correct), ack 1 win 33026 11:40:30.475175 IP (tos 0x10, ttl 64, id 13411, offset 0, flags [DF], proto: TCP (6), length: 82) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: P, cksum 0x2440 (correct), 755:785(30) ack 104 win 33026 11:40:30.476375 IP (tos 0x8, ttl 64, id 13412, offset 0, flags [DF], proto: TCP (6), length: 757) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59433: P 1:706(705) ack 1 win 33026 11:40:30.476386 IP (tos 0x8, ttl 64, id 13413, offset 0, flags [DF], proto: TCP (6), length: 52) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59433: F, cksum 0x3a26 (correct), 706:706(0) ack 1 win 33026 11:40:30.476419 IP (tos 0x10, ttl 64, id 13414, offset 0, flags [DF], proto: TCP (6), length: 74) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: P, cksum 0xa90b (correct), 785:807(22) ack 104 win 33026 11:40:30.644763 IP (tos 0x0, ttl 52, id 52719, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59433 > xxx.yyy.15.125.ftp-data: ., cksum 0x9a01 (correct), ack 707 win 8487 11:40:30.644768 IP (tos 0x0, ttl 52, id 52721, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59433 > xxx.yyy.15.125.ftp-data: F, cksum 0x989f (correct), 1:1(0) ack 707 win 8840 11:40:30.644800 IP (tos 0x8, ttl 64, id 13415, offset 0, flags [DF], proto: TCP (6), length: 52) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59433: ., cksum 0x397e (correct), ack 2 win 33025 11:40:30.645140 IP (tos 0x0, ttl 52, id 52725, offset 0, flags [none], proto: TCP (6), length: 60) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: P, cksum 0xf5a8 (correct), 104:112(8) ack 807 win 17680 11:40:30.645186 IP (tos 0x10, ttl 64, id 13416, offset 0, flags [DF], proto: TCP (6), length: 82) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: P, cksum 0xabd2 (correct), 807:837(30) ack 112 win 33026 11:40:30.817661 IP (tos 0x0, ttl 52, id 52751, offset 0, flags [none], proto: TCP (6), length: 104) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: P 112:164(52) ack 837 win 17680 11:40:30.817733 IP (tos 0x10, ttl 64, id 13417, offset 0, flags [DF], proto: TCP (6), length: 64) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: P, cksum 0x7ef6 (correct), 837:849(12) ack 164 win 33026 11:40:30.986187 IP (tos 0x0, ttl 52, id 52889, offset 0, flags [none], proto: TCP (6), length: 104) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: P 164:216(52) ack 849 win 17680 11:40:30.986350 IP (tos 0x10, ttl 64, id 13418, offset 0, flags [DF], proto: TCP (6), length: 72) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: P, cksum 0xbc39 (correct), 849:869(20) ack 216 win 33026 11:40:31.178950 IP (tos 0x0, ttl 52, id 52910, offset 0, flags [none], proto: TCP (6), length: 80) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: P, cksum 0x09ff (correct), 216:244(28) ack 869 win 17680 11:40:31.179050 IP (tos 0x10, ttl 64, id 13419, offset 0, flags [DF], proto: TCP (6), length: 81) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: P, cksum 0xce4c (correct), 869:898(29) ack 244 win 33026 11:40:31.348099 IP (tos 0x0, ttl 52, id 52939, offset 0, flags [none], proto: TCP (6), length: 104) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: P 244:296(52) ack 898 win 17680 11:40:31.348182 IP (tos 0x0, ttl 64, id 13420, offset 0, flags [DF], proto: TCP (6), length: 64) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: S, cksum 0x5b3d (correct), 1882233162:1882233162(0) win 65535 11:40:31.447341 IP (tos 0x10, ttl 64, id 13421, offset 0, flags [DF], proto: TCP (6), length: 52) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: ., cksum 0x86cf (correct), ack 296 win 33026 11:40:31.515626 IP (tos 0x0, ttl 52, id 52961, offset 0, flags [none], proto: TCP (6), length: 60) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: S, cksum 0xde2d (correct), 1839460650:1839460650(0) ack 1882233163 win 17680 11:40:31.515661 IP (tos 0x0, ttl 64, id 13422, offset 0, flags [DF], proto: TCP (6), length: 52) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: ., cksum 0xccf4 (correct), ack 1 win 33026 11:40:31.515721 IP (tos 0x10, ttl 64, id 13423, offset 0, flags [DF], proto: TCP (6), length: 112) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: P 898:958(60) ack 296 win 33026 11:40:31.516254 IP (tos 0x8, ttl 64, id 13424, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 1:1349(1348) ack 1 win 33026 11:40:31.838063 IP (tos 0x0, ttl 52, id 53010, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0x2832 (correct), ack 1349 win 8320 11:40:31.838093 IP (tos 0x8, ttl 64, id 13425, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 1349:2697(1348) ack 1 win 33026 11:40:31.838103 IP (tos 0x8, ttl 64, id 13426, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 2697:4045(1348) ack 1 win 33026 11:40:31.838437 IP (tos 0x0, ttl 52, id 53011, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: ., cksum 0xc240 (correct), ack 958 win 17680 11:40:32.006838 IP (tos 0x0, ttl 52, id 53139, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0x1c68 (correct), ack 4045 win 8320 11:40:32.006866 IP (tos 0x8, ttl 64, id 13427, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 4045:5393(1348) ack 1 win 33026 11:40:32.006876 IP (tos 0x8, ttl 64, id 13428, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 5393:6741(1348) ack 1 win 33026 11:40:32.006885 IP (tos 0x8, ttl 64, id 13429, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 6741:8089(1348) ack 1 win 33026 11:40:32.178238 IP (tos 0x0, ttl 52, id 53161, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0x0e95 (correct), ack 8089 win 7646 11:40:32.178264 IP (tos 0x8, ttl 64, id 13430, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 8089:9437(1348) ack 1 win 33026 11:40:32.178283 IP (tos 0x8, ttl 64, id 13431, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 9437:10785(1348) ack 1 win 33026 11:40:32.178292 IP (tos 0x8, ttl 64, id 13432, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 10785:12133(1348) ack 1 win 33026 11:40:32.178303 IP (tos 0x8, ttl 64, id 13433, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 12133:13481(1348) ack 1 win 33026 11:40:32.347763 IP (tos 0x0, ttl 52, id 53188, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0x0361 (correct), ack 10785 win 7646 11:40:32.347769 IP (tos 0x0, ttl 52, id 53191, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0xfb7a (correct), ack 12133 win 8320 11:40:32.347792 IP (tos 0x8, ttl 64, id 13434, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 13481:14829(1348) ack 1 win 33026 11:40:32.347801 IP (tos 0x8, ttl 64, id 13435, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 14829:16177(1348) ack 1 win 33026 11:40:32.347811 IP (tos 0x8, ttl 64, id 13436, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 16177:17525(1348) ack 1 win 33026 11:40:32.347826 IP (tos 0x8, ttl 64, id 13437, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 17525:18873(1348) ack 1 win 33026 11:40:32.347834 IP (tos 0x8, ttl 64, id 13438, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 18873:20221(1348) ack 1 win 33026 11:40:32.439209 IP (tos 0x0, ttl 52, id 53204, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0xf636 (correct), ack 13481 win 8320 11:40:32.439234 IP (tos 0x8, ttl 64, id 13439, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 20221:21569(1348) ack 1 win 33026 11:40:32.516914 IP (tos 0x0, ttl 52, id 53222, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0xeb04 (correct), ack 16177 win 8320 11:40:32.516938 IP (tos 0x8, ttl 64, id 13441, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 21569:22917(1348) ack 1 win 33026 11:40:32.516947 IP (tos 0x8, ttl 64, id 13442, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 22917:24265(1348) ack 1 win 33026 11:40:32.517165 IP (tos 0x0, ttl 52, id 53229, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0xddda (correct), ack 20221 win 7646 11:40:32.517190 IP (tos 0x8, ttl 64, id 13447, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 24265:25613(1348) ack 1 win 33026 11:40:32.517202 IP (tos 0x8, ttl 64, id 13448, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 25613:26961(1348) ack 1 win 33026 11:40:32.609860 IP (tos 0x0, ttl 52, id 53254, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0xd599 (correct), ack 21569 win 8320 11:40:32.609882 IP (tos 0x8, ttl 64, id 13450, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 26961:28309(1348) ack 1 win 33026 11:40:32.609893 IP (tos 0x8, ttl 64, id 13451, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 28309:29657(1348) ack 1 win 33026 11:40:32.685690 IP (tos 0x0, ttl 52, id 53281, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0xc821 (correct), ack 25613 win 7646 11:40:32.685713 IP (tos 0x8, ttl 64, id 13453, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 29657:31005(1348) ack 1 win 33026 11:40:32.685722 IP (tos 0x8, ttl 64, id 13454, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 31005:32353(1348) ack 1 win 33026 11:40:32.686939 IP (tos 0x0, ttl 52, id 53284, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0xc03b (correct), ack 26961 win 8320 11:40:32.686975 IP (tos 0x8, ttl 64, id 13456, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 32353:33701(1348) ack 1 win 33026 11:40:32.686986 IP (tos 0x8, ttl 64, id 13457, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 33701:35049(1348) ack 1 win 33026 11:40:32.778635 IP (tos 0x0, ttl 52, id 53315, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0xb556 (correct), ack 29657 win 8320 11:40:32.778660 IP (tos 0x8, ttl 64, id 13459, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 35049:36397(1348) ack 1 win 33026 11:40:32.778669 IP (tos 0x8, ttl 64, id 13460, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 36397:37745(1348) ack 1 win 33026 11:40:32.854966 IP (tos 0x0, ttl 52, id 53338, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0xaa81 (correct), ack 32353 win 8320 11:40:32.854988 IP (tos 0x8, ttl 64, id 13462, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 37745:39093(1348) ack 1 win 33026 11:40:32.854997 IP (tos 0x8, ttl 64, id 13463, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 39093:40441(1348) ack 1 win 33026 11:40:32.855465 IP (tos 0x0, ttl 52, id 53343, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0xa29a (correct), ack 35049 win 7646 11:40:32.855495 IP (tos 0x8, ttl 64, id 13465, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 40441:41789(1348) ack 1 win 33026 11:40:32.948411 IP (tos 0x0, ttl 52, id 53358, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0x9a59 (correct), ack 36397 win 8320 11:40:32.948463 IP (tos 0x8, ttl 64, id 13467, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 41789:43137(1348) ack 1 win 33026 11:40:32.948477 IP (tos 0x8, ttl 64, id 13468, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 43137:44485(1348) ack 1 win 33026 11:40:32.948785 IP (tos 0x0, ttl 52, id 53361, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0x9515 (correct), ack 37745 win 8320 11:40:32.948813 IP (tos 0x8, ttl 64, id 13470, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 44485:45833(1348) ack 1 win 33026 11:40:33.023741 IP (tos 0x0, ttl 52, id 53478, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0x8ce2 (correct), ack 40441 win 7646 11:40:33.023765 IP (tos 0x8, ttl 64, id 13472, offset 0, flags [DF], proto: TCP (6), length: 1400) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: . 45833:47181(1348) ack 1 win 33026 11:40:33.023774 IP (tos 0x8, ttl 64, id 13473, offset 0, flags [DF], proto: TCP (6), length: 752) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: FP 47181:47881(700) ack 1 win 33026 11:40:33.024116 IP (tos 0x0, ttl 52, id 53481, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0x84fc (correct), ack 41789 win 8320 11:40:33.118062 IP (tos 0x0, ttl 52, id 53505, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0x7f5b (correct), ack 43137 win 8320 11:40:33.118068 IP (tos 0x0, ttl 52, id 53510, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0x7775 (correct), ack 45833 win 7646 11:40:33.198889 IP (tos 0x0, ttl 52, id 53524, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: ., cksum 0x7087 (correct), ack 47882 win 7296 11:40:33.198894 IP (tos 0x0, ttl 52, id 53525, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.59434 > xxx.yyy.15.125.ftp-data: F, cksum 0x6a7e (correct), 1:1(0) ack 47882 win 8840 11:40:33.198929 IP (tos 0x8, ttl 64, id 13474, offset 0, flags [DF], proto: TCP (6), length: 52) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59434: ., cksum 0x0b55 (correct), ack 2 win 33025 11:41:18.199989 IP (tos 0x0, ttl 52, id 888, offset 0, flags [none], proto: TCP (6), length: 52) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: F, cksum 0xc1e3 (correct), 296:296(0) ack 958 win 17680 11:41:18.200018 IP (tos 0x10, ttl 64, id 13570, offset 0, flags [DF], proto: TCP (6), length: 52) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: ., cksum 0xcfa0 (correct), ack 297 win 33026 11:41:18.200099 IP (tos 0x10, ttl 64, id 13571, offset 0, flags [DF], proto: TCP (6), length: 65) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: P, cksum 0x0cd6 (correct), 958:971(13) ack 297 win 33026 11:41:18.200230 IP (tos 0x10, ttl 64, id 13572, offset 0, flags [DF], proto: TCP (6), length: 52) xxx.yyy.15.125.ftp > vvv.zzz.226.92.50187: F, cksum 0xcf92 (correct), 971:971(0) ack 297 win 33026 11:41:18.366766 IP (tos 0x0, ttl 52, id 919, offset 0, flags [none], proto: TCP (6), length: 40) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: R, cksum 0xe896 (correct), 1708289771:1708289771(0) win 0 11:41:18.366772 IP (tos 0x0, ttl 52, id 920, offset 0, flags [none], proto: TCP (6), length: 40) vvv.zzz.226.92.50187 > xxx.yyy.15.125.ftp: R, cksum 0xe896 (correct), 1708289771:1708289771(0) win 0 On Wed, Jan 6, 2010 at 11:23 AM, Peter Maxwell wrot= e: > 2010/1/6 M. Keith Thompson : >> I have a very screwy problem. =A0I have a pure-ftp server running pf on >> FreeBSD 7.0. =A0For the most part the server works fine; users upload >> and download multi-megabyte files daily. =A0However, I have one client >> (HP-UX) that can not get files larger that 98K. =A0If I turn off pf, it >> works fine. =A0The pflog does not show any packets from the IP that does >> not work. =A0I am totally lost; any ideas? > > > Off the top of my head: packet normalisation/scrub directives, the > other one would be to post your ruleset and a tcpdump of the session > so folk have something to work with. > > Also, what happens to the FTP data and control connections - do they > just stall or are the RSTs, etc? =A0What does your state table show? > From owner-freebsd-pf@FreeBSD.ORG Wed Jan 6 20:40:25 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D23010656C9 for ; Wed, 6 Jan 2010 20:40:25 +0000 (UTC) (envelope-from gofdp-freebsd-pf@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 95F508FC08 for ; Wed, 6 Jan 2010 20:40:24 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NScfr-00036T-Tl for freebsd-pf@freebsd.org; Wed, 06 Jan 2010 21:40:12 +0100 Received: from 207.155.204.151.ptr.us.xo.net ([207.155.204.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Jan 2010 21:40:11 +0100 Received: from atkin901 by 207.155.204.151.ptr.us.xo.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Jan 2010 21:40:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-pf@freebsd.org From: Mark Atkinson Date: Wed, 06 Jan 2010 11:24:02 -0800 Lines: 47 Message-ID: References: <7731938b1001060923n5de4b511of07b8c63cff4e011@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 207.155.204.151.ptr.us.xo.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100104 Thunderbird/3.0 In-Reply-To: Sender: news Subject: Re: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 20:40:25 -0000 On 01/06/10 09:57, M. Keith Thompson wrote: > The states and tcpdump are with scrub turned off. I tried that and it > did not change things. > > Unsuccessful: > > self tcp xxx.yyy.15.125:21<- vvv.zzz.226.92:50187 TIME_WAIT:TIME_WAIT > self tcp xxx.yyy.15.125:20<- vvv.zzz.226.92:59433 FIN_WAIT_2:FIN_WAIT_2 > self tcp xxx.yyy.15.125:20<- vvv.zzz.226.92:59434 FIN_WAIT_2:FIN_WAIT_2 > > Successful: > self tcp xxx.yyy.15.125:21<- vvv.zzz.226.92:50188 FIN_WAIT_2:FIN_WAIT_2 > self tcp xxx.yyy.15.125:20<- vvv.zzz.226.92:59435 FIN_WAIT_2:FIN_WAIT_2 > > On Wed, Jan 6, 2010 at 11:23 AM, Peter Maxwell wrote: >> 2010/1/6 M. Keith Thompson: >>> I have a very screwy problem. I have a pure-ftp server running pf on >>> FreeBSD 7.0. For the most part the server works fine; users upload >>> and download multi-megabyte files daily. However, I have one client >>> (HP-UX) that can not get files larger that 98K. If I turn off pf, it >>> works fine. The pflog does not show any packets from the IP that does >>> not work. I am totally lost; any ideas? >> >> >> Off the top of my head: packet normalisation/scrub directives, the >> other one would be to post your ruleset and a tcpdump of the session >> so folk have something to work with. >> >> Also, what happens to the FTP data and control connections - do they >> just stall or are the RSTs, etc? What does your state table show? The ftp server is sending FIN on the data connection after the first PSH of data. It would be interesting to see the before and after contents of the ftp command channel if you could repeat only the first failed transfer with the dump using '-s 0 -X' tcpdump flags. 11:40:30.476375 IP (tos 0x8, ttl 64, id 13412, offset 0, flags [DF], proto: TCP (6), length: 757) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59433: P 1:706(705) ack 1 win 33026 11:40:30.476386 IP (tos 0x8, ttl 64, id 13413, offset 0, flags [DF], proto: TCP (6), length: 52) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59433: F, cksum 0x3a26 (correct), 706:706(0) ack 1 win 33026 From owner-freebsd-pf@FreeBSD.ORG Wed Jan 6 21:40:31 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D01B10656C4 for ; Wed, 6 Jan 2010 21:40:31 +0000 (UTC) (envelope-from m.keith.thompson@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 92DA68FC16 for ; Wed, 6 Jan 2010 21:40:30 +0000 (UTC) Received: by bwz5 with SMTP id 5so11295370bwz.3 for ; Wed, 06 Jan 2010 13:40:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=ACLXdV5aeBxwuThquTgHMN4o7OGI2u+4234q6f5bH5Q=; b=dAtEkbQ3xtGaF34iRY+Dfm6QI6gPiwrPaEERF7jz3e9uxS43Zfr1/dI+bI5Twa29Rd NkRsnlsKhGbtWXlsRef574g/n8+2wvVncEYySe0EAWLW5GXRfn5qkD/br61Bfg762feH u5NK2nbZDqFFp8U20QRP8ySX0PWypVve7iJQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ipydFn+knXMUe5ghD4tf4PMKv9khzzPGszea1WDvMYoU5Pm/1aAsHEb3sKt8d3RLc6 QwIbkaPHlcSlyFChm/GqNA4yo28EaddTl4vIRla+VeYJxZOYuRTLN/1eBYFikANAMuXC ZX0vspoR9EZCzMWwP2JQFh/fwRjrEniZzp5CM= MIME-Version: 1.0 Received: by 10.204.18.212 with SMTP id x20mr2805184bka.9.1262814023009; Wed, 06 Jan 2010 13:40:23 -0800 (PST) In-Reply-To: <7731938b1001060923n5de4b511of07b8c63cff4e011@mail.gmail.com> References: <7731938b1001060923n5de4b511of07b8c63cff4e011@mail.gmail.com> Date: Wed, 6 Jan 2010 15:40:22 -0600 Message-ID: From: "M. Keith Thompson" To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 21:40:31 -0000 On 01/06/10 09:57, M. Keith Thompson wrote: > The states and tcpdump are with scrub turned off. I tried that and it > did not change things. > > Unsuccessful: > > self tcp xxx.yyy.15.125:21<- vvv.zzz.226.92:50187 TIME_WAIT:TIME_WAIT > self tcp xxx.yyy.15.125:20<- vvv.zzz.226.92:59433 FIN_WAIT_2:FIN_WAIT_2 > self tcp xxx.yyy.15.125:20<- vvv.zzz.226.92:59434 FIN_WAIT_2:FIN_WAIT_2 > > Successful: > self tcp xxx.yyy.15.125:21<- vvv.zzz.226.92:50188 FIN_WAIT_2:FIN_WAIT_2 > self tcp xxx.yyy.15.125:20<- vvv.zzz.226.92:59435 FIN_WAIT_2:FIN_WAIT_2 > > On Wed, Jan 6, 2010 at 11:23 AM, Peter Maxwell wrote: >> 2010/1/6 M. Keith Thompson: >>> I have a very screwy problem. I have a pure-ftp server running pf on >>> FreeBSD 7.0. For the most part the server works fine; users upload >>> and download multi-megabyte files daily. However, I have one client >>> (HP-UX) that can not get files larger that 98K. If I turn off pf, it >>> works fine. The pflog does not show any packets from the IP that does >>> not work. I am totally lost; any ideas? >> >> >> Off the top of my head: packet normalisation/scrub directives, the >> other one would be to post your ruleset and a tcpdump of the session >> so folk have something to work with. >> >> Also, what happens to the FTP data and control connections - do they >> just stall or are the RSTs, etc? What does your state table show? The ftp server is sending FIN on the data connection after the first PSH of data. It would be interesting to see the before and after contents of the ftp command channel if you could repeat only the first failed transfer with the dump using '-s 0 -X' tcpdump flags. 11:40:30.476375 IP (tos 0x8, ttl 64, id 13412, offset 0, flags [DF], proto: TCP (6), length: 757) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59433: P 1:706(705) ack 1 win 33026 11:40:30.476386 IP (tos 0x8, ttl 64, id 13413, offset 0, flags [DF], proto: TCP (6), length: 52) xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.59433: F, cksum 0x3a26 (correct), 706:706(0) ack 1 win 33026 Here is a dump with the requested flags. Some of the data was removed for security & brevity. listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes 14:40:47.964049 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: S 361770991:361770991(0) win 16384 0x0000: 4500 003c 2ecc 0000 3406 2985 a4eb e25c E..<....4.)....\ 0x0010: 97a6 0f7d c419 0015 1590 2fef 0000 0000 ...}....../..... 0x0020: a002 4000 9148 0000 0204 0550 0103 0300 ..@..H.....P.... 0x0030: 0101 080a 01de 402c 0000 0000 ......@,.... 14:40:47.964098 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: S 3213011514:3213011514(0) ack 361770992 win 65535 0x0000: 4500 003c 5adf 4000 4006 b171 97a6 0f7d E.. xxx.yyy.15.125.ftp: . ack 1 win 17680 0x0000: 4500 0034 2f1c 0000 3406 293d a4eb e25c E..4/...4.)=...\ 0x0010: 97a6 0f7d c419 0015 1590 2ff0 bf82 aa3b ...}....../....; 0x0020: 8010 4510 9021 0000 0101 080a 01de 402c ..E..!........@, 0x0030: 41bb 7bed A.{. 14:40:48.132208 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: P 1:260(259) ack 1 win 33026 0x0000: 4510 0137 5aee 4000 4006 b057 97a6 0f7d E..7Z.@.@..W...} 0x0010: a4eb e25c 0015 c419 bf82 aa3b 1590 2ff0 ...\.......;../. 0x0020: 8018 8102 649f 0000 0101 080a 41bb 7c95 ....d.......A.|. 0x0030: 01de 402c 3232 302d 2d2d 2d2d 2d2d 2d2d ..@,220--------- 0x0040: 2d20 5765 6c63 6f6d 6520 746f 2050 7572 -.Welcome.to.Pur 0x0050: 652d 4654 5064 205b 7072 6976 7365 705d e-FTPd.[privsep] 0x0060: 202d 2d2d 2d2d 2d2d 2d2d 2d0d 0a32 3230 .----------..220 0x0070: 2d59 6f75 2061 7265 2075 7365 7220 6e75 -You.are.user.nu 0x0080: 6d62 6572 2033 206f 6620 3530 2061 6c6c mber.3.of.50.all 0x0090: 6f77 6564 2e0d 0a32 3230 2d4c 6f63 616c owed...220-Local 0x00a0: 2074 696d 6520 6973 206e 6f77 2031 343a .time.is.now.14: 0x00b0: 3430 2e20 5365 7276 6572 2070 6f72 743a 40..Server.port: 0x00c0: 2032 312e 0d0a 3232 302d 5468 6973 2069 .21...220-This.i 0x00d0: 7320 6120 7072 6976 6174 6520 7379 7374 s.a.private.syst 0x00e0: 656d 202d 204e 6f20 616e 6f6e 796d 6f75 em.-.No.anonymou 0x00f0: 7320 6c6f 6769 6e0d 0a32 3230 2059 6f75 s.login..220.You 0x0100: 2077 696c 6c20 6265 2064 6973 636f 6e6e .will.be.disconn 0x0110: 6563 7465 6420 6166 7465 7220 3130 206d ected.after.10.m 0x0120: 696e 7574 6573 206f 6620 696e 6163 7469 inutes.of.inacti 0x0130: 7669 7479 2e0d 0a vity... 14:40:48.300852 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: P 1:14(13) ack 260 win 17680 0x0000: 4500 0041 2f6c 0000 3406 28e0 a4eb e25c E..A/l..4.(....\ 0x0010: 97a6 0f7d c419 0015 1590 2ff0 bf82 ab3e ...}....../....> 0x0020: 8018 4510 9683 0000 0101 080a 01de 402c ..E...........@, 0x0030: 41bb 7c95 5553 4552 2065 6461 6564 690d A.|.USER.edaedi. 0x0040: 0a . 14:40:48.300984 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: P 260:299(39) ack 14 win 33026 0x0000: 4510 005b 5af5 4000 4006 b12c 97a6 0f7d E..[Z.@.@..,...} 0x0010: a4eb e25c 0015 c419 bf82 ab3e 1590 2ffd ...\.......>../. 0x0020: 8018 8102 d846 0000 0101 080a 41bb 7d3e .....F......A.}> . . . 14:40:48.469127 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: P 14:29(15) ack 299 win 17680 0x0000: 4500 0043 2fba 0000 3406 2890 a4eb e25c E..C/...4.(....\ 0x0010: 97a6 0f7d c419 0015 1590 2ffd bf82 ab65 ...}....../....e 0x0020: 8018 4510 9485 0000 0101 080a 01de 402d ..E...........@- . . 14:40:48.474801 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: P 299:381(82) ack 29 win 33026 0x0000: 4510 0086 5afb 4000 4006 b0fb 97a6 0f7d E...Z.@.@......} 0x0010: a4eb e25c 0015 c419 bf82 ab65 1590 300c ...\.......e..0. 0x0020: 8018 8102 dce4 0000 0101 080a 41bb 7dec ............A.}. . . . 0x0060: 2020 2020 0d0a 3233 3020 4f4b 2e20 4375 ......230.OK..Cu 0x0070: 7272 656e 7420 6469 7265 6374 6f72 7920 rrent.directory. 0x0080: 6973 202f 0d0a is./.. 14:40:48.644524 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: P 29:34(5) ack 381 win 17680 0x0000: 4500 0039 3056 0000 3406 27fe a4eb e25c E..90V..4.'....\ 0x0010: 97a6 0f7d c419 0015 1590 300c bf82 abb7 ...}......0..... 0x0020: 8018 4510 ee17 0000 0101 080a 01de 402d ..E...........@- 0x0030: 41bb 7dec 5057 440d 0a A.}.PWD.. 14:40:48.644575 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: P 381:415(34) ack 34 win 33026 0x0000: 4510 0056 5b0b 4000 4006 b11b 97a6 0f7d E..V[.@.@......} 0x0010: a4eb e25c 0015 c419 bf82 abb7 1590 3011 ...\..........0. 0x0020: 8018 8102 c66e 0000 0101 080a 41bb 7e95 .....n......A.~. 0x0030: 01de 402d 3235 3720 222f 2220 6973 2079 ..@-257."/".is.y 0x0040: 6f75 7220 6375 7272 656e 7420 6c6f 6361 our.current.loca 0x0050: 7469 6f6e 0d0a tion.. 14:40:48.813676 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: P 34:40(6) ack 415 win 17680 0x0000: 4500 003a 3091 0000 3406 27c2 a4eb e25c E..:0...4.'....\ 0x0010: 97a6 0f7d c419 0015 1590 3011 bf82 abd9 ...}......0..... 0x0020: 8018 4510 f707 0000 0101 080a 01de 402d ..E...........@- 0x0030: 41bb 7e95 4645 4154 0d0a A.~.FEAT.. 14:40:48.813719 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: P 415:609(194) ack 40 win 33026 0x0000: 4510 00f6 5b12 4000 4006 b074 97a6 0f7d E...[.@.@..t...} 0x0010: a4eb e25c 0015 c419 bf82 abd9 1590 3017 ...\..........0. 0x0020: 8018 8102 8c53 0000 0101 080a 41bb 7f3e .....S......A..> 0x0030: 01de 402d 3231 312d 4578 7465 6e73 696f ..@-211-Extensio 0x0040: 6e73 2073 7570 706f 7274 6564 3a0d 0a20 ns.supported:... 0x0050: 4550 5254 0d0a 2049 444c 450d 0a20 4d44 EPRT...IDLE...MD 0x0060: 544d 0d0a 2053 495a 450d 0a20 5245 5354 TM...SIZE...REST 0x0070: 2053 5452 4541 4d0d 0a20 4d4c 5354 2074 .STREAM...MLST.t 0x0080: 7970 652a 3b73 697a 652a 3b73 697a 642a ype*;size*;sizd* 0x0090: 3b6d 6f64 6966 792a 3b55 4e49 582e 6d6f ;modify*;UNIX.mo 0x00a0: 6465 2a3b 554e 4958 2e75 6964 2a3b 554e de*;UNIX.uid*;UN 0x00b0: 4958 2e67 6964 2a3b 756e 6971 7565 2a3b IX.gid*;unique*; 0x00c0: 0d0a 204d 4c53 440d 0a20 4553 5441 0d0a ...MLSD...ESTA.. 0x00d0: 2050 4153 560d 0a20 4550 5356 0d0a 2053 .PASV...EPSV...S 0x00e0: 5053 560d 0a20 4553 5450 0d0a 3231 3120 PSV...ESTP..211. 0x00f0: 456e 642e 0d0a End... 14:40:48.986324 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: P 40:51(11) ack 609 win 17680 0x0000: 4500 003f 30ce 0000 3406 2780 a4eb e25c E..?0...4.'....\ 0x0010: 97a6 0f7d c419 0015 1590 3017 bf82 ac9b ...}......0..... 0x0020: 8018 4510 3cea 0000 0101 080a 01de 402e ..E.<.........@. 0x0030: 41bb 7f3e 4845 4c50 2053 4954 450d 0a A..>HELP.SITE.. 14:40:48.986365 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: P 609:726(117) ack 51 win 33026 0x0000: 4510 00a9 5b17 4000 4006 b0bc 97a6 0f7d E...[.@.@......} 0x0010: a4eb e25c 0015 c419 bf82 ac9b 1590 3022 ...\..........0" 0x0020: 8018 8102 e800 0000 0101 080a 41bb 7feb ............A... 0x0030: 01de 402e 3231 342d 5468 6520 666f 6c6c ..@.214-The.foll 0x0040: 6f77 696e 6720 5349 5445 2063 6f6d 6d61 owing.SITE.comma 0x0050: 6e64 7320 6172 6520 7265 636f 676e 697a nds.are.recogniz 0x0060: 6564 0d0a 2041 4c49 4153 0d0a 2043 484d ed...ALIAS...CHM 0x0070: 4f44 0d0a 2049 444c 450d 0a20 5554 494d OD...IDLE...UTIM 0x0080: 450d 0a32 3134 2050 7572 652d 4654 5064 E..214.Pure-FTPd 0x0090: 202d 2068 7474 703a 2f2f 7075 7265 6674 .-.http://pureft 0x00a0: 7064 2e6f 7267 2f0d 0a pd.org/.. 14:40:49.160097 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: P 51:80(29) ack 726 win 17680 0x0000: 4500 0051 3118 0000 3406 2724 a4eb e25c E..Q1...4.'$...\ 0x0010: 97a6 0f7d c419 0015 1590 3022 bf82 ad10 ...}......0".... 0x0020: 8018 4510 9e1a 0000 0101 080a 01de 402e ..E...........@. 0x0030: 41bb 7feb 504f 5254 2031 3634 2c32 3335 A...PORT.164,235 0x0040: 2c32 3236 2c39 322c 3233 352c 3130 330d ,226,92,235,103. 0x0050: 0a . 14:40:49.160234 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: P 726:755(29) ack 80 win 33026 0x0000: 4510 0051 5b26 4000 4006 b105 97a6 0f7d E..Q[&@.@......} 0x0010: a4eb e25c 0015 c419 bf82 ad10 1590 303f ...\..........0? 0x0020: 8018 8102 927b 0000 0101 080a 41bb 8099 .....{......A... 0x0030: 01de 402e 3230 3020 504f 5254 2063 6f6d ..@.200.PORT.com 0x0040: 6d61 6e64 2073 7563 6365 7373 6675 6c0d mand.successful. 0x0050: 0a . 14:40:49.329499 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: P 80:105(25) ack 755 win 17680 0x0000: 4500 004d 3160 0000 3406 26e0 a4eb e25c E..M1`..4.&....\ 0x0010: 97a6 0f7d c419 0015 1590 303f bf82 ad2d ...}......0?...- 0x0020: 8018 4510 fbea 0000 0101 080a 01de 402e ..E...........@. . . 14:40:49.329635 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60263: S 2183710806:2183710806(0) win 65535 0x0000: 4500 0040 5b2d 4000 4006 b11f 97a6 0f7d E..@[-@.@......} 0x0010: a4eb e25c 0014 eb67 8228 c856 0000 0000 ...\...g.(.V.... 0x0020: b002 ffff 0f9d 0000 0204 05b4 0103 0301 ................ 0x0030: 0101 080a 41bb 8142 0000 0000 0402 0000 ....A..B........ 14:40:49.429011 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: . ack 105 win 33026 0x0000: 4510 0034 5b2e 4000 4006 b11a 97a6 0f7d E..4[.@.@......} 0x0010: a4eb e25c 0015 c419 bf82 ad2d 1590 3058 ...\.......-..0X 0x0020: 8010 8102 4b1a 0000 0101 080a 41bb 81a6 ....K.......A... 0x0030: 01de 402e ..@. 14:40:49.497150 IP vvv.zzz.226.92.60263 > xxx.yyy.15.125.ftp-data: S 3714191276:3714191276(0) ack 2183710807 win 17680 0x0000: 4500 003c 31ae 0000 3406 26a3 a4eb e25c E..<1...4.&....\ 0x0010: 97a6 0f7d eb67 0014 dd62 0fac 8228 c857 ...}.g...b...(.W 0x0020: a012 4510 afc9 0000 0204 0550 0103 0301 ..E........P.... 0x0030: 0101 080a 01de 402f 41bb 8142 ......@/A..B 14:40:49.497191 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60263: . ack 1 win 33026 0x0000: 4500 0034 5b34 4000 4006 b124 97a6 0f7d E..4[4@.@..$...} 0x0010: a4eb e25c 0014 eb67 8228 c857 dd62 0fad ...\...g.(.W.b.. 0x0020: 8010 8102 9e90 0000 0101 080a 41bb 81ea ............A... 0x0030: 01de 402f ..@/ 14:40:49.497227 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: P 755:785(30) ack 105 win 33026 0x0000: 4510 0052 5b35 4000 4006 b0f5 97a6 0f7d E..R[5@.@......} 0x0010: a4eb e25c 0015 c419 bf82 ad2d 1590 3058 ...\.......-..0X 0x0020: 8018 8102 e92a 0000 0101 080a 41bb 81ea .....*......A... 0x0030: 01de 402e 3135 3020 436f 6e6e 6563 7469 ..@.150.Connecti 0x0040: 6e67 2074 6f20 706f 7274 2036 3032 3633 ng.to.port.60263 0x0050: 0d0a .. 14:40:49.498433 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60263: P 1:659(658) ack 1 win 33026 0x0000: 4508 02c6 5b36 4000 4006 ae88 97a6 0f7d E...[6@.@......} 0x0010: a4eb e25c 0014 eb67 8228 c857 dd62 0fad ...\...g.(.W.b.. 0x0020: 8018 8102 6e98 0000 0101 080a 41bb 81eb ....n.......A... . . . . . . . . . . . . . . . . . . . . 14:40:49.498445 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60263: F 659:659(0) ack 1 win 33026 0x0000: 4508 0034 5b37 4000 4006 b119 97a6 0f7d E..4[7@.@......} 0x0010: a4eb e25c 0014 eb67 8228 cae9 dd62 0fad ...\...g.(...b.. 0x0020: 8011 8102 9bfc 0000 0101 080a 41bb 81eb ............A... 0x0030: 01de 402f ..@/ 14:40:49.498480 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: P 785:807(22) ack 105 win 33026 0x0000: 4510 004a 5b38 4000 4006 b0fa 97a6 0f7d E..J[8@.@......} 0x0010: a4eb e25c 0015 c419 bf82 ad4b 1590 3058 ...\.......K..0X 0x0020: 8018 8102 67f6 0000 0101 080a 41bb 81eb ....g.......A... 0x0030: 01de 402e 3232 3620 3134 206d 6174 6368 ..@.226.14.match 0x0040: 6573 2074 6f74 616c 0d0a es.total.. 14:40:49.667424 IP vvv.zzz.226.92.60263 > xxx.yyy.15.125.ftp-data: . ack 660 win 8510 0x0000: 4500 0034 3251 0000 3406 2608 a4eb e25c E..42Q..4.&....\ 0x0010: 97a6 0f7d eb67 0014 dd62 0fad 8228 caea ...}.g...b...(.. 0x0020: 8010 213e fbc0 0000 0101 080a 01de 402f ..!>..........@/ 0x0030: 41bb 81eb A... 14:40:49.667430 IP vvv.zzz.226.92.60263 > xxx.yyy.15.125.ftp-data: F 1:1(0) ack 660 win 8840 0x0000: 4500 0034 3253 0000 3406 2606 a4eb e25c E..42S..4.&....\ 0x0010: 97a6 0f7d eb67 0014 dd62 0fad 8228 caea ...}.g...b...(.. 0x0020: 8011 2288 fa75 0000 0101 080a 01de 402f .."..u........@/ 0x0030: 41bb 81eb A... 14:40:49.667466 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60263: . ack 2 win 33025 0x0000: 4508 0034 5b47 4000 4006 b109 97a6 0f7d E..4[G@.@......} 0x0010: a4eb e25c 0014 eb67 8228 caea dd62 0fae ...\...g.(...b.. 0x0020: 8010 8101 9b53 0000 0101 080a 41bb 8294 .....S......A... 0x0030: 01de 402f ..@/ 14:40:49.668674 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: P 105:113(8) ack 807 win 17680 0x0000: 4500 003c 3257 0000 3406 25fa a4eb e25c E..<2W..4.%....\ 0x0010: 97a6 0f7d c419 0015 1590 3058 bf82 ad61 ...}......0X...a 0x0020: 8018 4510 b491 0000 0101 080a 01de 402f ..E...........@/ 0x0030: 41bb 81ea 5459 5045 2049 0d0a A...TYPE.I.. 14:40:49.668739 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: P 807:837(30) ack 113 win 33026 0x0000: 4510 0052 5b48 4000 4006 b0e2 97a6 0f7d E..R[H@.@......} 0x0010: a4eb e25c 0015 c419 bf82 ad61 1590 3060 ...\.......a..0` 0x0020: 8018 8102 6aba 0000 0101 080a 41bb 8295 ....j.......A... 0x0030: 01de 402f 3230 3020 5459 5045 2069 7320 ..@/200.TYPE.is. 0x0040: 6e6f 7720 382d 6269 7420 6269 6e61 7279 now.8-bit.binary 0x0050: 0d0a .. 14:40:49.839452 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: P 113:165(52) ack 837 win 17680 0x0000: 4500 0068 328d 0000 3406 2598 a4eb e25c E..h2...4.%....\ 0x0010: 97a6 0f7d c419 0015 1590 3060 bf82 ad7f ...}......0`.... 0x0020: 8018 4510 e7d6 0000 0101 080a 01de 402f ..E...........@/ . . . . 14:40:49.839526 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: P 837:849(12) ack 165 win 33026 0x0000: 4510 0040 5b4f 4000 4006 b0ed 97a6 0f7d E..@[O@.@......} 0x0010: a4eb e25c 0015 c419 bf82 ad7f 1590 3094 ...\..........0. 0x0020: 8018 8102 3de0 0000 0101 080a 41bb 8340 ....=.......A..@ 0x0030: 01de 402f 3231 3320 3533 3136 3238 0d0a ..@/213.531628.. 14:40:50.008225 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: P 165:217(52) ack 849 win 17680 0x0000: 4500 0068 32ca 0000 3406 255b a4eb e25c E..h2...4.%[...\ 0x0010: 97a6 0f7d c419 0015 1590 3094 bf82 ad8b ...}......0..... 0x0020: 8018 4510 f2e7 0000 0101 080a 01de 4030 ..E...........@0 . . . . 14:40:50.008397 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: P 849:869(20) ack 217 win 33026 0x0000: 4510 0048 5b54 4000 4006 b0e0 97a6 0f7d E..H[T@.@......} 0x0010: a4eb e25c 0015 c419 bf82 ad8b 1590 30c8 ...\..........0. 0x0020: 8018 8102 7b22 0000 0101 080a 41bb 83e9 ....{"......A... 0x0030: 01de 4030 3231 3320 3230 3039 3132 3330 ..@0213.20091230 0x0040: 3139 3037 3231 0d0a 190721.. 14:40:50.185371 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: P 217:246(29) ack 869 win 17680 0x0000: 4500 0051 331b 0000 3406 2521 a4eb e25c E..Q3...4.%!...\ 0x0010: 97a6 0f7d c419 0015 1590 30c8 bf82 ad9f ...}......0..... 0x0020: 8018 4510 97e5 0000 0101 080a 01de 4030 ..E...........@0 0x0030: 41bb 83e9 504f 5254 2031 3634 2c32 3335 A...PORT.164,235 0x0040: 2c32 3236 2c39 322c 3233 352c 3130 340d ,226,92,235,104. 0x0050: 0a . 14:40:50.185564 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: P 869:898(29) ack 246 win 33026 0x0000: 4510 0051 5b63 4000 4006 b0c8 97a6 0f7d E..Q[c@.@......} 0x0010: a4eb e25c 0015 c419 bf82 ad9f 1590 30e5 ...\..........0. 0x0020: 8018 8102 8d43 0000 0101 080a 41bb 849a .....C......A... 0x0030: 01de 4030 3230 3020 504f 5254 2063 6f6d ..@0200.PORT.com 0x0040: 6d61 6e64 2073 7563 6365 7373 6675 6c0d mand.successful. 0x0050: 0a . 14:40:50.358769 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: P 246:298(52) ack 898 win 17680 0x0000: 4500 0068 335f 0000 3406 24c6 a4eb e25c E..h3_..4.$....\ 0x0010: 97a6 0f7d c419 0015 1590 30e5 bf82 adbc ...}......0..... 0x0020: 8018 4510 ec05 0000 0101 080a 01de 4030 ..E...........@0 . . . . 14:40:50.358879 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: S 1454955342:1454955342(0) win 65535 0x0000: 4500 0040 5b6b 4000 4006 b0e1 97a6 0f7d E..@[k@.@......} 0x0010: a4eb e25c 0014 eb68 56b8 db4e 0000 0000 ...\...hV..N.... 0x0020: b002 ffff 240f 0000 0204 05b4 0103 0301 ....$........... 0x0030: 0101 080a 41bb 8547 0000 0000 0402 0000 ....A..G........ 14:40:50.458340 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: . ack 298 win 33026 0x0000: 4510 0034 5b6c 4000 4006 b0dc 97a6 0f7d E..4[l@.@......} 0x0010: a4eb e25c 0015 c419 bf82 adbc 1590 3119 ...\..........1. 0x0020: 8010 8102 45c3 0000 0101 080a 41bb 85ab ....E.......A... 0x0030: 01de 4030 ..@0 14:40:50.534790 IP vvv.zzz.226.92.60264 > xxx.yyy.15.125.ftp-data: S 1649882274:1649882274(0) ack 1454955343 win 17680 0x0000: 4500 003c 33ab 0000 3406 24a6 a4eb e25c E..<3...4.$....\ 0x0010: 97a6 0f7d eb68 0014 6257 34a2 56b8 db4f ...}.h..bW4.V..O 0x0020: a012 4510 1a4f 0000 0204 0550 0103 0301 ..E..O.....P.... 0x0030: 0101 080a 01de 4031 41bb 8547 ......@1A..G 14:40:50.534838 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . ack 1 win 33026 0x0000: 4500 0034 5b71 4000 4006 b0e7 97a6 0f7d E..4[q@.@......} 0x0010: a4eb e25c 0014 eb68 56b8 db4f 6257 34a3 ...\...hV..ObW4. 0x0020: 8010 8102 090e 0000 0101 080a 41bb 85f7 ............A... 0x0030: 01de 4031 ..@1 14:40:50.534898 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: P 898:958(60) ack 298 win 33026 0x0000: 4510 0070 5b72 4000 4006 b09a 97a6 0f7d E..p[r@.@......} 0x0010: a4eb e25c 0015 c419 bf82 adbc 1590 3119 ...\..........1. 0x0020: 8018 8102 5130 0000 0101 080a 41bb 85f7 ....Q0......A... 0x0030: 01de 4030 3135 302d 436f 6e6e 6563 7469 ..@0150-Connecti 0x0040: 6e67 2074 6f20 706f 7274 2036 3032 3634 ng.to.port.60264 0x0050: 0d0a 3135 3020 3531 392e 3220 6b62 7974 ..150.519.2.kbyt 0x0060: 6573 2074 6f20 646f 776e 6c6f 6164 0d0a es.to.download.. 14:40:50.535475 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 1:1349(1348) ack 1 win 33026 0x0000: 4508 0578 5b73 4000 4006 ab99 97a6 0f7d E..x[s@.@......} 0x0010: a4eb e25c 0014 eb68 56b8 db4f 6257 34a3 ...\...hV..ObW4. 0x0020: 8010 8102 f04d 0000 0101 080a 41bb 85f8 .....M......A... 0x0030: 01de 4031 3c3f 786d 6c20 7665 7273 696f ..@1.... 0x0070: 0a09 093c 446f 6375 6d65 6e74 4261 7365 ..... 0x0540: 0909 093c 5570 6772 6164 6553 7461 7475 ...0.... 14:40:50.836863 IP vvv.zzz.226.92.60264 > xxx.yyy.15.125.ftp-data: . ack 1349 win 8320 0x0000: 4500 0034 3495 0000 3406 23c4 a4eb e25c E..44...4.#....\ 0x0010: 97a6 0f7d eb68 0014 6257 34a3 56b8 e093 ...}.h..bW4.V... 0x0020: 8010 2080 644b 0000 0101 080a 01de 4031 ....dK........@1 0x0030: 41bb 85f8 A... 14:40:50.836869 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: . ack 958 win 17680 0x0000: 4500 0034 3496 0000 3406 23c3 a4eb e25c E..44...4.#....\ 0x0010: 97a6 0f7d c419 0015 1590 3119 bf82 adf8 ...}......1..... 0x0020: 8010 4510 812c 0000 0101 080a 01de 4031 ..E..,........@1 0x0030: 41bb 85f7 A... 14:40:50.836898 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 1349:2697(1348) ack 1 win 33026 0x0000: 4508 0578 5b84 4000 4006 ab88 97a6 0f7d E..x[.@.@......} 0x0010: a4eb e25c 0014 eb68 56b8 e093 6257 34a3 ...\...hV...bW4. 0x0020: 8010 8102 ff2b 0000 0101 080a 41bb 8725 .....+......A..% 0x0030: 01de 4031 0a09 093c 2f44 6f63 756d 656e ..@1... vvv.zzz.226.92.60264: . 2697:4045(1348) ack 1 win 33026 0x0000: 4508 0578 5b85 4000 4006 ab87 97a6 0f7d E..x[.@.@......} 0x0010: a4eb e25c 0014 eb68 56b8 e5d7 6257 34a3 ...\...hV...bW4. 0x0020: 8010 8102 3782 0000 0101 080a 41bb 8725 ....7.......A..% 0x0030: 01de 4031 436f 756e 7479 3e0a 0909 0909 ..@1County>..... . . . . 0x0560: 6e74 793e 0a09 0909 093c 436f 756e 7472 nty>..... vvv.zzz.226.92.60264: . 12133:13481(1348) ack 1 win 33026 0x0000: 4508 0578 5ba3 4000 4006 ab69 97a6 0f7d E..x[.@.@..i...} 0x0010: a4eb e25c 0014 eb68 56b9 0ab3 6257 34a3 ...\...hV...bW4. 0x0020: 8010 8102 6e62 0000 0101 080a 41bb 88b4 ....nb......A... 0x0030: 01de 4032 7970 653e 0a09 0909 093c 4869 ..@2ype>.....F 14:40:51.235665 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 13481:14829(1348) ack 1 win 33026 0x0000: 4508 0578 5ba4 4000 4006 ab68 97a6 0f7d E..x[.@.@..h...} 0x0010: a4eb e25c 0014 eb68 56b9 0ff7 6257 34a3 ...\...hV...bW4. 0x0020: 8010 8102 ed57 0000 0101 080a 41bb 88b4 .....W......A... 0x0030: 01de 4032 3246 3332 3337 3134 3441 313c ..@22F3237144A1< . . . . 0x0570: 7065 2044 6573 633d pe.Desc= 14:40:51.347938 IP vvv.zzz.226.92.60264 > xxx.yyy.15.125.ftp-data: . ack 12133 win 7646 0x0000: 4500 0034 35a5 0000 3406 22b4 a4eb e25c E..45...4."....\ 0x0010: 97a6 0f7d eb68 0014 6257 34a3 56b9 0ab3 ...}.h..bW4.V... 0x0020: 8010 1dde 3a49 0000 0101 080a 01de 4032 ....:I........@2 0x0030: 41bb 887b A..{ 14:40:51.347964 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 14829:16177(1348) ack 1 win 33026 0x0000: 4508 0578 5ba7 4000 4006 ab65 97a6 0f7d E..x[.@.@..e...} 0x0010: a4eb e25c 0014 eb68 56b9 153b 6257 34a3 ...\...hV..;bW4. 0x0020: 8010 8102 9673 0000 0101 080a 41bb 8924 .....s......A..$ . . . . . 0x0560: 093c 4368 6172 6163 7465 7269 7374 6963 ......< 14:40:51.347975 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 16177:17525(1348) ack 1 win 33026 0x0000: 4508 0578 5ba8 4000 4006 ab64 97a6 0f7d E..x[.@.@..d...} 0x0010: a4eb e25c 0014 eb68 56b9 1a7f 6257 34a3 ...\...hV...bW4. 0x0020: 8010 8102 a155 0000 0101 080a 41bb 8924 .....U......A..$ . . . . . 0x0570: 756d 6265 723e 3030 umber>00 14:40:51.347986 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 17525:18873(1348) ack 1 win 33026 0x0000: 4508 0578 5ba9 4000 4006 ab63 97a6 0f7d E..x[.@.@..c...} 0x0010: a4eb e25c 0014 eb68 56b9 1fc3 6257 34a3 ...\...hV...bW4. 0x0020: 8010 8102 e0d2 0000 0101 080a 41bb 8924 ............A..$ . . . . 0x0560: 3c2f 446f 6375 6d65 6e74 5479 7065 3e0a . 0x0570: 0909 0909 0909 3c4c ...... xxx.yyy.15.125.ftp-data: . ack 14829 win 7646 0x0000: 4500 0034 35b6 0000 3406 22a3 a4eb e25c E..45...4."....\ 0x0010: 97a6 0f7d eb68 0014 6257 34a3 56b9 153b ...}.h..bW4.V..; 0x0020: 8010 1dde 2f87 0000 0101 080a 01de 4033 ..../.........@3 0x0030: 41bb 88b4 A... 14:40:51.403931 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 18873:20221(1348) ack 1 win 33026 0x0000: 4508 0578 5bb2 4000 4006 ab5a 97a6 0f7d E..x[.@.@..Z...} 0x0010: a4eb e25c 0014 eb68 56b9 2507 6257 34a3 ...\...hV.%.bW4. 0x0020: 8010 8102 c5f3 0000 0101 080a 41bb 895c ............A..\ . . . . 0x0570: 6e22 3e34 394e 3c2f n">49N vvv.zzz.226.92.60264: . 20221:21569(1348) ack 1 win 33026 0x0000: 4508 0578 5bb3 4000 4006 ab59 97a6 0f7d E..x[.@.@..Y...} 0x0010: a4eb e25c 0014 eb68 56b9 2a4b 6257 34a3 ...\...hV.*KbW4. 0x0020: 8010 8102 108e 0000 0101 080a 41bb 895c ............A..\ . . . . 0x0570: 6f75 7263 654c 6567 ourceLeg 14:40:51.516465 IP vvv.zzz.226.92.60264 > xxx.yyy.15.125.ftp-data: . ack 17525 win 7646 0x0000: 4500 0034 35f4 0000 3406 2265 a4eb e25c E..45...4."e...\ 0x0010: 97a6 0f7d eb68 0014 6257 34a3 56b9 1fc3 ...}.h..bW4.V... 0x0020: 8010 1dde 248f 0000 0101 080a 01de 4033 ....$.........@3 0x0030: 41bb 8924 A..$ 14:40:51.516488 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 21569:22917(1348) ack 1 win 33026 0x0000: 4508 0578 5bb5 4000 4006 ab57 97a6 0f7d E..x[.@.@..W...} 0x0010: a4eb e25c 0014 eb68 56b9 2f8f 6257 34a3 ...\...hV./.bW4. 0x0020: 8010 8102 6b9e 0000 0101 080a 41bb 89cc ....k.......A... . . . . 0x0570: 3c2f 536f 7572 6365 vvv.zzz.226.92.60264: . 22917:24265(1348) ack 1 win 33026 0x0000: 4508 0578 5bb6 4000 4006 ab56 97a6 0f7d E..x[.@.@..V...} 0x0010: a4eb e25c 0014 eb68 56b9 34d3 6257 34a3 ...\...hV.4.bW4. 0x0020: 8010 8102 72de 0000 0101 080a 41bb 89cc ....r.......A... . . . . 0x0570: 0a09 0909 093c 4c65 ..... xxx.yyy.15.125.ftp-data: . ack 18873 win 8320 0x0000: 4500 0034 35f7 0000 3406 2262 a4eb e25c E..45...4."b...\ 0x0010: 97a6 0f7d eb68 0014 6257 34a3 56b9 2507 ...}.h..bW4.V.%. 0x0020: 8010 2080 1ca9 0000 0101 080a 01de 4033 ..............@3 0x0030: 41bb 8924 A..$ 14:40:51.516871 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 24265:25613(1348) ack 1 win 33026 0x0000: 4508 0578 5bb8 4000 4006 ab54 97a6 0f7d E..x[.@.@..T...} 0x0010: a4eb e25c 0014 eb68 56b9 3a17 6257 34a3 ...\...hV.:.bW4. 0x0020: 8010 8102 d6d6 0000 0101 080a 41bb 89cd ............A... . . . . 0x0570: 5346 2031 3434 393c SF.1449< 14:40:51.516883 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 25613:26961(1348) ack 1 win 33026 0x0000: 4508 0578 5bb9 4000 4006 ab53 97a6 0f7d E..x[.@.@..S...} 0x0010: a4eb e25c 0014 eb68 56b9 3f5b 6257 34a3 ...\...hV.?[bW4. 0x0020: 8010 8102 15e9 0000 0101 080a 41bb 89cd ............A... . . . . 0x0570: 313c 2f46 756c 6c54 1 xxx.yyy.15.125.ftp-data: . ack 21569 win 8320 0x0000: 4500 0034 3678 0000 3406 21e1 a4eb e25c E..46x..4.!....\ 0x0010: 97a6 0f7d eb68 0014 6257 34a3 56b9 2f8f ...}.h..bW4.V./. 0x0020: 8010 2080 11e9 0000 0101 080a 01de 4033 ..............@3 0x0030: 41bb 895c A..\ 14:40:51.573456 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 26961:28309(1348) ack 1 win 33026 0x0000: 4508 0578 5bbf 4000 4006 ab4d 97a6 0f7d E..x[.@.@..M...} 0x0010: a4eb e25c 0014 eb68 56b9 449f 6257 34a3 ...\...hV.D.bW4. 0x0020: 8010 8102 7a19 0000 0101 080a 41bb 8a05 ....z.......A... . . . . 0x0570: 0909 093c 4675 6c6c ... vvv.zzz.226.92.60264: . 28309:29657(1348) ack 1 win 33026 0x0000: 4508 0578 5bc0 4000 4006 ab4c 97a6 0f7d E..x[.@.@..L...} 0x0010: a4eb e25c 0014 eb68 56b9 49e3 6257 34a3 ...\...hV.I.bW4. 0x0020: 8010 8102 2f41 0000 0101 080a 41bb 8a05 ..../A......A... . . . . 0x0570: 303c 2f45 6469 7465 0 xxx.yyy.15.125.ftp-data: . ack 25613 win 7646 0x0000: 4500 0034 36ae 0000 3406 21ab a4eb e25c E..46...4.!....\ 0x0010: 97a6 0f7d eb68 0014 6257 34a3 56b9 3f5b ...}.h..bW4.V.?[ 0x0020: 8010 1dde 044f 0000 0101 080a 01de 4033 .....O........@3 0x0030: 41bb 89cc A... 14:40:51.688745 IP vvv.zzz.226.92.60264 > xxx.yyy.15.125.ftp-data: . ack 26961 win 8320 0x0000: 4500 0034 36b1 0000 3406 21a8 a4eb e25c E..46...4.!....\ 0x0010: 97a6 0f7d eb68 0014 6257 34a3 56b9 449f ...}.h..bW4.V.D. 0x0020: 8010 2080 fc67 0000 0101 080a 01de 4033 .....g........@3 0x0030: 41bb 89cd A... 14:40:51.688769 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 29657:31005(1348) ack 1 win 33026 0x0000: 4508 0578 5bd0 4000 4006 ab3c 97a6 0f7d E..x[.@.@..<...} 0x0010: a4eb e25c 0014 eb68 56b9 4f27 6257 34a3 ...\...hV.O'bW4. 0x0020: 8010 8102 a16e 0000 0101 080a 41bb 8a79 .....n......A..y . . . . 0x0570: 4675 6c6c 5465 7874 FullText 14:40:51.688780 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 31005:32353(1348) ack 1 win 33026 0x0000: 4508 0578 5bd1 4000 4006 ab3b 97a6 0f7d E..x[.@.@..;...} 0x0010: a4eb e25c 0014 eb68 56b9 546b 6257 34a3 ...\...hV.TkbW4. 0x0020: 8010 8102 4dc2 0000 0101 080a 41bb 8a79 ....M.......A..y . . . . 0x0570: 6167 3e31 3c2f 4675 ag>1 vvv.zzz.226.92.60264: . 32353:33701(1348) ack 1 win 33026 0x0000: 4508 0578 5bd3 4000 4006 ab39 97a6 0f7d E..x[.@.@..9...} 0x0010: a4eb e25c 0014 eb68 56b9 59af 6257 34a3 ...\...hV.Y.bW4. 0x0020: 8010 8102 04bc 0000 0101 080a 41bb 8a79 ............A..y . . . . 0x0570: 636c 7564 6564 3e30 cluded>0 14:40:51.688813 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 33701:35049(1348) ack 1 win 33026 0x0000: 4508 0578 5bd4 4000 4006 ab38 97a6 0f7d E..x[.@.@..8...} 0x0010: a4eb e25c 0014 eb68 56b9 5ef3 6257 34a3 ...\...hV.^.bW4. 0x0020: 8010 8102 924b 0000 0101 080a 41bb 8a79 .....K......A..y . . . . 0x0570: 0909 0909 093c 4f72 ..... xxx.yyy.15.125.ftp-data: . ack 29657 win 8320 0x0000: 4500 0034 36c2 0000 3406 2197 a4eb e25c E..46...4.!....\ 0x0010: 97a6 0f7d eb68 0014 6257 34a3 56b9 4f27 ...}.h..bW4.V.O' 0x0020: 8010 2080 f1a7 0000 0101 080a 01de 4033 ..............@3 0x0030: 41bb 8a05 A... 14:40:51.743733 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 35049:36397(1348) ack 1 win 33026 0x0000: 4508 0578 5bd6 4000 4006 ab36 97a6 0f7d E..x[.@.@..6...} 0x0010: a4eb e25c 0014 eb68 56b9 6437 6257 34a3 ...\...hV.d7bW4. 0x0020: 8010 8102 a4d9 0000 0101 080a 41bb 8ab0 ............A... . . . . 0x0570: 6972 6564 436f 6465 iredCode 14:40:51.743743 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 36397:37745(1348) ack 1 win 33026 0x0000: 4508 0578 5bd7 4000 4006 ab35 97a6 0f7d E..x[.@.@..5...} 0x0010: a4eb e25c 0014 eb68 56b9 697b 6257 34a3 ...\...hV.i{bW4. 0x0020: 8010 8102 5eaf 0000 0101 080a 41bb 8ab0 ....^.......A... . . . . . 0x0570: 6265 723e 3532 2e32 ber>52.2 14:40:51.859264 IP vvv.zzz.226.92.60264 > xxx.yyy.15.125.ftp-data: . ack 33701 win 7646 0x0000: 4500 0034 36fd 0000 3406 215c a4eb e25c E..46...4.!\...\ 0x0010: 97a6 0f7d eb68 0014 6257 34a3 56b9 5ef3 ...}.h..bW4.V.^. 0x0020: 8010 1dde e409 0000 0101 080a 01de 4033 ..............@3 0x0030: 41bb 8a79 A..y 14:40:51.859270 IP vvv.zzz.226.92.60264 > xxx.yyy.15.125.ftp-data: . ack 35049 win 7646 0x0000: 4500 0034 3700 0000 3406 2159 a4eb e25c E..47...4.!Y...\ 0x0010: 97a6 0f7d eb68 0014 6257 34a3 56b9 6437 ...}.h..bW4.V.d7 0x0020: 8010 1dde dec5 0000 0101 080a 01de 4033 ..............@3 0x0030: 41bb 8a79 A..y 14:40:51.859298 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 37745:39093(1348) ack 1 win 33026 0x0000: 4508 0578 5be0 4000 4006 ab2c 97a6 0f7d E..x[.@.@..,...} 0x0010: a4eb e25c 0014 eb68 56b9 6ebf 6257 34a3 ...\...hV.n.bW4. 0x0020: 8010 8102 bdcf 0000 0101 080a 41bb 8b23 ............A..# . . . . 0x0570: 3e0a 0909 0909 0909 >....... 14:40:51.859310 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 39093:40441(1348) ack 1 win 33026 0x0000: 4508 0578 5be1 4000 4006 ab2b 97a6 0f7d E..x[.@.@..+...} 0x0010: a4eb e25c 0014 eb68 56b9 7403 6257 34a3 ...\...hV.t.bW4. 0x0020: 8010 8102 6678 0000 0101 080a 41bb 8b23 ....fx......A..# . . . . . 0x0570: 653e 0a09 0909 0909 e>...... 14:40:51.859332 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . 40441:41789(1348) ack 1 win 33026 0x0000: 4508 0578 5be3 4000 4006 ab29 97a6 0f7d E..x[.@.@..)...} 0x0010: a4eb e25c 0014 eb68 56b9 7947 6257 34a3 ...\...hV.yGbW4. 0x0020: 8010 8102 4e19 0000 0101 080a 41bb 8b23 ....N.......A..# . . . . 0x0570: 696c 6c49 6e46 6c61 illInFla 14:40:51.859342 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: FP 41789:42489(700) ack 1 win 33026 0x0000: 4508 02f0 5be4 4000 4006 adb0 97a6 0f7d E...[.@.@......} 0x0010: a4eb e25c 0014 eb68 56b9 7e8b 6257 34a3 ...\...hV.~.bW4. 0x0020: 8019 8102 90af 0000 0101 080a 41bb 8b23 ............A..# . . . . 0x02e0: 4e75 6d62 6572 3e35 363c 2f4f 7264 6572 Number>56 xxx.yyy.15.125.ftp-data: . ack 37745 win 7646 0x0000: 4500 0034 3711 0000 3406 2148 a4eb e25c E..47...4.!H...\ 0x0010: 97a6 0f7d eb68 0014 6257 34a3 56b9 6ebf ...}.h..bW4.V.n. 0x0020: 8010 1dde d405 0000 0101 080a 01de 4034 ..............@4 0x0030: 41bb 8ab0 A... 14:40:52.029164 IP vvv.zzz.226.92.60264 > xxx.yyy.15.125.ftp-data: . ack 40441 win 7646 0x0000: 4500 0034 3744 0000 3406 2115 a4eb e25c E..47D..4.!....\ 0x0010: 97a6 0f7d eb68 0014 6257 34a3 56b9 7947 ...}.h..bW4.V.yG 0x0020: 8010 1dde c90a 0000 0101 080a 01de 4034 ..............@4 0x0030: 41bb 8b23 A..# 14:40:52.029170 IP vvv.zzz.226.92.60264 > xxx.yyy.15.125.ftp-data: . ack 42490 win 7296 0x0000: 4500 0034 3748 0000 3406 2111 a4eb e25c E..47H..4.!....\ 0x0010: 97a6 0f7d eb68 0014 6257 34a3 56b9 8148 ...}.h..bW4.V..H 0x0020: 8010 1c80 c267 0000 0101 080a 01de 4034 .....g........@4 0x0030: 41bb 8b23 A..# 14:40:52.029173 IP vvv.zzz.226.92.60264 > xxx.yyy.15.125.ftp-data: F 1:1(0) ack 42490 win 8840 0x0000: 4500 0034 3749 0000 3406 2110 a4eb e25c E..47I..4.!....\ 0x0010: 97a6 0f7d eb68 0014 6257 34a3 56b9 8148 ...}.h..bW4.V..H 0x0020: 8011 2288 bc5e 0000 0101 080a 01de 4034 .."..^........@4 0x0030: 41bb 8b23 A..# 14:40:52.029206 IP xxx.yyy.15.125.ftp-data > vvv.zzz.226.92.60264: . ack 2 win 33025 0x0000: 4508 0034 5be9 4000 4006 b067 97a6 0f7d E..4[.@.@..g...} 0x0010: a4eb e25c 0014 eb68 56b9 8148 6257 34a4 ...\...hV..HbW4. 0x0020: 8010 8101 5d3b 0000 0101 080a 41bb 8bcd ....];......A... 0x0030: 01de 4034 ..@4 14:41:37.043508 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: F 298:298(0) ack 958 win 17680 0x0000: 4500 0034 7376 0000 3406 e4e2 a4eb e25c E..4sv..4......\ 0x0010: 97a6 0f7d c419 0015 1590 3119 bf82 adf8 ...}......1..... 0x0020: 8011 4510 80ce 0000 0101 080a 01de 408e ..E...........@. 0x0030: 41bb 85f7 A... 14:41:37.043534 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: . ack 299 win 33026 0x0000: 4510 0034 64ad 4000 4006 a79b 97a6 0f7d E..4d.@.@......} 0x0010: a4eb e25c 0015 c419 bf82 adf8 1590 311a ...\..........1. 0x0020: 8010 8102 8f3b 0000 0101 080a 41bc 3b97 .....;......A.;. 0x0030: 01de 408e ..@. 14:41:37.043594 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: P 958:971(13) ack 299 win 33026 0x0000: 4510 0041 64ae 4000 4006 a78d 97a6 0f7d E..Ad.@.@......} 0x0010: a4eb e25c 0015 c419 bf82 adf8 1590 311a ...\..........1. 0x0020: 8018 8102 cc70 0000 0101 080a 41bc 3b97 .....p......A.;. 0x0030: 01de 408e 3135 3020 4c6f 676f 7574 2e0d ..@.150.Logout.. 0x0040: 0a . 14:41:37.043726 IP xxx.yyy.15.125.ftp > vvv.zzz.226.92.50201: F 971:971(0) ack 299 win 33026 0x0000: 4510 0034 64af 4000 4006 a799 97a6 0f7d E..4d.@.@......} 0x0010: a4eb e25c 0015 c419 bf82 ae05 1590 311a ...\..........1. 0x0020: 8011 8102 8f2d 0000 0101 080a 41bc 3b97 .....-......A.;. 0x0030: 01de 408e ..@. 14:41:37.211160 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: R 361771290:361771290(0) win 0 0x0000: 4500 0028 73a4 0000 3406 e4c0 a4eb e25c E..(s...4......\ 0x0010: 97a6 0f7d c419 0015 1590 311a 0000 0000 ...}......1..... 0x0020: 5004 0000 769c 0000 0000 0000 0000 P...v......... 14:41:37.211166 IP vvv.zzz.226.92.50201 > xxx.yyy.15.125.ftp: R 361771290:361771290(0) win 0 0x0000: 4500 0028 73a5 0000 3406 e4bf a4eb e25c E..(s...4......\ 0x0010: 97a6 0f7d c419 0015 1590 311a 0000 0000 ...}......1..... 0x0020: 5004 0000 769c 0000 0000 0000 0000 P...v......... From owner-freebsd-pf@FreeBSD.ORG Thu Jan 7 17:13:14 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A5A61065698 for ; Thu, 7 Jan 2010 17:13:14 +0000 (UTC) (envelope-from gofdp-freebsd-pf@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B6D818FC08 for ; Thu, 7 Jan 2010 17:13:13 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NSvv5-0005LN-6f for freebsd-pf@freebsd.org; Thu, 07 Jan 2010 18:13:11 +0100 Received: from 207.155.204.151.ptr.us.xo.net ([207.155.204.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Jan 2010 18:13:11 +0100 Received: from atkin901 by 207.155.204.151.ptr.us.xo.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Jan 2010 18:13:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-pf@freebsd.org From: Mark Atkinson Date: Thu, 07 Jan 2010 09:12:48 -0800 Lines: 23 Message-ID: References: <7731938b1001060923n5de4b511of07b8c63cff4e011@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 207.155.204.151.ptr.us.xo.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100104 Thunderbird/3.0 In-Reply-To: Sender: news Subject: Re: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:13:14 -0000 On 01/06/10 13:40, M. Keith Thompson wrote: > 14:40:49.329499 IP vvv.zzz.226.92.50201> xxx.yyy.15.125.ftp: P > 80:105(25) ack 755 win 17680 > 0x0000: 4500 004d 3160 0000 3406 26e0 a4eb e25c E..M1`..4.&....\ > 0x0010: 97a6 0f7d c419 0015 1590 303f bf82 ad2d ...}......0?...- > 0x0020: 8018 4510 fbea 0000 0101 080a 01de 402e ..E...........@. > . > . > 14:40:49.498480 IP xxx.yyy.15.125.ftp> vvv.zzz.226.92.50201: P > 785:807(22) ack 105 win 33026 > 0x0000: 4510 004a 5b38 4000 4006 b0fa 97a6 0f7d E..J[8@.@......} > 0x0010: a4eb e25c 0015 c419 bf82 ad4b 1590 3058 ...\.......K..0X > 0x0020: 8018 8102 67f6 0000 0101 080a 41bb 81eb ....g.......A... > 0x0030: 01de 402e 3232 3620 3134 206d 6174 6368 ..@.226.14.match > 0x0040: 6573 2074 6f74 616c 0d0a es.total.. So this doesn't look like the result of a 'RETR' command, but maybe a 'LIST'? The transfer appears successful, and the following trace, despite the one side ignoring the 150 logout, appears to transfer successfully too. I'm not seeing any problem in the trace, but the hp client complains after this transfer? From owner-freebsd-pf@FreeBSD.ORG Thu Jan 7 18:26:55 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1A33106568B for ; Thu, 7 Jan 2010 18:26:55 +0000 (UTC) (envelope-from m.keith.thompson@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 67C548FC13 for ; Thu, 7 Jan 2010 18:26:55 +0000 (UTC) Received: by bwz5 with SMTP id 5so11911167bwz.3 for ; Thu, 07 Jan 2010 10:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=wrPmzKdiND1dUJpuH7uB4pSqGF+zUPZQ324xk6OVtrU=; b=LyvuJA6zgaGu6NG5PLU4kZYe+B26G3pVjhOzFESGFaPL95ZO8emV3vQ4J5k5Yqe5Gc FcZPS9/rAnp6HN+v0hW6TqKoqqvpX425XcBORuhobooktk64NV3x/OnIQOTO36vpomTl 6DupC7cG8eNa0DHZJJGw2WQZQ2j1HEnshCDAE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NMYkWLspfWcjFz/8o6aki09hD01EgN3hL2pv0CTw4is+nQpxpmLFSsB+SiO5bQz8s0 MhsqLlcwFqcbm23WNDk2FuvLwtTcBt3pQ7NeeswLYnnpN78Tt0UXzv1WSYbT1Xmcr9i0 GRlIoi++mxeeyobeqiPXxXtWPYceTRqKUO6vQ= MIME-Version: 1.0 Received: by 10.204.29.16 with SMTP id o16mr1156873bkc.26.1262888808167; Thu, 07 Jan 2010 10:26:48 -0800 (PST) Date: Thu, 7 Jan 2010 12:26:48 -0600 Message-ID: From: "M. Keith Thompson" To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 18:26:55 -0000 It does a list first to see which file to get. Then it tries to download the 1st file. It starts downloading the file around: 14:40:49.668739 From owner-freebsd-pf@FreeBSD.ORG Thu Jan 7 21:02:51 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79C9510656A4 for ; Thu, 7 Jan 2010 21:02:51 +0000 (UTC) (envelope-from j65nko@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 0F1368FC25 for ; Thu, 7 Jan 2010 21:02:50 +0000 (UTC) Received: by ewy26 with SMTP id 26so17105561ewy.3 for ; Thu, 07 Jan 2010 13:02:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0/c3S5juV8H1Q3VX5QvsxRtc62yZgFFnxSlpX4Pqszw=; b=HWnzCCrRr+5dcW5VgL5xFMuR3eQMakh3OEV0Lnob0Y16beAbX+q+j3h3l8lvhIJE5Y bboBtHeDVzh/06m2OiKuKF+UFRit+fWmKDc/8V5eVKsqDwMQIwy9zSy3KXgizI5Hfdw3 hO2c4YeAZNvJfw6atTHPdnGRcCn5MzMLlcw6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Wsn07/CNRlroFVNwLzCZXH0n6MTrIpWckUgnbzUgkLIi72lwRDVAebqzTO1rmwIjz3 bD0zNicwTaDbluE5j5RnYA/yMuHTpWZl8rHt6JvzOw30qHQ2Yz+l7AHbcBvfKcgR4lYW 3UsF5taNgMsWesNs4sKxGvksnp56BPzONqAhA= MIME-Version: 1.0 Received: by 10.213.23.144 with SMTP id r16mr10182940ebb.41.1262896647329; Thu, 07 Jan 2010 12:37:27 -0800 (PST) In-Reply-To: <2cf1d0681001071216p6b516e9egcf7401f2b38e3c3d@mail.gmail.com> References: <7731938b1001060923n5de4b511of07b8c63cff4e011@mail.gmail.com> <2cf1d0681001071216p6b516e9egcf7401f2b38e3c3d@mail.gmail.com> Date: Thu, 7 Jan 2010 21:37:27 +0100 Message-ID: <19861fba1001071237ncc440d5u1ab280d2aaf0c72f@mail.gmail.com> From: J65nko To: "M. Keith Thompson" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-pf@freebsd.org Subject: Re: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 21:02:51 -0000 > # SSH from NetEng subnet > pass in quick log on $ext_if proto tcp from $net_eng to $ext_if port > 22 keep state > > # Allow inside network to ping the server > pass in quick on $ext_if proto icmp from $pingers to $ext_IP keep state > > # Allow DNS lookups > pass out quick on $ext_if proto udp to any port 53 > pass out quick on $ext_if proto tcp to any port 53 keep state > > # Allow ftp > pass in quick on $ext_if proto tcp from any to $ext_IP port 21 keep state > pass in quick on $ext_if proto tcp from any to $ext_IP port > 49151 keep state > pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP > port 20 keep state > > --- end of pf.conf ---------------------- To prevent problems with TCP window scaling you should create state on only the first packet of the 3 way TCP handshake, the packet with only the Syn flag set. With pf you do this by using 'keep state flags S/SA". This TCP window scaling issue is explained by Daniel Hartmeier, pf hacker, in http://undeadly.org/cgi?action=article&sid=20060928081238 under the section "Create TCP states on the initial SYN packet" BTW I wonder why you don't use the pf ftp-proxy, and why you allow active ftp transfers ;) From owner-freebsd-pf@FreeBSD.ORG Thu Jan 7 21:19:56 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C46361065670 for ; Thu, 7 Jan 2010 21:19:56 +0000 (UTC) (envelope-from m.keith.thompson@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 53BC98FC08 for ; Thu, 7 Jan 2010 21:19:55 +0000 (UTC) Received: by bwz5 with SMTP id 5so12026973bwz.3 for ; Thu, 07 Jan 2010 13:19:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=g0EfjdyM4F7yAeqhgIWpSzMRj4ppUgm65iU6KTrUi8U=; b=jeWOyW5DbLbeFPgewtodNme6+RqGNX0X9XgQY0r6WFe1OFxuQ3kMFhNd2RnrILOswo 8lNbJO+20naGERByz++nsYnF11MNOp2OVMwpP4MhqxYR+Ty2OjwrfCMpmTrvdraB2Cbg L2OSAg7t6rxW9OIDkLzI7qIPgDKDHIjNOD+b4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=jhr7go4FGsEOWm+9g6Yp3usAkGjTbgFeiW5Wv4Iy6Vk+ngd75m/r8DTi+H5VzKvpuO 4k3hFZxNNWIzD7pW/a91zEOfKUgxzXM7bHe+AkuH9OwcL0WqW/TdqOQMXIlF0Sv6x5Oy ZVEJ7tm0ipiXWstKnVUkXddopvg6uG61I9rAg= MIME-Version: 1.0 Received: by 10.204.18.212 with SMTP id x20mr3680702bka.9.1262899191908; Thu, 07 Jan 2010 13:19:51 -0800 (PST) In-Reply-To: <19861fba1001071237ncc440d5u1ab280d2aaf0c72f@mail.gmail.com> References: <7731938b1001060923n5de4b511of07b8c63cff4e011@mail.gmail.com> <2cf1d0681001071216p6b516e9egcf7401f2b38e3c3d@mail.gmail.com> <19861fba1001071237ncc440d5u1ab280d2aaf0c72f@mail.gmail.com> Date: Thu, 7 Jan 2010 15:19:50 -0600 Message-ID: From: "M. Keith Thompson" To: J65nko , freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 21:19:56 -0000 On Thu, Jan 7, 2010 at 2:37 PM, J65nko wrote: >> # SSH from NetEng subnet >> pass in quick log on $ext_if proto tcp from $net_eng to $ext_if port >> 22 keep state >> >> # Allow inside network to ping the server >> pass in quick on $ext_if proto icmp from $pingers to $ext_IP keep state >> >> # Allow DNS lookups >> pass out quick on $ext_if proto udp to any port 53 >> pass out quick on $ext_if proto tcp to any port 53 keep state >> >> # Allow ftp >> pass in quick on $ext_if proto tcp from any to $ext_IP port 21 keep stat= e >> pass in quick on $ext_if proto tcp from any to $ext_IP port > 49151 keep= state >> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP >> port 20 keep state >> >> --- end of pf.conf =A0---------------------- > > To prevent problems with TCP window scaling you should create state on > only the first packet > of the 3 way TCP handshake, the packet with only the Syn flag set. > > With pf you do this by using 'keep state flags S/SA". > > This TCP window scaling issue is explained by Daniel Hartmeier, pf > hacker, in http://undeadly.org/cgi?action=3Darticle&sid=3D20060928081238 > under the section > "Create TCP states on the initial SYN packet" > > BTW I wonder why you don't use the pf ftp-proxy, and why you allow > active ftp transfers ;) > Changed the three ftp pass rules to "flags S/SA"; still no love. I was not using the proxy because there is no NAT involved. I will try adding the pf ftp-proxy. I am forced by user requirments to allow active transfers. Thanks for all of the input! From owner-freebsd-pf@FreeBSD.ORG Thu Jan 7 21:47:22 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD5D4106566B for ; Thu, 7 Jan 2010 21:47:22 +0000 (UTC) (envelope-from gofdp-freebsd-pf@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 96E438FC18 for ; Thu, 7 Jan 2010 21:47:22 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NT0CN-0006dg-M7 for freebsd-pf@freebsd.org; Thu, 07 Jan 2010 22:47:19 +0100 Received: from 207.155.204.151.ptr.us.xo.net ([207.155.204.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Jan 2010 22:47:19 +0100 Received: from atkin901 by 207.155.204.151.ptr.us.xo.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Jan 2010 22:47:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-pf@freebsd.org From: Mark Atkinson Date: Thu, 07 Jan 2010 13:46:56 -0800 Lines: 20 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 207.155.204.151.ptr.us.xo.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100104 Thunderbird/3.0 In-Reply-To: Sender: news Subject: Re: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 21:47:22 -0000 On 01/07/10 10:26, M. Keith Thompson wrote: > It does a list first to see which file to get. Then it tries to > download the 1st file. > > It starts downloading the file around: > > 14:40:49.668739 Yep, I see that, the only anomoly is no '226 transfer complete' on the command channel after the Fin + PSH from the server to the client. Not sure if this is the complete set data transferred or not, you maybe able to tell looking at the complete trace. The client finishes acking the rest of the data and then sends it's FIN as well, then the client closes the command channel and we see the 150 logout. I would suggest loading up the pcap in wireshark and look at the tcp analysis to see if it notes anything unusual in the sequence numbers, sizes, retransmits, etc that might be causing a problem. From owner-freebsd-pf@FreeBSD.ORG Thu Jan 7 22:51:55 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC513106568D for ; Thu, 7 Jan 2010 22:51:55 +0000 (UTC) (envelope-from webmaster@absolutenetworks.biz) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id BF0B28FC25 for ; Thu, 7 Jan 2010 22:51:55 +0000 (UTC) Received: by pxi12 with SMTP id 12so12600286pxi.3 for ; Thu, 07 Jan 2010 14:51:44 -0800 (PST) MIME-Version: 1.0 Sender: webmaster@absolutenetworks.biz Received: by 10.143.26.42 with SMTP id d42mr7526532wfj.219.1262903260157; Thu, 07 Jan 2010 14:27:40 -0800 (PST) From: Kurt Turner Date: Thu, 7 Jan 2010 16:27:20 -0600 X-Google-Sender-Auth: 75a4bca7094dd367 Message-ID: <40fc01eb1001071427g335634c9u1ffa8aacba1360f3@mail.gmail.com> To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: freebsd 8 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 22:51:55 -0000 Hello all In an effort not to create yet another insecure server on the www I'd like to ensure my pf.conf file is good and secure - will someone please review this configuration and let me know your thoughts? I only want to allow www and ssh inbound and have limited access also outbound - this is a remote web server I do not have access to at all. TIA #### First declare a couple of variables #### # outgoing services tcp_services = "{ ssh, smtp, domain, www, https, ntp, 43}" udp_services = "{ domain, ntp }" martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4 }" ext_if = "re0" # Internet #### Normalization scrub in all #### Start filtering # Drop incoming everything block in all # Default connection refused message to client block return # keep stats of outging connections pass out keep state # activate spoofing protection for all interfaces block in quick from urpf-failed # Antispoof is a common special case of filtering and blocking. This mechanism protects against activity from spoofed or forged IP addresses antispoof log for $ext_if #Block RFC 1918 addresses block drop in log (all) quick on $ext_if from $martians to any block drop out log (all) quick on $ext_if from any to $martians # Allow outgoing via ssh, smtp, domain, www, https, whois etc pass out on $ext_if proto tcp to any port $tcp_services pass out on $ext_if proto udp to any port $udp_services # Allow outgoing Trace route pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep state # Allow http traffic pass in on $ext_if proto tcp from any to any port 80 flags S/SA synproxy modulate state # SSH pass in on $ext_if proto tcp from any to any port 22 flags S/SA synproxy modulate state From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 01:58:45 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1C9E1065676 for ; Fri, 8 Jan 2010 01:58:45 +0000 (UTC) (envelope-from pgoggins@carrollu.edu) Received: from Mail-1.carrollu.edu (mail-1.carrollu.edu [140.104.8.80]) by mx1.freebsd.org (Postfix) with ESMTP id 73F3A8FC14 for ; Fri, 8 Jan 2010 01:58:45 +0000 (UTC) Received: from CMAIL.carrollu.edu ([fe80::dca9:63d7:73cb:2beb]) by Mail-1.carrollu.edu ([2002:8c68:850::8c68:850]) with mapi; Thu, 7 Jan 2010 19:46:53 -0600 From: Patrick Goggins To: "freebsd-pf@freebsd.org" Date: Thu, 7 Jan 2010 19:46:48 -0600 Thread-Topic: freebsd 8 Thread-Index: AcqP6/mxBP2L48jOR3+gibh1A5guUQAF+Neg Message-ID: <23E3A2C29073ED4CB8EAEA459791FD7A0868CA4C9F@CMAIL.carrollu.edu> References: <40fc01eb1001071427g335634c9u1ffa8aacba1360f3@mail.gmail.com> In-Reply-To: <40fc01eb1001071427g335634c9u1ffa8aacba1360f3@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: freebsd 8 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 01:58:45 -0000 I would not recommend allowing everyone under the sun ssh access to the box= . Either restrict it by outside IP if possible and if that is not possible = at least alter the port to prevent bots. ~Patrick -----Original Message----- From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On= Behalf Of Kurt Turner Sent: Thursday, January 07, 2010 4:27 PM To: freebsd-pf@freebsd.org Subject: freebsd 8 Hello all In an effort not to create yet another insecure server on the www I'd like to ensure my pf.conf file is good and secure - will someone please review this configuration and let me know your thoughts? I only want to allow www and ssh inbound and have limited access also outbound - this is a remote web server I do not have access to at all. TIA #### First declare a couple of variables #### # outgoing services tcp_services =3D "{ ssh, smtp, domain, www, https, ntp, 43}" udp_services =3D "{ domain, ntp }" martians =3D "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4 }" ext_if =3D "re0" # Internet #### Normalization scrub in all #### Start filtering # Drop incoming everything block in all # Default connection refused message to client block return # keep stats of outging connections pass out keep state # activate spoofing protection for all interfaces block in quick from urpf-failed # Antispoof is a common special case of filtering and blocking. This mechanism protects against activity from spoofed or forged IP addresses antispoof log for $ext_if #Block RFC 1918 addresses block drop in log (all) quick on $ext_if from $martians to any block drop out log (all) quick on $ext_if from any to $martians # Allow outgoing via ssh, smtp, domain, www, https, whois etc pass out on $ext_if proto tcp to any port $tcp_services pass out on $ext_if proto udp to any port $udp_services # Allow outgoing Trace route pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep state # Allow http traffic pass in on $ext_if proto tcp from any to any port 80 flags S/SA synproxy modulate state # SSH pass in on $ext_if proto tcp from any to any port 22 flags S/SA synproxy modulate state _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 04:18:57 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B575106566B for ; Fri, 8 Jan 2010 04:18:57 +0000 (UTC) (envelope-from j65nko@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id F27168FC08 for ; Fri, 8 Jan 2010 04:18:56 +0000 (UTC) Received: by ewy26 with SMTP id 26so17433462ewy.3 for ; Thu, 07 Jan 2010 20:18:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0QHRlk6QTZUyd+j3WJ16d3l2i+0Q7B+Z9Dp+p1gHPw8=; b=JinLNnt5XDIKlLCiODXTSGj+/TejtxdwaYfRcL9ZqAxEDiMJuvOeIeCl9hxP2XM8ef rj5HDIC8u3a9QZWF5aPjD2V7bzieBkZk3MKodNndcsIFYd1SrD+6zPhbqtIW8XLPrevM nxy6S5Ws9ADIPE+V6FMdEYrd3ay6rMfs5EbI8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ka6J+j+U68JpN+C152NZTokbTB115CePgd5QvLJFx5ox/XMcghwrTzNQ07GoCtjT/p 94jO8fz3x6HMZqKvzqRAc7vtEaQigpmPrns2+xqxN8IcCckPer5TVMHBcj9DTptZKlif 7U5FNN75b3yabkGi0Bv4AKlAJ+3B4bcna2dvQ= MIME-Version: 1.0 Received: by 10.213.100.145 with SMTP id y17mr781446ebn.27.1262924328853; Thu, 07 Jan 2010 20:18:48 -0800 (PST) In-Reply-To: References: <7731938b1001060923n5de4b511of07b8c63cff4e011@mail.gmail.com> <2cf1d0681001071216p6b516e9egcf7401f2b38e3c3d@mail.gmail.com> <19861fba1001071237ncc440d5u1ab280d2aaf0c72f@mail.gmail.com> Date: Fri, 8 Jan 2010 05:18:48 +0100 Message-ID: <19861fba1001072018g115a0bccrf9510a38454cc9db@mail.gmail.com> From: J65nko To: "M. Keith Thompson" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-pf@freebsd.org Subject: Re: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 04:18:57 -0000 On Thu, Jan 7, 2010 at 10:19 PM, M. Keith Thompson wrote: > On Thu, Jan 7, 2010 at 2:37 PM, J65nko wrote: >>> # SSH from NetEng subnet >>> pass in quick log on $ext_if proto tcp from $net_eng to $ext_if port >>> 22 keep state >>> >>> # Allow inside network to ping the server >>> pass in quick on $ext_if proto icmp from $pingers to $ext_IP keep state >>> >>> # Allow DNS lookups >>> pass out quick on $ext_if proto udp to any port 53 >>> pass out quick on $ext_if proto tcp to any port 53 keep state >>> >>> # Allow ftp >>> pass in quick on $ext_if proto tcp from any to $ext_IP port 21 keep state >>> pass in quick on $ext_if proto tcp from any to $ext_IP port > 49151 keep state >>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP >>> port 20 keep state >>> >>> --- end of pf.conf ---------------------- With ftp the client initiates the ftp command channel client:port >1023 ---> server:port 21 The passive ftp data channel is initiated by the client client:port >1023 ---> server:port>1023 Your second rule takes care of this The active ftp data channel is initiated by the ftp server using and that is kind of weird, port 20 (ftp-data), as source port. server:port 20 ---> clientLport >1023 You meant to pass active ftp with this rule: >>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP >>> port 20 keep state But it should be: pass out quick on $ext_if inet proto tcp from any port ftp-data to $ext_IP port > 10000 keep state BTW you have a nice pf debug friendly "block log all" default policy. Does "tcpdump -eni pflog0" on the pf box show any blocked packets? RE: ftp-proxy This just adds complexitiy, after everything is working you could add it in. RE: active ftp user requirement Yes, I understand, it is the users who help us pay our mortgage ;) From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 05:31:13 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B91331065693 for ; Fri, 8 Jan 2010 05:31:13 +0000 (UTC) (envelope-from fbsdq@peterk.org) Received: from poshta.pknet.net (poshta.pknet.net [216.241.167.213]) by mx1.freebsd.org (Postfix) with ESMTP id 6120C8FC13 for ; Fri, 8 Jan 2010 05:31:13 +0000 (UTC) Received: (qmail 61254 invoked by uid 89); 8 Jan 2010 05:04:34 -0000 Received: from poshta.pknet.net (HELO pop.pknet.net) (216.241.167.213) by poshta.pknet.net with SMTP; 8 Jan 2010 05:04:34 -0000 Received: from 216.241.167.213 (SquirrelMail authenticated user fbsdq@peterk.org) by pop.pknet.net with HTTP; Thu, 7 Jan 2010 22:04:34 -0700 Message-ID: <25cb73eeb5cb6830aefd1164b23e82b8.squirrel@pop.pknet.net> Date: Thu, 7 Jan 2010 22:04:34 -0700 From: "Peter" To: freebsd-pf@freebsd.org User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: setfib + pf + synproxy not working X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 05:31:13 -0000 iH, Playing around with FIBs and jails. The host system is on a private 172.xxx network with a gateway of 172.xxx going through a NAT box for internet. [fib 0] The jail has only a public IP, on fib 1 [with gateway being ISP router] With this, the jail is working fine. What I'm trying to accomplish is portknocking for 'ssh' access: pass in log quick proto tcp from any to any port {1234} synproxy state \ (max-src-conn-rate 5/15, overload ) Because the jail is on 'fib 1', the connection is never established to overload the rule. The 'synproxy state' is communicating via the 172.xxxx/default gateway [of fib 0] instead of via the public "fib 1" I can ssh into the jail if I do pass in log quick proto tcp from any to any port {22} keep state I CANNOT ssh into the jail if I do pass in log quick proto tcp from any to any port {22} synproxy state Anyway I can force 'synproxy' to communicate via fib 1 ? ]Peter[ From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 05:55:46 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59AF3106566C for ; Fri, 8 Jan 2010 05:55:46 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id E65EB8FC0A for ; Fri, 8 Jan 2010 05:55:45 +0000 (UTC) Received: from vampire.homelinux.org (dslb-088-066-050-238.pools.arcor-ip.net [88.66.50.238]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MRB6N-1NL7BX34xj-00U2Zl; Fri, 08 Jan 2010 06:55:44 +0100 Received: (qmail 94212 invoked from network); 8 Jan 2010 05:55:44 -0000 Received: from f8x64.laiers.local (192.168.4.188) by ns1.laiers.local with SMTP; 8 Jan 2010 05:55:44 -0000 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Fri, 8 Jan 2010 06:55:43 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-RELEASE; KDE/4.3.4; amd64; ; ) References: <25cb73eeb5cb6830aefd1164b23e82b8.squirrel@pop.pknet.net> In-Reply-To: <25cb73eeb5cb6830aefd1164b23e82b8.squirrel@pop.pknet.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001080655.43652.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18N6Ew4xDhHtQJuWd5yhzHJV6Cu8O2BLmjYgJ7 D+5LBEJJMPS+WqIuQfbm/hCyxo59+Q6/G9iyyYTiG3OFTNn26c aaFVksyHiTcCxteDoOrDQ== Cc: Subject: Re: setfib + pf + synproxy not working X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 05:55:46 -0000 On Friday 08 January 2010 06:04:34 Peter wrote: > iH, > Playing around with FIBs and jails. > > The host system is on a private 172.xxx network with a gateway of 172.xxx > going through a NAT box for internet. [fib 0] > > The jail has only a public IP, on fib 1 [with gateway being ISP router] > > With this, the jail is working fine. > > What I'm trying to accomplish is portknocking for 'ssh' access: > > pass in log quick proto tcp from any to any port {1234} synproxy state \ > (max-src-conn-rate 5/15, overload ) > > Because the jail is on 'fib 1', the connection is never established to > overload the rule. The 'synproxy state' is communicating via the > 172.xxxx/default gateway [of fib 0] instead of via the public "fib 1" > > I can ssh into the jail if I do > pass in log quick proto tcp from any to any port {22} keep state > > I CANNOT ssh into the jail if I do > pass in log quick proto tcp from any to any port {22} synproxy state > > Anyway I can force 'synproxy' to communicate via fib 1 ? I don't think I understand your setup and intent completely, but you can select a fib with the "rtable" filter parameter. It *should* be used for the synproxy communication, as well. Please report if this helps. -- Max From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 07:29:34 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C48B1065676 for ; Fri, 8 Jan 2010 07:29:34 +0000 (UTC) (envelope-from fbsdq@peterk.org) Received: from poshta.pknet.net (poshta.pknet.net [216.241.167.213]) by mx1.freebsd.org (Postfix) with ESMTP id 3735A8FC18 for ; Fri, 8 Jan 2010 07:29:33 +0000 (UTC) Received: (qmail 81893 invoked by uid 89); 8 Jan 2010 07:29:36 -0000 Received: from poshta.pknet.net (HELO pop.pknet.net) (216.241.167.213) by poshta.pknet.net with SMTP; 8 Jan 2010 07:29:36 -0000 Received: from 216.241.167.213 (SquirrelMail authenticated user fbsdq@peterk.org) by pop.pknet.net with HTTP; Fri, 8 Jan 2010 00:29:36 -0700 Message-ID: In-Reply-To: <201001080655.43652.max@love2party.net> References: <25cb73eeb5cb6830aefd1164b23e82b8.squirrel@pop.pknet.net> <201001080655.43652.max@love2party.net> Date: Fri, 8 Jan 2010 00:29:36 -0700 From: "Peter" To: "Max Laier" User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-pf@freebsd.org Subject: Re: setfib + pf + synproxy not working X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 07:29:34 -0000 > On Friday 08 January 2010 06:04:34 Peter wrote: >> iH, >> Playing around with FIBs and jails. >> >> The host system is on a private 172.xxx network with a gateway of >> 172.xxx >> going through a NAT box for internet. [fib 0] >> >> The jail has only a public IP, on fib 1 [with gateway being ISP router] >> >> With this, the jail is working fine. >> >> What I'm trying to accomplish is portknocking for 'ssh' access: >> >> pass in log quick proto tcp from any to any port {1234} synproxy state \ >> (max-src-conn-rate 5/15, overload ) >> >> Because the jail is on 'fib 1', the connection is never established to >> overload the rule. The 'synproxy state' is communicating via the >> 172.xxxx/default gateway [of fib 0] instead of via the public "fib 1" >> >> I can ssh into the jail if I do >> pass in log quick proto tcp from any to any port {22} keep state >> >> I CANNOT ssh into the jail if I do >> pass in log quick proto tcp from any to any port {22} synproxy state >> >> Anyway I can force 'synproxy' to communicate via fib 1 ? > > I don't think I understand your setup and intent completely, but you can > select a fib with the "rtable" filter parameter. It *should* be used for > the > synproxy communication, as well. Please report if this helps. > > -- > Max > host: 172.xxx -> gateway = 172.xxx.1 [NAT] -> 216.241.167.YY [fib 0/default] jail: 216.241.167.XX -> gateway = 216.241.167.1 [jail started on fib 1] fib0: gateway = 172.xxx.1 [host] fib1: gateway = 216.241.167.1 [jail] With jail on fib 1, and different gateway vs. the host system itself, 'synproxy' does not work. With rtable, I'm still NOT able to connect to jail from outside: pass in log quick proto tcp from any to any port = ssh synproxy state rtable 1 [/sbin/pfctl -nf /etc/pf.conf && /sbin/pfctl -f /etc/pf.conf] If I remove 'synproxy state' and put in 'keep state' it works. FreeBSD stable/8 ]Peter[ From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 08:38:05 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 529DD1065670 for ; Fri, 8 Jan 2010 08:38:05 +0000 (UTC) (envelope-from Olivier.Thibault@lmpt.univ-tours.fr) Received: from mailhost.lmpt.univ-tours.fr (mailhost.lmpt.univ-tours.fr [193.52.212.1]) by mx1.freebsd.org (Postfix) with ESMTP id 094898FC0C for ; Fri, 8 Jan 2010 08:38:04 +0000 (UTC) Received: from mailhost.lmpt.univ-tours.fr (localhost [127.0.0.1]) by mailhost.lmpt.univ-tours.fr (Postfix) with ESMTP id 2434BDAFE5; Fri, 8 Jan 2010 09:19:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= lmpt.univ-tours.fr; h=content-transfer-encoding:content-type :content-type:in-reply-to:references:subject:subject :mime-version:user-agent:from:from:date:date:message-id:received :received; s=main; t=1262938789; bh=CPdvid6fMIFDmEzrJtUTK280J9Dg J+8nbQz4dokG1mg=; b=jc6/ljfOJ3P0UXL1KgokKa0FuZAp4b+fMu0tgsRxRN5r KI1mF11HaANfMgK9RJbevgqNpBdmS5Xt3MxkkpF5riNmT5/dxJv+3EXldBbhey8b nuQ8Xl6UNucXowJpIK/m2Zhe1B/Fdax7/eTN2nOVMT/It+EGyAPSELDxHdoHBt8= X-Virus-Scanned: amavisd-new at lmpt.univ-tours.fr Received: from mailhost.lmpt.univ-tours.fr ([127.0.0.1]) by mailhost.lmpt.univ-tours.fr (mailhost.lmpt.univ-tours.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id i+N4L0Cmt25b; Fri, 8 Jan 2010 09:19:49 +0100 (CET) Received: from [10.68.5.128] (trinity.lmpt.priv [10.68.5.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailhost.lmpt.univ-tours.fr (Postfix) with ESMTPSA id 7C255DAF70; Fri, 8 Jan 2010 09:19:49 +0100 (CET) Message-ID: <4B46EAA2.5050904@lmpt.univ-tours.fr> Date: Fri, 08 Jan 2010 09:19:46 +0100 From: Olivier Thibault User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Kurt Turner References: <40fc01eb1001071427g335634c9u1ffa8aacba1360f3@mail.gmail.com> In-Reply-To: <40fc01eb1001071427g335634c9u1ffa8aacba1360f3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: freebsd 8 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 08:38:05 -0000 Hello, Le 07.01.2010 23:27, Kurt Turner a =E9crit : > Hello all >=20 > In an effort not to create yet another insecure server on the www I'd l= ike > to ensure my pf.conf file is good and secure - will someone please revi= ew > this configuration and let me know your thoughts? >=20 > I only want to allow www and ssh inbound and have limited access also > outbound - this is a remote web server I do not have access to at all. = TIA >=20 ... > # keep stats of outging connections > pass out keep state This rule allows everything out and next outgoing rules won't be checked = as this=20 one first match. The "keep state" keyword is also not necessary any more since FreeBSD 7. = It is=20 implicit. Maybe you can just write "block return all", which implies in and out in = the=20 same rule. Best regards, --=20 Olivier THIBAULT Universit=E9 Fran=E7ois Rabelais - UFR Sciences et Techniques Laboratoire de Math=E9matiques et Physique Th=E9orique (UMR CNRS 6083) Service Informatique de l'UFR Parc de Grandmont 37200 Tours - France Email: olivier.thibault at lmpt.univ-tours.fr Tel: (33)(0)2 47 36 69 12 Fax: (33)(0)2 47 36 70 68 Mobile : (33)(0)6 62 60 80 44 From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 10:31:23 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB4C3106566B for ; Fri, 8 Jan 2010 10:31:23 +0000 (UTC) (envelope-from allicient3141@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0758FC17 for ; Fri, 8 Jan 2010 10:31:23 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so1300412eye.9 for ; Fri, 08 Jan 2010 02:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=RuD+i/BiTI+NeAyZ++eQsXdK1xLdzIUPD1KBqJ/wwkg=; b=gVuJ+QhIFyhbYPEPzAI2WHGfV0EXi2CztnIQpa+EYRaPApFIAEGXZR2P0J1PJ7yxpu 6BqZYRcjQU4Ve4rO8WmtftAfjN1MK5ZqDv5Hcu15E5AG4N/ueqkIVu56jyct7LtduXTn BjjChjowj02tc7AuMzBygmhKlKTqLTCoxAnSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=o3QrTdUpBga0qFQ8I8/P8w69d5jVs73QZqiNBnSj4cF+oTrydjJzvPepCKdPqgfaCU FRujYYfxrxmKsdCR+7FtuEvAIsbAge/zxtGqYphXQv9IJKc5W/Gmb3mbnPdDntkxIfLP ZwcF/7jtNSlrVBekBYn2nOiXzcc1xI8QL4j+g= MIME-Version: 1.0 Sender: allicient3141@googlemail.com Received: by 10.213.24.2 with SMTP id t2mr1139970ebb.6.1262946678597; Fri, 08 Jan 2010 02:31:18 -0800 (PST) In-Reply-To: <4B46EAA2.5050904@lmpt.univ-tours.fr> References: <40fc01eb1001071427g335634c9u1ffa8aacba1360f3@mail.gmail.com> <4B46EAA2.5050904@lmpt.univ-tours.fr> Date: Fri, 8 Jan 2010 10:31:18 +0000 X-Google-Sender-Auth: 6d4d8bc61f5f1f32 Message-ID: <7731938b1001080231p75e6ee17g59c8fbacda90d983@mail.gmail.com> From: Peter Maxwell To: Olivier Thibault Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-pf@freebsd.org Subject: Re: freebsd 8 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 10:31:24 -0000 2010/1/8 Olivier Thibault : >> # keep stats of outging connections >> pass out keep state > > This rule allows everything out and next outgoing rules won't be checked as > this one first match. That's incorrect, pf does the opposite and uses the *last* match - at least that's what the documentation says... http://www.openbsd.org/faq/pf/filter.html The quick keyword is used for shortcut evaluation. From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 10:38:38 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ED85106566B for ; Fri, 8 Jan 2010 10:38:38 +0000 (UTC) (envelope-from Olivier.Thibault@lmpt.univ-tours.fr) Received: from mailhost.lmpt.univ-tours.fr (mailhost.lmpt.univ-tours.fr [193.52.212.1]) by mx1.freebsd.org (Postfix) with ESMTP id 345EC8FC0C for ; Fri, 8 Jan 2010 10:38:38 +0000 (UTC) Received: from mailhost.lmpt.univ-tours.fr (localhost [127.0.0.1]) by mailhost.lmpt.univ-tours.fr (Postfix) with ESMTP id 95067DB05F for ; Fri, 8 Jan 2010 11:38:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= lmpt.univ-tours.fr; h=content-transfer-encoding:content-type :content-type:in-reply-to:references:subject:subject :mime-version:user-agent:from:from:date:date:message-id:received :received; s=main; t=1262947115; bh=RuXUhLK2M6r86EWIdwtoeCrsQcFo Lo41W1wTVK0Cnoc=; b=XAATRiH6Q+bPGl5vFGMRF0MlMLILGwfbBI1DFsj8VH4u Etjnc4mBjmfPpIHcD2KA2od6jjR2i1+DyBe4x5T5zKCc4BBNMA7XdIs+weyLFnl2 9rRDMoEFO0v3YBn+Mcj3wZ9pW2eplfidcl15Q4n5qdTXpDW2u7JL1eGRQlVHvsQ= X-Virus-Scanned: amavisd-new at lmpt.univ-tours.fr Received: from mailhost.lmpt.univ-tours.fr ([127.0.0.1]) by mailhost.lmpt.univ-tours.fr (mailhost.lmpt.univ-tours.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id e9mchCt2UHJV for ; Fri, 8 Jan 2010 11:38:35 +0100 (CET) Received: from [10.68.5.128] (trinity.lmpt.priv [10.68.5.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailhost.lmpt.univ-tours.fr (Postfix) with ESMTPSA id 5C700DAFE5 for ; Fri, 8 Jan 2010 11:38:35 +0100 (CET) Message-ID: <4B470B28.8070408@lmpt.univ-tours.fr> Date: Fri, 08 Jan 2010 11:38:32 +0100 From: Olivier Thibault User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <40fc01eb1001071427g335634c9u1ffa8aacba1360f3@mail.gmail.com> <4B46EAA2.5050904@lmpt.univ-tours.fr> <7731938b1001080231p75e6ee17g59c8fbacda90d983@mail.gmail.com> In-Reply-To: <7731938b1001080231p75e6ee17g59c8fbacda90d983@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: freebsd 8 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 10:38:38 -0000 Le 08.01.2010 11:31, Peter Maxwell a =E9crit : > 2010/1/8 Olivier Thibault : >=20 >>> # keep stats of outging connections >>> pass out keep state >> This rule allows everything out and next outgoing rules won't be check= ed as >> this one first match. >=20 > That's incorrect, pf does the opposite and uses the *last* match - at > least that's what the documentation says... > http://www.openbsd.org/faq/pf/filter.html >=20 > The quick keyword is used for shortcut evaluation. Yes ! Actually, all the following rules in my pf.conf use this keyword. That's why I said that. I suppose the rules evaluation is quicker this way but I may be wrong. Am I ? Best regards, --=20 Olivier THIBAULT Universit=E9 Fran=E7ois Rabelais - UFR Sciences et Techniques Laboratoire de Math=E9matiques et Physique Th=E9orique (UMR CNRS 6083) Service Informatique de l'UFR Parc de Grandmont 37200 Tours - France Email: olivier.thibault at lmpt.univ-tours.fr Tel: (33)(0)2 47 36 69 12 Fax: (33)(0)2 47 36 70 68 Mobile : (33)(0)6 62 60 80 44 From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 11:15:05 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EC5D106568B for ; Fri, 8 Jan 2010 11:15:05 +0000 (UTC) (envelope-from allicient3141@googlemail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id C511F8FC08 for ; Fri, 8 Jan 2010 11:15:04 +0000 (UTC) Received: by ewy26 with SMTP id 26so17684255ewy.3 for ; Fri, 08 Jan 2010 03:14:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=tPlqgUvW7LwZxcutQ/bzl3mJKqKNL88LLLbmDQtxmw8=; b=ps8gkRu88dwj2B/sfWyw5aOopSQesO3pCilenjD+VT105bPTlXfXr4rZfGSb8pOJaY x5fUGy7FXIg3yh7I1cCQ3FC4i6UjKotgojQrp/T289cxle7ynPeZbYWeuTlYYFgrgk22 7L8VidkvDdsRli+V9gbwnG9p0KnoNY7uFU7iY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=DS4rfYk9dHYSS0bBrWlxzleQJy/dy4GwdwxRfESGmECE7Q7Q9mqpXdAKXICCw38gQq ydW/nvQQZR4U1G7uxbQ6WNY7gv3/Xrh51ZYiTuSvQ5yK1DA1NSjYRy/1Ifsg+qzrBcvs ATKKPXzBRNSTg6Jvh1AmNuOte5vhbTDBGokBE= MIME-Version: 1.0 Sender: allicient3141@googlemail.com Received: by 10.213.100.229 with SMTP id z37mr3197795ebn.87.1262949299484; Fri, 08 Jan 2010 03:14:59 -0800 (PST) In-Reply-To: <4B470B28.8070408@lmpt.univ-tours.fr> References: <40fc01eb1001071427g335634c9u1ffa8aacba1360f3@mail.gmail.com> <4B46EAA2.5050904@lmpt.univ-tours.fr> <7731938b1001080231p75e6ee17g59c8fbacda90d983@mail.gmail.com> <4B470B28.8070408@lmpt.univ-tours.fr> Date: Fri, 8 Jan 2010 11:14:59 +0000 X-Google-Sender-Auth: 657aba0f0ab68f3b Message-ID: <7731938b1001080314k1de75328l15afb2f636b8cae2@mail.gmail.com> From: Peter Maxwell To: Olivier Thibault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: freebsd 8 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 11:15:05 -0000 2010/1/8 Olivier Thibault : > Le 08.01.2010 11:31, Peter Maxwell a =E9crit : >> >> 2010/1/8 Olivier Thibault : >> >>>> # keep stats of outging connections >>>> pass out keep state >>> >>> This rule allows everything out and next outgoing rules won't be checke= d >>> as >>> this one first match. >> >> That's incorrect, pf does the opposite and uses the *last* match - at >> least that's what the documentation says... >> http://www.openbsd.org/faq/pf/filter.html >> >> The quick keyword is used for shortcut evaluation. > > Yes ! Actually, all the following rules in my pf.conf use this keyword. > That's why I said that. > I suppose the rules evaluation is quicker this way but I may be wrong. > Am I ? Erm, mostly wrong... it wouldn't improve performance if even a majority of your rules use it, in that case all you've done is change last match processing to first match processing. If when pf is actually processing packets (this is not the same as loading your rule set), lets assume that the packets are evaluated against each rule in a sequential manner. With that assumption, having most of your rules *without* the quick keyword then only use quick for those rules near the top of your ruleset that process a large amount of new connections (again, not synonymous with traffic - it's new connections that matter), in that case you may see a performance improvement. For example, say you have a complex ruleset but lots of incoming connections on port 80 - then using the quick keyword and placing the rule near the top of your ruleset may improve things. However, that assumes pf goes through the rules in a sequential manner when actually processing packets - that may not be true. My advice would be to put a single 'block all' rule at the top, then have the remainder of your rules doing 'pass': it is much much easier to read and debug. What is more valuable to you, saving hours on debuging a firewall box or a 2% performance improvement? It is also unlikely you'd be getting enough traffic to warrant the use of 'quick' ;-) Most other packet filters/firewalls I've used use match first. Logically using match last is no different (you essentially just write your rule set upside-down), but it is actually my preference. From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 12:21:16 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB18F106566B for ; Fri, 8 Jan 2010 12:21:16 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 683A68FC17 for ; Fri, 8 Jan 2010 12:21:16 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 85A2819E023; Fri, 8 Jan 2010 13:21:14 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 0483119E019; Fri, 8 Jan 2010 13:21:11 +0100 (CET) Message-ID: <4B472337.1040407@quip.cz> Date: Fri, 08 Jan 2010 13:21:11 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.6) Gecko/20091206 SeaMonkey/2.0.1 MIME-Version: 1.0 To: Max Laier References: <4B315B31.7050902@quip.cz> <200912230140.40776.max@love2party.net> <4B316E7B.9020404@quip.cz> In-Reply-To: <4B316E7B.9020404@quip.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: How to export / save and compare PF rule sets X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 12:21:16 -0000 Hi Max, can you take a look at my problem again? I don't want to make you angry, I am just trying to better understand things and found if the problem is on my side or some inconsistency of the pfctl output. Thanks in advance for your help. Miroslav Lachman Miroslav Lachman wrote: > Max Laier wrote: >> On Wednesday 23 December 2009 00:50:09 Miroslav Lachman wrote: >>> scrub is before nat/rdr rules in case of "pfctl -s a" and after nat/rdr >>> in case of "pfctl -nvf /etc/pf.conf" >> >> The order should always be options, scrub, queues, nat, filters. pfctl >> -nvf >> only works with a different order if you have "set require-order no" >> in your >> ruleset. You should be able to fix this at your end. > > I have things in this order in my pf.conf: > macros > tables > options > scrub > nat > rdr > pass/block rules > > I don't have "set require-order no" in pf.conf, the only options I have > are: > set timeout { interval 10, frag 20 } > set limit { states 10000, frags 5000 } > set optimization aggressive > set block-policy return > set skip on $unfiltered > > then: > scrub in on $ext_if > scrub out on $ext_if no-df random-id max-mss 1492 > > nat pass on $ext_if from $vpn_sectun_net to any -> $ext_addr_0 > rdr pass on $ext_if inet proto tcp from to $ext_addr_0 port > 10443 -> $pdu_addr_0 port 443 > rdr pass on $ext_if inet proto tcp from to $ext_addr_0 port > 11443 -> $pdu_addr_1 port 443 > rdr pass on $ext_if inet proto tcp from to $ext_addr_0 port > 12443 -> $pdu_addr_2 port 443 > > So do I have to change anything? I think I have it in the right order. > That's why I asked the question here. > > The problem is that "pfctl -s a" shows > TRANSLATION RULES: > (some NAT/RDR here) > > FILTER RULES: > scrub in on bge1 all fragment reassemble > scrub out on bge1 all no-df random-id max-mss 1492 fragment reassemble > pass in quick proto tcp from to any flags S/SA keep state > block return in log quick from to any > > As you can see - scrub is in the FILTER RULES section of the output, but > in pf.conf (required according to manpage) scrub is before TRANSLATION > RULES and pfctl -nvf print it in this (right) order. > >>> Is there any other way how can I export live and saved rules in the same >>> format and the same order, ready to comparission by diff? >> >> you can always extract the parts individually and cat them together if >> you >> insist on keeping the ruleset unordered. > > I was trying to do it in one pass (speed optimization ;]) From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 13:33:36 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A80D106568F for ; Fri, 8 Jan 2010 13:33:36 +0000 (UTC) (envelope-from Olivier.Thibault@lmpt.univ-tours.fr) Received: from mailhost.lmpt.univ-tours.fr (mailhost.lmpt.univ-tours.fr [193.52.212.1]) by mx1.freebsd.org (Postfix) with ESMTP id ECA808FC2F for ; Fri, 8 Jan 2010 13:33:35 +0000 (UTC) Received: from mailhost.lmpt.univ-tours.fr (localhost [127.0.0.1]) by mailhost.lmpt.univ-tours.fr (Postfix) with ESMTP id F0914DB0FB; Fri, 8 Jan 2010 14:33:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= lmpt.univ-tours.fr; h=content-transfer-encoding:content-type :content-type:in-reply-to:references:subject:subject :mime-version:user-agent:from:from:date:date:message-id:received :received; s=main; t=1262957613; bh=1FLDZsN/wN3mR4oxkvkGKvFFr8+F /JRq+js/dO5rpqA=; b=To+QYfnsJDvyX1pcAh2bvii5OwFguhTLZxP15yB1Y183 u0mPY1eo1lglzBEHLzh4LN4sjRwdJy+h8Gand62DInEs7U48s4GnonBcV2vW3lW3 ZSg2sV+wdMZLKD6nGtZkN4AQblZQ18Z/A78wRsBxxd08vMNuaOzv9E/xKd11spg= X-Virus-Scanned: amavisd-new at lmpt.univ-tours.fr Received: from mailhost.lmpt.univ-tours.fr ([127.0.0.1]) by mailhost.lmpt.univ-tours.fr (mailhost.lmpt.univ-tours.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yuJfn42oP00n; Fri, 8 Jan 2010 14:33:33 +0100 (CET) Received: from [10.68.5.128] (trinity.lmpt.priv [10.68.5.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailhost.lmpt.univ-tours.fr (Postfix) with ESMTPSA id EDD07DB0ED; Fri, 8 Jan 2010 14:33:32 +0100 (CET) Message-ID: <4B473429.6010508@lmpt.univ-tours.fr> Date: Fri, 08 Jan 2010 14:33:29 +0100 From: Olivier Thibault User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Peter Maxwell References: <40fc01eb1001071427g335634c9u1ffa8aacba1360f3@mail.gmail.com> <4B46EAA2.5050904@lmpt.univ-tours.fr> <7731938b1001080231p75e6ee17g59c8fbacda90d983@mail.gmail.com> <4B470B28.8070408@lmpt.univ-tours.fr> <7731938b1001080314k1de75328l15afb2f636b8cae2@mail.gmail.com> In-Reply-To: <7731938b1001080314k1de75328l15afb2f636b8cae2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: freebsd 8 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 13:33:36 -0000 Hi, Thanks a lot for your answer and explanations. This will be very helpfull to me and I will update my pf.conf. Thanks again. Olivier Le 08.01.2010 12:14, Peter Maxwell a =E9crit : > 2010/1/8 Olivier Thibault : >> Le 08.01.2010 11:31, Peter Maxwell a =E9crit : >>> 2010/1/8 Olivier Thibault : >>> >>>>> # keep stats of outging connections >>>>> pass out keep state >>>> This rule allows everything out and next outgoing rules won't be che= cked >>>> as >>>> this one first match. >>> That's incorrect, pf does the opposite and uses the *last* match - at >>> least that's what the documentation says... >>> http://www.openbsd.org/faq/pf/filter.html >>> >>> The quick keyword is used for shortcut evaluation. >> Yes ! Actually, all the following rules in my pf.conf use this keyword= . >> That's why I said that. >> I suppose the rules evaluation is quicker this way but I may be wrong. >> Am I ? >=20 > Erm, mostly wrong... it wouldn't improve performance if even a > majority of your rules use it, in that case all you've done is change > last match processing to first match processing. >=20 > If when pf is actually processing packets (this is not the same as > loading your rule set), lets assume that the packets are evaluated > against each rule in a sequential manner. With that assumption, > having most of your rules *without* the quick keyword then only use > quick for those rules near the top of your ruleset that process a > large amount of new connections (again, not synonymous with traffic - > it's new connections that matter), in that case you may see a > performance improvement. For example, say you have a complex ruleset > but lots of incoming connections on port 80 - then using the quick > keyword and placing the rule near the top of your ruleset may improve > things. >=20 > However, that assumes pf goes through the rules in a sequential manner > when actually processing packets - that may not be true. My advice > would be to put a single 'block all' rule at the top, then have the > remainder of your rules doing 'pass': it is much much easier to read > and debug. What is more valuable to you, saving hours on debuging a > firewall box or a 2% performance improvement? It is also unlikely > you'd be getting enough traffic to warrant the use of 'quick' ;-) >=20 > Most other packet filters/firewalls I've used use match first. > Logically using match last is no different (you essentially just write > your rule set upside-down), but it is actually my preference. --=20 Olivier THIBAULT Universit=E9 Fran=E7ois Rabelais - UFR Sciences et Techniques Laboratoire de Math=E9matiques et Physique Th=E9orique (UMR CNRS 6083) Service Informatique de l'UFR Parc de Grandmont 37200 Tours - France Email: olivier.thibault at lmpt.univ-tours.fr Tel: (33)(0)2 47 36 69 12 Fax: (33)(0)2 47 36 70 68 Mobile : (33)(0)6 62 60 80 44 From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 13:51:34 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B86C1065692 for ; Fri, 8 Jan 2010 13:51:34 +0000 (UTC) (envelope-from m.keith.thompson@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 26E7B8FC1B for ; Fri, 8 Jan 2010 13:51:33 +0000 (UTC) Received: by bwz5 with SMTP id 5so12360868bwz.3 for ; Fri, 08 Jan 2010 05:51:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dRxAdc4qnOs1HpG0/yYhqONRMO9CLPC5LeIyPi4M2mY=; b=GbUM3X50HkrtSwyInSzBMHRjp61OxaCW2U0g9qjF18pEhUjDgrGZUIEfYuMrKgG6ly VyKnpBTQAfv2s4wVrt3CwKuVjvD3XS6Yw1wePbZvI7281q9kvWAs2xPiRUOHJnVXpECp D/1Mq11SN/ECEsrRV55q0JZCYF76k7b/BSmsE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Q1RDC1Hd+w6LW7HCxjLGqUclgV6tdOvhBYUTrt7I0Qn+LlX+YF3p7Ndr/Xom3eZeXy 7Fzi4tjfyLJSoJYxZ8k6Gem/bCW+gNj/Znwd5/rj4Dj0lhxg3VsCSH2npxLdhGbhbCLc h3emAi0o0HHK9QUGNb+x72RoWKBewcPPDpn9Q= MIME-Version: 1.0 Received: by 10.204.49.79 with SMTP id u15mr5780860bkf.117.1262958690432; Fri, 08 Jan 2010 05:51:30 -0800 (PST) In-Reply-To: <19861fba1001072018g115a0bccrf9510a38454cc9db@mail.gmail.com> References: <7731938b1001060923n5de4b511of07b8c63cff4e011@mail.gmail.com> <2cf1d0681001071216p6b516e9egcf7401f2b38e3c3d@mail.gmail.com> <19861fba1001071237ncc440d5u1ab280d2aaf0c72f@mail.gmail.com> <19861fba1001072018g115a0bccrf9510a38454cc9db@mail.gmail.com> Date: Fri, 8 Jan 2010 07:51:30 -0600 Message-ID: From: "M. Keith Thompson" To: J65nko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 13:51:34 -0000 On Thu, Jan 7, 2010 at 10:18 PM, J65nko wrote: > On Thu, Jan 7, 2010 at 10:19 PM, M. Keith Thompson > wrote: >> On Thu, Jan 7, 2010 at 2:37 PM, J65nko wrote: >>>> # SSH from NetEng subnet >>>> pass in quick log on $ext_if proto tcp from $net_eng to $ext_if port >>>> 22 keep state >>>> >>>> # Allow inside network to ping the server >>>> pass in quick on $ext_if proto icmp from $pingers to $ext_IP keep stat= e >>>> >>>> # Allow DNS lookups >>>> pass out quick on $ext_if proto udp to any port 53 >>>> pass out quick on $ext_if proto tcp to any port 53 keep state >>>> >>>> # Allow ftp >>>> pass in quick on $ext_if proto tcp from any to $ext_IP port 21 keep st= ate >>>> pass in quick on $ext_if proto tcp from any to $ext_IP port > 49151 ke= ep state >>>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP >>>> port 20 keep state >>>> >>>> --- end of pf.conf =A0---------------------- > > With ftp the client initiates the ftp command channel > =A0 client:port >1023 =A0 ---> server:port 21 > > The passive ftp data channel is initiated by the client > =A0 =A0client:port >1023 =A0---> server:port>1023 > > Your second rule takes care of this > > The active ftp data channel is initiated by the ftp server > using and that is kind of weird, port 20 (ftp-data), as source port. > =A0 =A0 =A0server:port 20 =A0 ---> clientLport >1023 > > You meant to pass active ftp with this rule: > >>>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP >>>> port 20 keep state > > But it should be: > =A0 =A0pass out quick on $ext_if inet proto tcp from any port ftp-data > =A0 =A0to $ext_IP port > 10000 keep state I will make that change > BTW you have a nice pf debug friendly "block log all" default policy. > Does "tcpdump -eni pflog0" on the pf box show any blocked packets? tcpdump of the pflog0 does not show any packets from or to the IP in questi= on. > RE: ftp-proxy > This just adds complexitiy, after everything is working you could add it = in. > > RE: active ftp user requirement > Yes, I understand, it is the users who help us pay our mortgage ;) > From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 15:00:36 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F950106566C for ; Fri, 8 Jan 2010 15:00:36 +0000 (UTC) (envelope-from webmaster@absolutenetworks.biz) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0B06C8FC17 for ; Fri, 8 Jan 2010 15:00:35 +0000 (UTC) Received: by pwi15 with SMTP id 15so57955pwi.3 for ; Fri, 08 Jan 2010 07:00:33 -0800 (PST) MIME-Version: 1.0 Sender: webmaster@absolutenetworks.biz Received: by 10.143.154.2 with SMTP id g2mr1749927wfo.18.1262962833247; Fri, 08 Jan 2010 07:00:33 -0800 (PST) In-Reply-To: <4B473429.6010508@lmpt.univ-tours.fr> References: <40fc01eb1001071427g335634c9u1ffa8aacba1360f3@mail.gmail.com> <4B46EAA2.5050904@lmpt.univ-tours.fr> <7731938b1001080231p75e6ee17g59c8fbacda90d983@mail.gmail.com> <4B470B28.8070408@lmpt.univ-tours.fr> <7731938b1001080314k1de75328l15afb2f636b8cae2@mail.gmail.com> <4B473429.6010508@lmpt.univ-tours.fr> From: Kurt Turner Date: Fri, 8 Jan 2010 09:00:13 -0600 X-Google-Sender-Auth: 02e99e5cd82df10d Message-ID: <40fc01eb1001080700o6c277be5i12fb613c18fd2080@mail.gmail.com> To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: freebsd 8 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 15:00:36 -0000 Thank you all for your help. > Le 08.01.2010 12:14, Peter Maxwell a =E9crit : > > 2010/1/8 Olivier Thibault : >> >>> Le 08.01.2010 11:31, Peter Maxwell a =E9crit : >>> >>>> 2010/1/8 Olivier Thibault : >>>> >>>> # keep stats of outging connections >>>>>> pass out keep state >>>>>> >>>>> This rule allows everything out and next outgoing rules won't be >>>>> checked >>>>> as >>>>> this one first match. >>>>> >>>> That's incorrect, pf does the opposite and uses the *last* match - at >>>> least that's what the documentation says... >>>> http://www.openbsd.org/faq/pf/filter.html >>>> >>>> The quick keyword is used for shortcut evaluation. >>>> >>> Yes ! Actually, all the following rules in my pf.conf use this keyword. >>> That's why I said that. >>> I suppose the rules evaluation is quicker this way but I may be wrong. >>> Am I ? >>> >> >> Erm, mostly wrong... it wouldn't improve performance if even a >> majority of your rules use it, in that case all you've done is change >> last match processing to first match processing. >> >> If when pf is actually processing packets (this is not the same as >> loading your rule set), lets assume that the packets are evaluated >> against each rule in a sequential manner. With that assumption, >> having most of your rules *without* the quick keyword then only use >> quick for those rules near the top of your ruleset that process a >> large amount of new connections (again, not synonymous with traffic - >> it's new connections that matter), in that case you may see a >> performance improvement. For example, say you have a complex ruleset >> but lots of incoming connections on port 80 - then using the quick >> keyword and placing the rule near the top of your ruleset may improve >> things. >> >> However, that assumes pf goes through the rules in a sequential manner >> when actually processing packets - that may not be true. My advice >> would be to put a single 'block all' rule at the top, then have the >> remainder of your rules doing 'pass': it is much much easier to read >> and debug. What is more valuable to you, saving hours on debuging a >> firewall box or a 2% performance improvement? It is also unlikely >> you'd be getting enough traffic to warrant the use of 'quick' ;-) >> >> Most other packet filters/firewalls I've used use match first. >> Logically using match last is no different (you essentially just write >> your rule set upside-down), but it is actually my preference. >> > > > -- > Olivier THIBAULT > Universit=E9 Fran=E7ois Rabelais - UFR Sciences et Techniques > Laboratoire de Math=E9matiques et Physique Th=E9orique (UMR CNRS 6083) > Service Informatique de l'UFR > Parc de Grandmont > 37200 Tours - France > Email: olivier.thibault at lmpt.univ-tours.fr > Tel: (33)(0)2 47 36 69 12 > Fax: (33)(0)2 47 36 70 68 > Mobile : (33)(0)6 62 60 80 44 > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 16:31:15 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82934106568F for ; Fri, 8 Jan 2010 16:31:15 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 327648FC1A for ; Fri, 8 Jan 2010 16:31:14 +0000 (UTC) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id 2AE32B03892D for ; Fri, 8 Jan 2010 11:31:13 -0500 (EST) thread-index: AcqQf/3iMnGfnaX4THeb2nXL3nPXCg== Received: from dllstx1-8sst9f1.corp.verio.net ([10.144.0.7]) by iad-wprd-xchw01.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 11:31:11 -0500 Received: by dllstx1-8sst9f1.corp.verio.net (sSMTP sendmail emulation); Fri, 08 Jan 2010 10:31:11 +0000 Date: Fri, 8 Jan 2010 10:31:11 -0600 Content-Transfer-Encoding: 7bit From: "David DeSimone" To: Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Message-ID: <20100108163110.GL9200@verio.net> Mail-Followup-To: freebsd-pf@freebsd.org References: <7731938b1001060923n5de4b511of07b8c63cff4e011@mail.gmail.com> <2cf1d0681001071216p6b516e9egcf7401f2b38e3c3d@mail.gmail.com> <19861fba1001071237ncc440d5u1ab280d2aaf0c72f@mail.gmail.com> <19861fba1001072018g115a0bccrf9510a38454cc9db@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <19861fba1001072018g115a0bccrf9510a38454cc9db@mail.gmail.com> Precedence: bulk User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 08 Jan 2010 16:31:11.0743 (UTC) FILETIME=[FD3E10F0:01CA907F] Subject: Re: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 16:31:15 -0000 J65nko wrote: > > You meant to pass active ftp with this rule: > > >>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP > >>> port 20 keep state > > But it should be: > pass out quick on $ext_if inet proto tcp from any port ftp-data > to $ext_IP port > 10000 keep state Are you sure you don't mean: pass out quick on $ext_if inet proto tcp from $ext_IP port ftp-data \ to any port > 10000 keep state -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 20:51:03 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D6D91065696 for ; Fri, 8 Jan 2010 20:51:03 +0000 (UTC) (envelope-from m.keith.thompson@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 18BE98FC1E for ; Fri, 8 Jan 2010 20:51:02 +0000 (UTC) Received: by bwz5 with SMTP id 5so12639356bwz.3 for ; Fri, 08 Jan 2010 12:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FwL4AS8grYlvq85mlaqWk0U4mrI0LRvf8p67n7BxfGg=; b=n7fTthDv9HFZRbFbhXtpWmQxGTzzAWeVoB393hOQXFLy6HjHk6Uj3U0cXhGveqVAbU qLPvkdz+o+H5w2zQpTFRjNGXTUU4USYwtpr4Irz+xgBKa1pUjmStPdRoC80SMIpozHWz Bgn0PbXRwnJ2/aKZWMZCJA1XHbKj1xjAqzu4Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Mdp5GLxMotWzFcrk4gpX9nbEgLT/GvQZdbqBBoSg/W9rFnWdPfjzlIY1TP1WSAAyaH opX7KK6+CjltnQEbsISkdGFgZTmJl+HeiVdQssUGuDXYYDLeke1Es24O1LD4ieMpkLvX 9JY2459sCxmBh8E1r7Ql+49s1Dxwr9RlquL5E= MIME-Version: 1.0 Received: by 10.204.156.28 with SMTP id u28mr2907309bkw.74.1262983856998; Fri, 08 Jan 2010 12:50:56 -0800 (PST) In-Reply-To: References: <7731938b1001060923n5de4b511of07b8c63cff4e011@mail.gmail.com> <2cf1d0681001071216p6b516e9egcf7401f2b38e3c3d@mail.gmail.com> <19861fba1001071237ncc440d5u1ab280d2aaf0c72f@mail.gmail.com> <19861fba1001072018g115a0bccrf9510a38454cc9db@mail.gmail.com> Date: Fri, 8 Jan 2010 14:50:56 -0600 Message-ID: From: "M. Keith Thompson" To: J65nko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 20:51:03 -0000 It looks like it was a tcp windowing problem. The command: "sysctl -w sysctl net.inet.tcp.rfc1323=3D0" fixed the problem. Thanks for all of the suggestions and help. On Fri, Jan 8, 2010 at 7:51 AM, M. Keith Thompson wrote: > On Thu, Jan 7, 2010 at 10:18 PM, J65nko wrote: >> On Thu, Jan 7, 2010 at 10:19 PM, M. Keith Thompson >> wrote: >>> On Thu, Jan 7, 2010 at 2:37 PM, J65nko wrote: >>>>> # SSH from NetEng subnet >>>>> pass in quick log on $ext_if proto tcp from $net_eng to $ext_if port >>>>> 22 keep state >>>>> >>>>> # Allow inside network to ping the server >>>>> pass in quick on $ext_if proto icmp from $pingers to $ext_IP keep sta= te >>>>> >>>>> # Allow DNS lookups >>>>> pass out quick on $ext_if proto udp to any port 53 >>>>> pass out quick on $ext_if proto tcp to any port 53 keep state >>>>> >>>>> # Allow ftp >>>>> pass in quick on $ext_if proto tcp from any to $ext_IP port 21 keep s= tate >>>>> pass in quick on $ext_if proto tcp from any to $ext_IP port > 49151 k= eep state >>>>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP >>>>> port 20 keep state >>>>> >>>>> --- end of pf.conf =A0---------------------- >> >> With ftp the client initiates the ftp command channel >> =A0 client:port >1023 =A0 ---> server:port 21 >> >> The passive ftp data channel is initiated by the client >> =A0 =A0client:port >1023 =A0---> server:port>1023 >> >> Your second rule takes care of this >> >> The active ftp data channel is initiated by the ftp server >> using and that is kind of weird, port 20 (ftp-data), as source port. >> =A0 =A0 =A0server:port 20 =A0 ---> clientLport >1023 >> >> You meant to pass active ftp with this rule: >> >>>>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP >>>>> port 20 keep state >> >> But it should be: >> =A0 =A0pass out quick on $ext_if inet proto tcp from any port ftp-data >> =A0 =A0to $ext_IP port > 10000 keep state > > I will make that change > >> BTW you have a nice pf debug friendly "block log all" default policy. >> Does "tcpdump -eni pflog0" on the pf box show any blocked packets? > > tcpdump of the pflog0 does not show any packets from or to the IP in ques= tion. > >> RE: ftp-proxy >> This just adds complexitiy, after everything is working you could add it= in. >> >> RE: active ftp user requirement >> Yes, I understand, it is the users who help us pay our mortgage ;) >> > From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 21:05:11 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C75106566C for ; Fri, 8 Jan 2010 21:05:11 +0000 (UTC) (envelope-from m.keith.thompson@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 5D5388FC14 for ; Fri, 8 Jan 2010 21:05:10 +0000 (UTC) Received: by bwz5 with SMTP id 5so12646197bwz.3 for ; Fri, 08 Jan 2010 13:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=5lFhjtXg4f1fh3AyhITxtZ1vyx1PXePOQN0dVvOM26Q=; b=Jm43wwHpT6mQ+1u5BYw3F46iHn/XR6NoFKAwrH0xSNvQqvhaywpfkrIvvEiji3fRAb pwjAtJaZ6V335P6VC3wTJDJcG1s2QDzQIl0+08Jvo4Mc2VZ3vchKzLOfOgH4qlJYRp8G XkZxaaIyhl6WXpQgh0qXEaRRycl36hDtk8PbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Hs9JiyMLWj3ksceoRkHHhYdOiB+sX5UdMTUhhJIvjIox0hg2i7IyBZ+NiywOiSgeMk QJCkgFQZkklj6kFbF9qwdBcVax4JuvaQlNxIsVOKj93Hg6rCfbONwzz9lFdZDHA4wUSJ j9DH0UNi8TWYwFQK87IMeTS9Q2NjSFwROrqbs= MIME-Version: 1.0 Received: by 10.204.48.144 with SMTP id r16mr864927bkf.170.1262984705308; Fri, 08 Jan 2010 13:05:05 -0800 (PST) Date: Fri, 8 Jan 2010 15:05:05 -0600 Message-ID: From: "M. Keith Thompson" To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 21:05:11 -0000 Yes, that is what he meant and I fixed it. From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 22:51:00 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E18041065670 for ; Fri, 8 Jan 2010 22:51:00 +0000 (UTC) (envelope-from j65nko@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 68BDB8FC08 for ; Fri, 8 Jan 2010 22:51:00 +0000 (UTC) Received: by ewy26 with SMTP id 26so18365018ewy.3 for ; Fri, 08 Jan 2010 14:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jpp7C9h76D0VzraVrJ9RmoVjpY5d6vGA7ix2wwLwgGQ=; b=GE5z8yJXm65ZkVW7pOmNV6WOLCu5zPcaUo5wBcfCahm8uxyGiy4UnX92v/854ZSuie x354xSehzj+6m2/H80v3yeDx/F2syOqSg7Zki/oxEf5xyUQygzduUPGww6Evc+At5wsZ lRNzmGkFc4CqAx0hCjINtzStdPLwNTDFOS004= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N5T86v9w63dCJjtar+B5qP+PHHuEffxwrdC8ebmbrrkZCECgpvg2SS4kEWMNlB7yIZ XqAh8AJSJ8MDfsOdtpSo2FKMwsTU+JJiDRJc0q37/EeoglmmNzQlhOKFmfZ250SiOBk/ DVBEz7tjcQ4e+b/JjFoHQdcKbWXETBHEa3704= MIME-Version: 1.0 Received: by 10.213.100.145 with SMTP id y17mr1949900ebn.27.1262991054592; Fri, 08 Jan 2010 14:50:54 -0800 (PST) In-Reply-To: References: <7731938b1001060923n5de4b511of07b8c63cff4e011@mail.gmail.com> <2cf1d0681001071216p6b516e9egcf7401f2b38e3c3d@mail.gmail.com> <19861fba1001071237ncc440d5u1ab280d2aaf0c72f@mail.gmail.com> <19861fba1001072018g115a0bccrf9510a38454cc9db@mail.gmail.com> Date: Fri, 8 Jan 2010 23:50:54 +0100 Message-ID: <19861fba1001081450w4d9096bdt83c8024b6e58af55@mail.gmail.com> From: J65nko To: "M. Keith Thompson" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-pf@freebsd.org Subject: Re: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 22:51:01 -0000 On Fri, Jan 8, 2010 at 9:50 PM, M. Keith Thompson wrote: > It looks like it was a tcp windowing problem. The command: "sysctl -w > sysctl net.inet.tcp.rfc1323=0" > fixed the problem. This only fixes a symptom. :) There is something wrong with your ruleset. >>> # Allow ftp >>> pass in quick on $ext_if proto tcp from any to $ext_IP port 21 keep state >>> pass in quick on $ext_if proto tcp from any to $ext_IP port > 49151 keep state >>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP >>> port 20 keep state With this active ftp rule you had before, the HP client could initiate and transfer over an active ftp data channel, while this rule does not allow this at all. There shouldn't be any active ftp datachannel communication possible because port 20 is the source port and not the destination port. I tried the following pf.conf , with a similar ftp-data rule , on a local FreeBSD 7.2 box in my network EXT_IF=fxp0 # net.inet.ip.portrange.hilast: 65535 # net.inet.ip.portrange.hifirst: 49152 PASSIVE='49152:65535' set skip on lo0 # default policy block log all # outgoing DNS requests pass out quick on $EXT_IF inet proto udp from $EXT_IF:network to any port domain keep state pass out quick on $EXT_IF inet proto tcp from $EXT_IF:network to any port domain keep state flags S/SA # incoming SSH pass in quick on $EXT_IF inet proto tcp from $EXT_IF:network to port 2022 keep state flags S/SA # incoming FTP # ftp command channel pass in quick on $EXT_IF inet proto tcp from any to $EXT_IF port ftp keep state flags S/SA # ftp data channel (passive) pass in quick on $EXT_IF inet proto tcp from any to $EXT_IF port $PASSIVE keep state flags S/SA # ftp data channel (active) # wrong direction!!! pass in quick on $EXT_IF inet proto tcp from any to $EXT_IF port ftp-data keep state flags S/SA Here I also erroneously used port 20 as destination port. An active ftp command to upload a file aborts with 200 EPRT command successful. 425 Can't build data connection: Operation not permitted. A pflog0 tcpdump shows the reason: tcpdump -eni pflog0 -s0 -v tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 65535 bytes 22:16:42.551221 rule 0/0(match): block out on fxp0: (tos 0x8, ttl 64, id 2766, offset 0, flags [DF], proto TCP (6), length 60) 192.168.222.244.20 > 192.168.222.20.62316: S, cksum 0xc222 (correct), 488073960:488073960(0) win 65535 So this rule set blocks the first packet of the three-way TCP handshake. 192.168.222.244.20 > 192.168.222.20.62316. or server.20 > client.62316 Your previous ruleset somehow created state or allowed the server to initiate the data channel to the client somewhere else in your rule set. It didn't create state on the initial packet of the TCP handshake, where the TCP window size is negotiated. Just like the Daniel Hartmeier article states, this a caused tcp window scaling issue. Remember that in pf the last matching rule wins. You only can defeat this behaviour by using the 'quick' keyword. After adding the following corrected rule the transfer proceeds without any blockage # correct direction/source port pass out quick on $EXT_IF inet proto tcp from any port ftp-data to any keep state flags S/SA The rules as parsed are now: # pfctl -vvf /etc/pf.conf No ALTQ support in kernel ALTQ related functions disabled Loaded 696 passive OS fingerprints EXT_IF = "fxp0" PASSIVE = "49152:65535" set skip on { lo0 } @0 block drop log all @1 pass out quick on fxp0 inet proto udp from 192.168.222.0/24 to any port = domain keep state @2 pass out quick on fxp0 inet proto tcp from 192.168.222.0/24 to any port = domain flags S/SA keep state @3 pass in quick on fxp0 inet proto tcp from 192.168.222.0/24 to any port = down flags S/SA keep state @4 pass in quick on fxp0 inet proto tcp from any to 192.168.222.244 port = ftp flags S/SA keep state @5 pass in quick on fxp0 inet proto tcp from any to 192.168.222.244 port 49152:65535 flags S/SA keep state @6 pass in quick on fxp0 inet proto tcp from any to 192.168.222.244 port = ftp-data flags S/SA keep state @7 pass out quick on fxp0 inet proto tcp from any port = ftp-data to any flags S/SA keep state Rule 6 is the rule with the wrong direction/port specification. Rule 7 is the corrected one pflog0 doesn't show any errors: tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 65535 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel And a quick state check still showed some remnants of the connections # pfctl -ss No ALTQ support in kernel ALTQ related functions disabled [snip] all tcp 192.168.222.244:21 <- 192.168.222.20:13497 FIN_WAIT_2:FIN_WAIT_2 all tcp 192.168.222.244:20 -> 192.168.222.20:55246 FIN_WAIT_2:FIN_WAIT_2 all tcp 192.168.222.244:20 -> 192.168.222.20:59354 FIN_WAIT_2:FIN_WAIT_2 The first state is the ftp command channel client:13497 > server:21 The last two are the active data channels: server:20 > client:55246, and server.20 > client.59354 Don't get confused, the last octet of the client IP (192.168.222.20) happens to be the same as the ftp-data port number. ;) A repeat of the transfer shows the following verbose state # pfctl -vvss all tcp 192.168.222.244:20 -> 192.168.222.20:64857 ESTABLISHED:ESTABLISHED [1427346948 + 65536] wscale 3 [200059941 + 37224] wscale 0 age 00:00:02, expires in 24:00:00, 13716:20572 pkts, 713240:30853060 bytes, rule 7 id: 4b47883900000033 creatorid: c576b1b2 By using this command you should be able to figure out which actual rule, here rule 7, creates state for the active ftp data channel. The same when the transfer has finished all tcp 192.168.222.244:20 -> 192.168.222.20:64857 FIN_WAIT_2:FIN_WAIT_2 [1427346950 + 65534] wscale 3 [259693437 + 66608] wscale 0 age 00:00:59, expires in 00:00:38, 41209:61758 pkts, 2142876:92628227 bytes, rule 7 id: 4b47883900000033 creatorid: c576b1b2 Happy rule/state hunting Adriaan all tcp 192.168.222.244:20 -> 192.168.222.20:64857 FIN_WAIT_2:FIN_WAIT_2 [1427346950 + 65534] wscale 3 [259693437 + 66608] wscale 0 age 00:00:59, expires in 00:00:38, 41209:61758 pkts, 2142876:92628227 bytes, rule 7 id: 4b47883900000033 creatorid: c576b1b2 From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 23:06:58 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E783106566C for ; Fri, 8 Jan 2010 23:06:58 +0000 (UTC) (envelope-from m.keith.thompson@gmail.com) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 3D2068FC08 for ; Fri, 8 Jan 2010 23:06:58 +0000 (UTC) Received: by yxe2 with SMTP id 2so5018638yxe.7 for ; Fri, 08 Jan 2010 15:06:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=XANSD9UKmAyYWYIcXSo3Wba6ify5LoB8lpeZX/F7764=; b=xVHKFM97jd5nBubzF9EHFGDl7O1qNS0QeBw5jOFJr783AdmjORYZlAcdEaxBx90zfR 73MouJl6JU4xbt3y/24pYATmGqokryK1LJIzQzx9Dn3RjMXAPqlCJChH5RdrJqUMgeEh 3odJzDc+/wTWWRdzhIxsya0TNBxh5Kt491yz8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=P1S7takXM6hEjCaS+Pr3jpRMaowayTv4Sh694VfAmCDwq6iQbijgBfER8zQaWPTxjH DpNcObXF6qjsLB1mbdxvTWPd+N1gvlbXXV0LF/UMRGAC9HhTdZjyoIl9icJ6JNAW6z63 d2+gGvKkGRSXLeTaA3jXzX30a5GLTYBnxBSXA= Received: by 10.100.35.1 with SMTP id i1mr18597637ani.132.1262992012469; Fri, 08 Jan 2010 15:06:52 -0800 (PST) Received: from ?10.24.45.236? ([166.205.5.170]) by mx.google.com with ESMTPS id 36sm9443451yxh.67.2010.01.08.15.05.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 08 Jan 2010 15:06:51 -0800 (PST) References: <7731938b1001060923n5de4b511of07b8c63cff4e011@mail.gmail.com> <2cf1d0681001071216p6b516e9egcf7401f2b38e3c3d@mail.gmail.com> <19861fba1001071237ncc440d5u1ab280d2aaf0c72f@mail.gmail.com> <19861fba1001072018g115a0bccrf9510a38454cc9db@mail.gmail.com> <19861fba1001081450w4d9096bdt83c8024b6e58af55@mail.gmail.com> Message-Id: From: "M.Keith.Thompson " To: J65nko In-Reply-To: <19861fba1001081450w4d9096bdt83c8024b6e58af55@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Fri, 8 Jan 2010 17:05:16 -0600 Cc: "freebsd-pf@freebsd.org" Subject: Re: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 23:06:58 -0000 Remember the problem is only with one client and files over 98K. Hundreds of other clients transfer multi-megabyte files no problem. On Jan 8, 2010, at 4:50 PM, J65nko wrote: > On Fri, Jan 8, 2010 at 9:50 PM, M. Keith Thompson > wrote: >> It looks like it was a tcp windowing problem. The command: "sysctl >> -w >> sysctl net.inet.tcp.rfc1323=0" >> fixed the problem. > > This only fixes a symptom. :) There is something wrong with your > ruleset. > >>>> # Allow ftp >>>> pass in quick on $ext_if proto tcp from any to $ext_IP port 21 >>>> keep state >>>> pass in quick on $ext_if proto tcp from any to $ext_IP port > >>>> 49151 keep state >>>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP >>>> port 20 keep state > > With this active ftp rule you had before, the HP client could initiate > and transfer over an active ftp data channel, > while this rule does not allow this at all. > There shouldn't be any active ftp datachannel communication possible > because port 20 is the source port and not the destination port. > > I tried the following pf.conf , with a similar ftp-data rule , on a > local FreeBSD 7.2 box in my network > > EXT_IF=fxp0 > > # net.inet.ip.portrange.hilast: 65535 > # net.inet.ip.portrange.hifirst: 49152 > PASSIVE='49152:65535' > > set skip on lo0 > > # default policy > block log all > > # outgoing DNS requests > > pass out quick on $EXT_IF inet proto udp from $EXT_IF:network to any > port domain keep state > pass out quick on $EXT_IF inet proto tcp from $EXT_IF:network to any > port domain keep state flags S/SA > > # incoming SSH > > pass in quick on $EXT_IF inet proto tcp from $EXT_IF:network to port > 2022 keep state flags S/SA > > # incoming FTP > > # ftp command channel > pass in quick on $EXT_IF inet proto tcp from any to $EXT_IF port ftp > keep state flags S/SA > > # ftp data channel (passive) > pass in quick on $EXT_IF inet proto tcp from any to $EXT_IF port > $PASSIVE keep state flags S/SA > > # ftp data channel (active) > # wrong direction!!! > pass in quick on $EXT_IF inet proto tcp from any to $EXT_IF port > ftp-data keep state flags S/SA > > Here I also erroneously used port 20 as destination port. > > An active ftp command to upload a file aborts with > > 200 EPRT command successful. > 425 Can't build data connection: Operation not permitted. > > A pflog0 tcpdump shows the reason: > > tcpdump -eni pflog0 -s0 -v > tcpdump: WARNING: pflog0: no IPv4 address assigned > tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), > capture size 65535 bytes > 22:16:42.551221 rule 0/0(match): block out on fxp0: (tos 0x8, ttl 64, > id 2766, offset 0, flags [DF], proto TCP (6), length 60) > 192.168.222.244.20 > 192.168.222.20.62316: S, cksum 0xc222 (correct), > 488073960:488073960(0) win 65535 3,sackOK,timestamp 6278055 0> > > So this rule set blocks the first packet of the three-way TCP > handshake. > > 192.168.222.244.20 > 192.168.222.20.62316. > or > server.20 > client.62316 > > Your previous ruleset somehow created state or allowed the server to > initiate the data channel to the client somewhere else in your rule > set. It didn't create state on the initial packet of the TCP > handshake, where the TCP window size is negotiated. Just like the > Daniel Hartmeier article states, this a caused tcp window scaling > issue. > > Remember that in pf the last matching rule wins. > You only can defeat this behaviour by using the 'quick' keyword. > > After adding the following corrected rule the transfer proceeds > without any blockage > > # correct direction/source port > pass out quick on $EXT_IF inet proto tcp from any port ftp-data to > any keep state flags S/SA > > The rules as parsed are now: > > # pfctl -vvf /etc/pf.conf > No ALTQ support in kernel > ALTQ related functions disabled > Loaded 696 passive OS fingerprints > EXT_IF = "fxp0" > PASSIVE = "49152:65535" > set skip on { lo0 } > @0 block drop log all > @1 pass out quick on fxp0 inet proto udp from 192.168.222.0/24 to any > port = domain keep state > @2 pass out quick on fxp0 inet proto tcp from 192.168.222.0/24 to any > port = domain flags S/SA keep state > @3 pass in quick on fxp0 inet proto tcp from 192.168.222.0/24 to any > port = down flags S/SA keep state > @4 pass in quick on fxp0 inet proto tcp from any to 192.168.222.244 > port = ftp flags S/SA keep state > @5 pass in quick on fxp0 inet proto tcp from any to 192.168.222.244 > port 49152:65535 flags S/SA keep state > @6 pass in quick on fxp0 inet proto tcp from any to 192.168.222.244 > port = ftp-data flags S/SA keep state > @7 pass out quick on fxp0 inet proto tcp from any port = ftp-data to > any flags S/SA keep state > > Rule 6 is the rule with the wrong direction/port specification. > Rule 7 is the corrected one > > pflog0 doesn't show any errors: > tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), > capture size 65535 bytes > ^C > 0 packets captured > 0 packets received by filter > 0 packets dropped by kernel > > And a quick state check still showed some remnants of the connections > > # pfctl -ss > No ALTQ support in kernel > ALTQ related functions disabled > [snip] > all tcp 192.168.222.244:21 <- 192.168.222.20:13497 > FIN_WAIT_2:FIN_WAIT_2 > all tcp 192.168.222.244:20 -> 192.168.222.20:55246 > FIN_WAIT_2:FIN_WAIT_2 > all tcp 192.168.222.244:20 -> 192.168.222.20:59354 > FIN_WAIT_2:FIN_WAIT_2 > > The first state is the ftp command channel client:13497 > server:21 > The last two are the active data channels: server:20 > client:55246, > and server.20 > client.59354 > > Don't get confused, the last octet of the client IP (192.168.222.20) > happens to be the same as > the ftp-data port number. ;) > > A repeat of the transfer shows the following verbose state > > # pfctl -vvss > > all tcp 192.168.222.244:20 -> 192.168.222.20:64857 > ESTABLISHED:ESTABLISHED > [1427346948 + 65536] wscale 3 [200059941 + 37224] wscale 0 > age 00:00:02, expires in 24:00:00, 13716:20572 pkts, > 713240:30853060 bytes, rule 7 > id: 4b47883900000033 creatorid: c576b1b2 > > By using this command you should be able to figure out which actual > rule, here rule 7, creates state for the active ftp data channel. > > The same when the transfer has finished > > all tcp 192.168.222.244:20 -> 192.168.222.20:64857 > FIN_WAIT_2:FIN_WAIT_2 > [1427346950 + 65534] wscale 3 [259693437 + 66608] wscale 0 > age 00:00:59, expires in 00:00:38, 41209:61758 pkts, > 2142876:92628227 bytes, rule 7 > id: 4b47883900000033 creatorid: c576b1b2 > > Happy rule/state hunting > > Adriaan > > > all tcp 192.168.222.244:20 -> 192.168.222.20:64857 > FIN_WAIT_2:FIN_WAIT_2 > [1427346950 + 65534] wscale 3 [259693437 + 66608] wscale 0 > age 00:00:59, expires in 00:00:38, 41209:61758 pkts, > 2142876:92628227 bytes, rule 7 > id: 4b47883900000033 creatorid: c576b1b2 From owner-freebsd-pf@FreeBSD.ORG Sat Jan 9 20:27:24 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 381D21065670 for ; Sat, 9 Jan 2010 20:27:24 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 6584C8FC08 for ; Sat, 9 Jan 2010 20:27:22 +0000 (UTC) Received: (qmail 60473 invoked from network); 9 Jan 2010 23:00:41 +0300 Received: from tarkhil147-9.rostokino.net (tarkhil147-9.rostokino.net [89.222.147.9]) by mail.sub.ru ([88.212.205.2]) with ESMTP via TCP; 09 Jan 2010 20:00:41 -0000 Message-ID: <4B48E065.8070307@webmail.sub.ru> Date: Sat, 09 Jan 2010 23:00:37 +0300 From: Alex Povolotsky User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20091221 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <4AEC4A6F65A84D258332A61EF5980850@john> <9a542da30912110411g6d332409h9db4664b73ee1153@mail.gmail.com> In-Reply-To: <9a542da30912110411g6d332409h9db4664b73ee1153@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: FW: clientNatLookup: PF open failed: (13) Permission denied X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 20:27:24 -0000 On 12/11/09 15:11, Ermal Luçi wrote: > > Just allow the user with which you run squid permission of read(write?) to > /dev/pf. > > Well, what is the proper way to chgrp squid /dev/pf and chmod g+r /dev/pf automatically? Nothing better than rc.local or patching /usr/local/etc/rc.d/squid? Alex. From owner-freebsd-pf@FreeBSD.ORG Sat Jan 9 20:38:02 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 991AE106566C for ; Sat, 9 Jan 2010 20:38:02 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id C224C8FC08 for ; Sat, 9 Jan 2010 20:38:01 +0000 (UTC) Received: (qmail 72841 invoked from network); 9 Jan 2010 23:38:00 +0300 Received: from tarkhil147-9.rostokino.net (tarkhil147-9.rostokino.net [89.222.147.9]) by mail.sub.ru ([88.212.205.2]) with ESMTP via TCP; 09 Jan 2010 20:38:00 -0000 Message-ID: <4B48E927.1030706@webmail.sub.ru> Date: Sat, 09 Jan 2010 23:37:59 +0300 From: Alex Povolotsky User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20091221 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <4AEC4A6F65A84D258332A61EF5980850@john> <9a542da30912110411g6d332409h9db4664b73ee1153@mail.gmail.com> <4B48E065.8070307@webmail.sub.ru> In-Reply-To: <4B48E065.8070307@webmail.sub.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FW: clientNatLookup: PF open failed: (13) Permission denied X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 20:38:02 -0000 On 01/09/10 23:00, Alex Povolotsky wrote: > Well, what is the proper way to chgrp squid /dev/pf and chmod g+r > /dev/pf automatically? Nothing better than rc.local or patching > /usr/local/etc/rc.d/squid? Quite simple; I should figure it out at once. use devd.conf Alex.