From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 02:25: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 D3863106566C for ; Wed, 28 Jul 2010 02:25:00 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [69.42.208.18]) by mx1.freebsd.org (Postfix) with ESMTP id BE23A8FC1A for ; Wed, 28 Jul 2010 02:25:00 +0000 (UTC) Received: from [192.168.1.64] (99-118-214-35.lightspeed.irvnca.sbcglobal.net [99.118.214.35]) by sed.awknet.com (Postfix) with ESMTP id 59D5B107D9B1; Wed, 28 Jul 2010 02:25:00 +0000 (UTC) Message-ID: <4C4F94F8.5050709@sk1llz.net> Date: Tue, 27 Jul 2010 19:24:56 -0700 From: Justin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Daniel Hartmeier , freebsd-pf@freebsd.org References: <4C4D7EED.4060704@sk1llz.net> <20100727074850.GB1114@insomnia.benzedrine.cx> <4C4F8D19.2020609@sk1llz.net> In-Reply-To: <4C4F8D19.2020609@sk1llz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: pf synproxy 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, 28 Jul 2010 02:25:00 -0000 - tcpdumps showing the initial connect attempt (logs below were furhter along the process); external: 02:21:25.595977 IP (tos 0x0, ttl 118, id 10020, offset 0, flags [DF], proto TCP (6), length 52) REMOTE_VIEWING_HOST.53782 > CLIENT_DESTINATION_IP.80: Flags [S], cksum 0x537b (correct), se q 2569879850, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 02:21:25.596000 IP (tos 0x10, ttl 64, id 27957, offset 0, flags [DF], proto TCP (6), length 44) CLIENT_DESTINATION_IP.80 > REMOTE_VIEWING_HOST.53782: Flags [S.], cksum 0x7920 (correct), s eq 3819585455, ack 2569879851, win 0, options [mss 1460], length 0 02:21:25.605825 IP (tos 0x0, ttl 118, id 10021, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_VIEWING_HOST.53782 > CLIENT_DESTINATION_IP.80: Flags [.], cksum 0x95ec (correct), ac k 3819585456, win 64240, length 0 02:21:25.615953 IP (tos 0x0, ttl 118, id 10022, offset 0, flags [DF], proto TCP (6), length 40) internal: 02:22:34.717332 IP (tos 0x0, ttl 118, id 22015, offset 0, flags [DF], proto TCP (6), length 52) REMOTE_VIEWING_HOST.53786 > CLIENT_DESTINATION_IP.80: Flags [S], cksum 0x84ee (correct), se q 1816476827, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 02:22:34.717354 IP (tos 0x10, ttl 64, id 39898, offset 0, flags [DF], proto TCP (6), length 44) CLIENT_DESTINATION_IP.80 > REMOTE_VIEWING_HOST.53786: Flags [S.], cksum 0x1d5d (correct), s eq 76721150, ack 1816476828, win 0, options [mss 1460], length 0 02:22:34.728880 IP (tos 0x0, ttl 118, id 22016, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_VIEWING_HOST.53786 > CLIENT_DESTINATION_IP.80: Flags [.], cksum 0x3a29 (correct), ac k 76721151, win 64240, length 0 02:22:34.742691 IP (tos 0x0, ttl 118, id 22017, offset 0, flags [DF], proto TCP (6), length 40) On 7/27/2010 6:51 PM, Justin wrote: > Hello Daniel, > > Didn't get any sort of information from pfctl -x misc. Here's the > output from the commands you suggested; > > (3 SSH connections to run/log the tcpdump and pfctl outputs, 1 > attempted proxy) > > Pre HTTP end host attempt; > > # pfctl -vvsi > No ALTQ support in kernel > ALTQ related functions disabled > Status: Enabled for 0 days 00:01:21 Debug: Urgent > > Hostid: 0x144de36b > Checksum: 0xda84c38c7e2412bb81511fe0620a1012 > > State Table Total Rate > current entries 9 > searches 407 5.0/s > inserts 22 0.3/s > removals 13 0.2/s > Source Tracking Table > current entries 0 > searches 0 0.0/s > inserts 0 0.0/s > removals 0 0.0/s > Counters > match 26 0.3/s > bad-offset 0 0.0/s > fragment 0 0.0/s > short 0 0.0/s > normalize 0 0.0/s > memory 0 0.0/s > bad-timestamp 0 0.0/s > congestion 0 0.0/s > ip-option 0 0.0/s > proto-cksum 0 0.0/s > state-mismatch 0 0.0/s > state-insert 0 0.0/s > state-limit 0 0.0/s > src-limit 0 0.0/s > synproxy 14 0.2/s > Limit Counters > max states per rule 0 0.0/s > max-src-states 0 0.0/s > max-src-nodes 0 0.0/s > max-src-conn 0 0.0/s > max-src-conn-rate 0 0.0/s > overload table insertion 0 0.0/s > overload flush states 0 0.0/s > > > after attempt and failure; > > # pfctl -vvsi > No ALTQ support in kernel > ALTQ related functions disabled > Status: Enabled for 0 days 00:02:53 Debug: Urgent > > Hostid: 0x144de36b > Checksum: 0xda84c38c7e2412bb81511fe0620a1012 > > State Table Total Rate > current entries 5 > searches 9552 55.2/s > inserts 25 0.1/s > removals 20 0.1/s > Source Tracking Table > current entries 0 > searches 0 0.0/s > inserts 0 0.0/s > removals 0 0.0/s > Counters > match 35 0.2/s > bad-offset 0 0.0/s > fragment 0 0.0/s > short 0 0.0/s > normalize 0 0.0/s > memory 0 0.0/s > bad-timestamp 0 0.0/s > congestion 0 0.0/s > ip-option 0 0.0/s > proto-cksum 0 0.0/s > state-mismatch 0 0.0/s > state-insert 0 0.0/s > state-limit 0 0.0/s > src-limit 0 0.0/s > synproxy 3274 18.9/s > Limit Counters > max states per rule 0 0.0/s > max-src-states 0 0.0/s > max-src-nodes 0 0.0/s > max-src-conn 0 0.0/s > max-src-conn-rate 0 0.0/s > overload table insertion 0 0.0/s > overload flush states 0 0.0/s > > > > # pfctl -vvss > No ALTQ support in kernel > ALTQ related functions disabled > all tcp FIREWALL_EXTERNAL_IP:22 <- REMOTE_VIEWING_HOST:53065 > ESTABLISHED:ESTABLISHED > [51278071 + 64060](+3232864399) [4177391361 + 65535](+803461391) > age 00:02:49, expires in 04:59:45, 515:920 pkts, 28140:866768 > bytes, rule 3 > id: 4c4f86b600000031 creatorid: 144de36b > all tcp FIREWALL_EXTERNAL_IP:22 <- REMOTE_VIEWING_HOST:53067 > ESTABLISHED:ESTABLISHED > [3663860670 + 63784](+2459193596) [1446109858 + 65535](+1445587765) > age 00:02:19, expires in 04:59:45, 490:862 pkts, 27452:809608 > bytes, rule 3 > id: 4c4f86b60000003b creatorid: 144de36b > all tcp FIREWALL_EXTERNAL_IP:22 <- REMOTE_VIEWING_HOST:53070 > ESTABLISHED:ESTABLISHED > [1850293048 + 63336](+3364896299) [442076181 + 65535](+2933418221) > age 00:02:00, expires in 05:00:00, 84:108 pkts, 7728:17192 bytes, > rule 3 > id: 4c4f86b600000042 creatorid: 144de36b > all tcp CLIENT_DESTINATION_IP:80 <- REMOTE_VIEWING_HOST:53075 > PROXY:DST > [0 + 3477913824] [3572604858 + 3688639377] > age 00:00:26, expires in 00:00:04, 0:0 pkts, 0:0 bytes, rule 3 > id: 4c4f86b600000048 creatorid: 144de36b > > > tcpdump -nvSi [interface] tcp port 80 > > external interface: > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.], > cksum 0xa59b (correct), ack 2966276940, win 64240, length 0 > 01:39:14.466318 IP (tos 0x0, ttl 118, id 27612, offset 0, flags [DF], > proto TCP (6), length 40) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.], > cksum 0xa59b (correct), ack 2966276940, win 64240, length 0 > 01:39:14.467753 IP (tos 0x0, ttl 118, id 27613, offset 0, flags [DF], > proto TCP (6), length 40) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.], > cksum 0xa59b (correct), ack 2966276940, win 64240, length 0 > 01:39:14.468718 IP (tos 0x0, ttl 118, id 27614, offset 0, flags [DF], > proto TCP (6), length 40) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.], > cksum 0xa59b (correct), ack 2966276940, win 64240, length 0 > 01:39:14.469965 IP (tos 0x0, ttl 118, id 27615, offset 0, flags [DF], > proto TCP (6), length 40) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.], > cksum 0xa59b (correct), ack 2966276940, win 64240, length 0 > 01:39:14.470957 IP (tos 0x0, ttl 118, id 27616, offset 0, flags [DF], > proto TCP (6), length 40) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [R.], > cksum 0xa088 (correct), seq 3572604859, ack 2966276940, win 0, length 0 > > internal interface: > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S], > cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460], > length 0 > 01:39:14.467760 IP (tos 0x10, ttl 64, id 8944, offset 0, flags [DF], > proto TCP (6), length 44) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S], > cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460], > length 0 > 01:39:14.468725 IP (tos 0x10, ttl 64, id 8945, offset 0, flags [DF], > proto TCP (6), length 44) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S], > cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460], > length 0 > 01:39:14.469969 IP (tos 0x10, ttl 64, id 8946, offset 0, flags [DF], > proto TCP (6), length 44) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S], > cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460], > length 0 > 01:39:14.470964 IP (tos 0x10, ttl 64, id 8947, offset 0, flags [DF], > proto TCP (6), length 44) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S], > cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460], > length 0 > 01:39:34.524975 IP (tos 0x10, ttl 64, id 9091, offset 0, flags [DF], > proto TCP (6), length 40) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [R.], > cksum 0xa089 (correct), seq 2966276939, ack 3572604859, win 0, length 0 > > > > On 7/27/2010 12:48 AM, Daniel Hartmeier wrote: >> On Mon, Jul 26, 2010 at 05:26:21AM -0700, Justin wrote: >> >>> When using synproxy state - the connection never completes. If we >>> change >>> synproxy to keep, everything works fine. Alternately, if the service in >>> question is running locally on the actual firewall itself, I'll see >>> state entries show up in pfctl -s doing a proxy and then passing the >>> connection on to its self - so why doesn't it work in the same manner >>> when passing on to a host behind the machine? I've tried all sorts of >>> variations and skipping processing on internal interface, but I just >>> can't seem to get it to work. All my searching has turned up nothing. >>> I've also tried state-policy if-bound and there appears to be no >>> change. >>> Is this a bug? Have I missed something totally obvious? >> Concurrently run >> >> # tcpdump -nvSi em0 tcp port 80 >> >> and >> >> # tcpdump -nvSi em1 tcp port 80 >> >> and reproduce one connection failure. What do you see? >> Does the TCP handshake (SYN, SYN+ACK, ACK) complete between >> client and pf? And the one between pf and the server? >> >> Right after the failure, does pfctl -vvss show a state entry >> for the failed connection? What does it look like? >> >> Run pfctl -vvsi before and after the failure. Which counters >> are increasing? >> >> Enable verbose logging (pfctl -x misc), does /var/log/messages >> show any message possibly related to the failure? >> >> Kind regards, >> Daniel > > _______________________________________________ > 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"