From owner-freebsd-pf@FreeBSD.ORG Fri Apr 28 13:39:54 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E07316A410 for ; Fri, 28 Apr 2006 13:39:54 +0000 (UTC) (envelope-from dimas@dataart.com) Received: from relay1.dataart.com (fobos.marketsite.ru [62.152.84.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5953543D46 for ; Fri, 28 Apr 2006 13:39:51 +0000 (GMT) (envelope-from dimas@dataart.com) Received: from e1.universe.dart.spb ([192.168.10.44]) by relay1.dataart.com with esmtp (Exim 4.22) id 1FZTCH-0005GU-UD for freebsd-pf@freebsd.org; Fri, 28 Apr 2006 17:39:49 +0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Apr 2006 17:38:29 +0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPSEC tunnel problem thread-index: AcZqyThjKu1flU0KRW+kxPLFMtmK3g== From: "Dmitry Andrianov" To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: IPSEC tunnel 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, 28 Apr 2006 13:39:54 -0000 Hello. First of all I apologize if I freebsd-pf is not the rigth place to ask my question. I will explain below why it is actually asked here. But if anyone knows the better place, let me know. =20 On FreeBSD-6.0 I have setup IPSEC VPN tunnel as explained in the FreeBSD Handbook - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html I also have applied kern/91412 patch ( http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/91412 ) because it seemed related to the issue. Unfortunately, the problem was exactly the same before and after applying the patch. =20 User-visible sympthoms: a user connects to MS Remote Desktop server through VPN tunnel and works for some time. At some random moment, RD hangs. =20 tcpdump on server's side ethernet interface at that moment starts observing ICMP host unreach packets: =20 (192.168.194.90 is the server while 192.168.10.176 is the client) =20 17:11:17.471023 IP 192.168.194.90.3389 > 192.168.10.176.4941: P 64012:65378(1366) ack 4236 win 64341 17:11:17.496187 IP 192.168.10.176.4941 > 192.168.194.90.3389: . ack 63407 win 32409 17:11:17.496866 IP 192.168.194.90.3389 > 192.168.10.176.4941: P 65378:66582(1204) ack 4236 win 64341 17:11:17.497008 IP 192.168.194.90.3389 > 192.168.10.176.4941: P 66582:67376(794) ack 4236 win 64341 17:11:17.497030 IP 192.168.194.1 > 192.168.194.90: ICMP host 192.168.10.176 unreachable, length 36 17:11:17.509615 IP 192.168.10.176.4941 > 192.168.194.90.3389: . ack 65378 win 33580 17:11:17.512078 IP 192.168.10.176.4941 > 192.168.194.90.3389: P 4236:4253(17) ack 65378 win 33580 17:11:17.516507 IP 192.168.194.90.3389 > 192.168.10.176.4941: P 67376:68526(1150) ack 4253 win 64324 17:11:17.516529 IP 192.168.194.1 > 192.168.194.90: ICMP host 192.168.10.176 unreachable, length 36 17:11:17.516586 IP 192.168.194.90.3389 > 192.168.10.176.4941: P 68526:69455(929) ack 4253 win 64324 17:11:17.516607 IP 192.168.194.1 > 192.168.194.90: ICMP host 192.168.10.176 unreachable, length 36 17:11:17.516750 IP 192.168.194.90.3389 > 192.168.10.176.4941: P 69455:70642(1187) ack 4253 win 64324 17:11:17.516772 IP 192.168.194.1 > 192.168.194.90: ICMP host 192.168.10.176 unreachable, length 36 17:11:17.619311 IP 192.168.10.176.4941 > 192.168.194.90.3389: P 4253:4319(66) ack 66582 win 32376 17:11:17.773334 IP 192.168.10.176.4941 > 192.168.194.90.3389: P 4319:4350(31) ack 66582 win 32376 17:11:17.773514 IP 192.168.194.90.3389 > 192.168.10.176.4941: . ack 4350 win 64227 17:11:17.891308 IP 192.168.10.176.4941 > 192.168.194.90.3389: P 4350:4423(73) ack 66582 win 32376 17:11:17.997662 IP 192.168.10.176.4941 > 192.168.194.90.3389: P 4423:4475(52) ack 66582 win 32376 17:11:17.997841 IP 192.168.194.90.3389 > 192.168.10.176.4941: . ack 4475 win 65535 17:11:18.106066 IP 192.168.10.176.4941 > 192.168.194.90.3389: P 4475:4541(66) ack 66582 win 32376 17:11:18.157117 IP 192.168.194.90.3389 > 192.168.10.176.4941: P 66582:67970(1388) ack 4541 win 65469 17:11:18.157140 IP 192.168.194.1 > 192.168.194.90: ICMP host 192.168.10.176 unreachable, length 36 =20 So, why freebsd-pf? Because I noticed in pfctl -s info output that "state-mismatch" counter which normally is still, starts rapidly incrementing when such a "hangups" occur. At the same time, pf should not return ICMP messages because of =20 set block-policy drop =20 and=20 =20 block drop log all =20 as the first rule. I do not have any "block return" rules so I have no idea who returns ICMP, why it does so and what pf counts as state-mismatch. =20 The problem is 100% reproduceable and I can gather ani additional statistics/output if it is needed. =20 Again, if I should ask in another place, let me know. =20 Regards, Dmitry Andrianov