From owner-freebsd-pf@FreeBSD.ORG Mon Sep 5 11:07:14 2011 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 D992B106564A for ; Mon, 5 Sep 2011 11:07:14 +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 BE7C78FC18 for ; Mon, 5 Sep 2011 11:07:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p85B7E25065958 for ; Mon, 5 Sep 2011 11:07:14 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p85B7EqQ065956 for freebsd-pf@FreeBSD.org; Mon, 5 Sep 2011 11:07:14 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Sep 2011 11:07:14 GMT Message-Id: <201109051107.p85B7EqQ065956@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, 05 Sep 2011 11:07:15 -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/160370 pf [pf] Incorrect pfctl check of pf.conf o kern/159390 pf [pf] [panic] mutex pf task mtx owned at /usr/src/sys/c o kern/159029 pf [pf] [panic] m_copym, offset > size of mbuf chain when o kern/158873 pf [pf] [panic] When I launch pf daemon, I have a kernel o kern/158636 pf [pf] if_pfsync.c fails to build when NBPFILTER == 0 o kern/155736 pf [pf] [altq] borrow from parent queue does not work wit o kern/153307 pf [pf] Bug with PF firewall o kern/148290 pf [pf] "sticky-address" option of Packet Filter (PF) blo o kern/148260 pf [pf] [patch] pf rdr incompatible with dummynet o kern/147789 pf [pf] Firewall PF no longer drops connections by sendin o kern/146832 pf [pf] "(self)" not always matching all local IPv6 addre o kern/143543 pf [pf] [panic] PF route-to causes kernel panic o bin/143504 pf [patch] outgoing states are not killed by authpf(8) o conf/142961 pf [pf] No way to adjust pidfile in pflogd o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl 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/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 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 51 problems total. From owner-freebsd-pf@FreeBSD.ORG Tue Sep 6 02:02:11 2011 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EB8D106564A; Tue, 6 Sep 2011 02:02:11 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 162118FC13; Tue, 6 Sep 2011 02:02:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p8622AWP000552; Tue, 6 Sep 2011 02:02:10 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p8622A7D000547; Tue, 6 Sep 2011 02:02:10 GMT (envelope-from linimon) Date: Tue, 6 Sep 2011 02:02:10 GMT Message-Id: <201109060202.p8622A7D000547@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-pf@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/160496: [pf] [patch] kernel panic with pf + VIMAGE 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: Tue, 06 Sep 2011 02:02:11 -0000 Old Synopsis: [patch] kernel panic with pf + VIMAGE New Synopsis: [pf] [patch] kernel panic with pf + VIMAGE Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 6 02:01:39 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=160496 From owner-freebsd-pf@FreeBSD.ORG Tue Sep 6 10:04:36 2011 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24C5D106564A; Tue, 6 Sep 2011 10:04:36 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F10E28FC08; Tue, 6 Sep 2011 10:04:35 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p86A4ZMk076467; Tue, 6 Sep 2011 10:04:35 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p86A4ZnB076463; Tue, 6 Sep 2011 10:04:35 GMT (envelope-from bz) Date: Tue, 6 Sep 2011 10:04:35 GMT Message-Id: <201109061004.p86A4ZnB076463@freefall.freebsd.org> To: bz@FreeBSD.org, freebsd-pf@FreeBSD.org, freebsd-virtualization@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/160496: [pf] [patch] kernel panic with pf + VIMAGE 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: Tue, 06 Sep 2011 10:04:36 -0000 Synopsis: [pf] [patch] kernel panic with pf + VIMAGE Responsible-Changed-From-To: freebsd-pf->freebsd-virtualization Responsible-Changed-By: bz Responsible-Changed-When: Tue Sep 6 10:04:16 UTC 2011 Responsible-Changed-Why: Move to vritualization where we aggregate VIMAGE PRs. http://www.freebsd.org/cgi/query-pr.cgi?pr=160496 From owner-freebsd-pf@FreeBSD.ORG Thu Sep 8 06:12:19 2011 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35C55106566C; Thu, 8 Sep 2011 06:12:18 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C83D48FC14; Thu, 8 Sep 2011 06:12:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p886CIqp073640; Thu, 8 Sep 2011 06:12:18 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p886CIBK073636; Thu, 8 Sep 2011 06:12:18 GMT (envelope-from linimon) Date: Thu, 8 Sep 2011 06:12:18 GMT Message-Id: <201109080612.p886CIBK073636@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-pf@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/160541: [vimage][pf][patch] panic: userret: Returning on td 0xxxxxxxxx (pid xxxx, pftop) with vnet 0xxxxxxxxx set in pfioctl 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, 08 Sep 2011 06:12:19 -0000 Synopsis: [vimage][pf][patch] panic: userret: Returning on td 0xxxxxxxxx (pid xxxx, pftop) with vnet 0xxxxxxxxx set in pfioctl Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Thu Sep 8 06:12:12 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=160541 From owner-freebsd-pf@FreeBSD.ORG Thu Sep 8 13:05:51 2011 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 DAAAD1065676 for ; Thu, 8 Sep 2011 13:05:51 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC368FC0A for ; Thu, 8 Sep 2011 13:05:51 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id A00D91FFC35 for ; Thu, 8 Sep 2011 12:47:29 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 60A2484530; Thu, 8 Sep 2011 14:47:29 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: freebsd-pf@freebsd.org Date: Thu, 08 Sep 2011 14:47:29 +0200 Message-ID: <868vpzqjz2.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: route-to rule 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, 08 Sep 2011 13:05:51 -0000 According to the pf.conf(5) man page in FreeBSD 8.2, the address part of the route-to destination is optional: route =3D ( "route-to" | "reply-to" | "dup-to" ) ( routehost | "{" routehost-list "}" ) [ pooltype ] routehost =3D "(" interface-name [ address [ "/" mask-bits ] ] ")" routehost-list =3D routehost [ [ "," ] routehost-list ] but pf complains of a syntax error if I leave it out, so pass in on $lan2 route-to ($ext2) from ($lan2:network) doesn't work, while pass in on $lan2 route-to ($ext2 172.16.0.1) from ($lan2:network) does. I realize that pf can't *know* the correct next-hop address for the specified interface, but it can make a reasonable guess (first non-zero address in $ext2:network), so hard-coding would only be required in cases where the "reasonable guess" is incorrect or $ext2 has multiple IP addresses. Also, there does not seem to be a way to complement a host-list: hosts =3D "all" | "from" ( "any" | "no-route" | "urpf-failed" | "self" = | host | "{" host-list "}" | "route" string ) [ port ] [ os ] "to" ( "any" | "no-route" | "self" | host | "{" host-list "}" | "route" string ) [ port ] host =3D [ "!" ] ( address [ "/" mask-bits ] | "<" string ">= " ) host-list =3D host [ [ "," ] host-list ] so you can say { $lan1:network, $lan2:network } but not ! { $lan1:network, $lan2:network } As a result, a rule such as=20 pass in on $lan2 route-to ($ext2 172.16.0.1) from ($lan2:network) to !$lan= 2:network means that traffic from $lan2:network to $lan1:network will be routed through $ext2 instead of going directly to $lan1. I can add explicit route-to rules to circumvent that, but I'd much rather use something like this: pass in on $lan2 route-to ($ext2 172.16.0.1) from ($lan2:network) to ! { $= lan1:network, $lan2:network } (I checked Reed's book and both edition of Hansteen's, but Reed makes no sense, and Hansteen doesn't mention route-to at all) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-pf@FreeBSD.ORG Thu Sep 8 14:27:59 2011 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 42290106564A for ; Thu, 8 Sep 2011 14:27:59 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 9A7988FC0C for ; Thu, 8 Sep 2011 14:27:58 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id p88EARkQ020095 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 16:10:27 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id p88EAQ0t026240; Thu, 8 Sep 2011 16:10:26 +0200 (MEST) Date: Thu, 8 Sep 2011 16:10:26 +0200 From: Daniel Hartmeier To: Dag-Erling Sm??rgrav Message-ID: <20110908141026.GB10185@insomnia.benzedrine.cx> References: <868vpzqjz2.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <868vpzqjz2.fsf@ds4.des.no> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-pf@freebsd.org Subject: Re: route-to rule 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, 08 Sep 2011 14:27:59 -0000 On Thu, Sep 08, 2011 at 02:47:29PM +0200, Dag-Erling Sm??rgrav wrote: > According to the pf.conf(5) man page in FreeBSD 8.2, the address part of > but pf complains of a syntax error if I leave it out, so > > pass in on $lan2 route-to ($ext2) from ($lan2:network) > > doesn't work, while > > pass in on $lan2 route-to ($ext2 172.16.0.1) from ($lan2:network) > > does. The BNF syntax is slighty wrong, the parentheses are needed when both interface and address are specified. If only the interface is specified, no parentheses are needed or allowed, i.e. try pass in on $lan2 route-to $ext2 from ($lan2:network) > I realize that pf can't *know* the correct next-hop address for the > specified interface, but it can make a reasonable guess (first non-zero > address in $ext2:network), so hard-coding would only be required in > cases where the "reasonable guess" is incorrect or $ext2 has multiple IP > addresses. There is no guessing involved. If you specify the addresses, this address is used for an arp lookup, and the ethernet frame will have this IP address' MAC address as destination. If you don't specify the address, the destination IP address of the matching packet is used for the arp lookup instead! If that destination IP address is not local (i.e. must be sent through a next-hop), you MUST specify the next-hop address, or the packet will be dropped, as arp resolution will fail. So, specifying the next-hop address is not really "optional". You may even have to split a route-to rule into two separate rules (one with and the other without specifying the next-hop), when some (but not all) possibly matching destinations are local (arp resolvable). > so you can say > > { $lan1:network, $lan2:network } > > but not > > ! { $lan1:network, $lan2:network } The reason this is not supported is purely technical, as a single rule with an address list expands to multiple rules internally. And this particular construct would expand to the two rules pass ... from ! $lan1:network pass ... from ! $lan2:network which would match every possible source, not what any user whould ever expect the construct to do. More details on http://www.openbsd.org/faq/pf/macros.html search for "negated list". Short answer: usually an address table can be used instead of an address list, i.e. table const { $lan1:network $lan2:network } pass ... from ! Kind regards, Daniel From owner-freebsd-pf@FreeBSD.ORG Thu Sep 8 16:22:10 2011 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 29C351065673 for ; Thu, 8 Sep 2011 16:22:10 +0000 (UTC) (envelope-from rob@ipninja.net) Received: from storm.ipninja.net (mail.ipninja.net [IPv6:2001:4978:1cc:0:215:f2ff:fe67:cafa]) by mx1.freebsd.org (Postfix) with ESMTP id E78548FC19 for ; Thu, 8 Sep 2011 16:22:09 +0000 (UTC) Received: from gambit ([IPv6:2001:4978:1cc:0:38e3:2275:f417:1183]) (authenticated bits=0) by storm.ipninja.net (8.14.4/8.14.5) with ESMTP id p88GKTn0001428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Sep 2011 12:20:35 -0400 (EDT) (envelope-from rob@ipninja.net) From: "Rob V" To: "'Daniel Hartmeier'" , "'Dag-Erling Sm??rgrav'" References: <868vpzqjz2.fsf@ds4.des.no> <20110908141026.GB10185@insomnia.benzedrine.cx> In-Reply-To: <20110908141026.GB10185@insomnia.benzedrine.cx> Date: Thu, 8 Sep 2011 12:20:06 -0400 Message-ID: <000601cc6e43$33c78640$9b5692c0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxuM4iJ4t6xEXLyQW2iBmrYJTQSgQAD2guA Content-Language: en-ca X-Spam-Status: No, score=-97.3 required=5.0 tests=DOS_OUTLOOK_TO_MX, FSL_HELO_NON_FQDN_1, HELO_NO_DOMAIN, RAWR2, RDNS_NONE autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on storm.ipninja.net Cc: freebsd-pf@freebsd.org Subject: RE: route-to rule 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, 08 Sep 2011 16:22:10 -0000 >> I realize that pf can't *know* the correct next-hop address for the >> specified interface, but it can make a reasonable guess (first non-zero >> address in $ext2:network), so hard-coding would only be required in >> cases where the "reasonable guess" is incorrect or $ext2 has multiple IP >> addresses. > > There is no guessing involved. If you specify the addresses, this > address is used for an arp lookup, and the ethernet frame will have > this IP address' MAC address as destination. > > If you don't specify the address, the destination IP address of the > matching packet is used for the arp lookup instead! > > If that destination IP address is not local (i.e. must be sent through > a next-hop), you MUST specify the next-hop address, or the packet will > be dropped, as arp resolution will fail. Unless your router is doing proxy arp. From owner-freebsd-pf@FreeBSD.ORG Fri Sep 9 16:08:48 2011 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 9B12D106566C; Fri, 9 Sep 2011 16:08:48 +0000 (UTC) (envelope-from flo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7E4568FC08; Fri, 9 Sep 2011 16:08:48 +0000 (UTC) Received: from [IPv6:::1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p89G8lfn021065; Fri, 9 Sep 2011 16:08:47 GMT (envelope-from flo@FreeBSD.org) Message-ID: <4E6A3A0D.7020800@FreeBSD.org> Date: Fri, 09 Sep 2011 18:08:45 +0200 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?UTF-8?B?RXJtYWwgTHXDp2k=?= , bz@FreeBSD.org References: <201106281157.p5SBvP5g048097@svn.freebsd.org> <20110629192224.2283efc8@fabiankeil.de> <20110707193539.GA60591@dragon.NUXI.org> <20110708170240.GA59024@dragon.NUXI.org> <4E4BB39D.8070903@freebsd.org> <22DE2AEF-22A3-4B6E-9E24-DCF0EDF40933@lists.zabbadoz.net> <4E4BB602.2060205@freebsd.org> <4E4BBCB0.4090003@freebsd.org> <4E4DA196.7090304@userid.org> <4E4E30A2.7040509@freebsd.org> In-Reply-To: <4E4E30A2.7040509@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@FreeBSD.org Subject: Re: svn commit: r223637 - in head: . contrib/pf/authpf contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pflogd sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/modules s... 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, 09 Sep 2011 16:08:48 -0000 On 19.08.11 11:45, Florian Smeets wrote: > On 19.08.2011 01:34, Pierre Lamy wrote: >> I just found how to resolve the problem (1 minute ago) as I was also >> having the same issue. If you compile pf into the kernel, state removals >> are NOT performed at all. pftop will show you garbage null entries. >> Flushing current states works for real states, but the malloc is never >> cleared for the garbage entries. Eventually you will run out of memory >> (max state entries too high), or be unable to add any more states. A >> reboot is the only way to clear it. >> >> I recompiled as a module and not in the kernel, it "just works" without >> any special extra steps. >> > > I can confirm (using the same kernel sources as before) that using the > modules fixed the problem for me too. > Hi, does anybody have an idea what could cause this? I think this is something that should be fixed before the release, as this can cause quite some pain for people who compile pf into the kernel. I tried to track this down, but i failed. Should file a PR to track this? Thanks, Florian From owner-freebsd-pf@FreeBSD.ORG Fri Sep 9 20:00:49 2011 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 74747106566B; Fri, 9 Sep 2011 20:00:49 +0000 (UTC) (envelope-from mlobo@digiart.art.br) Received: from capella.hmnoc.net (capella.hmnoc.net [174.122.209.54]) by mx1.freebsd.org (Postfix) with ESMTP id 421148FC0A; Fri, 9 Sep 2011 20:00:49 +0000 (UTC) Received: from [186.212.242.15] (port=63422 helo=papi.localnet) by capella.hmnoc.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R26uT-0005Xv-0M; Fri, 09 Sep 2011 16:38:45 -0300 From: Mario Lobo To: freebsd-pf@freebsd.org Date: Fri, 9 Sep 2011 16:38:51 -0300 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.2; amd64; ; ) X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201109091638.51633.mlobo@digiart.art.br> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - capella.hmnoc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - digiart.art.br Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-questions@freebsd.org Subject: VPN 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, 09 Sep 2011 20:00:49 -0000 Hi; I've been having this problem closing a VPN behind a FreeBSD 8-STABLE with pf. I have this scenario: home LAN ---- FBSD+pf home ---- INTERNET --- FBSD+pf work --- work LAN MPD VPN server nat on $ext_if from $int_if:network to any -> ($ext_if) port 1024:65535 # nat on $ext_if from any to any -> ($ext_if) port 1024:65535 obs- it makes no difference which nat rule I use. The problem persists. These are the first 5 pf rules on FBSD+pf home: # pass quick all pass quick on lo0 all # my whole home lan is free pass in quick on $int_if from $int_if:network to any #--- Allow networks to see themselves and dns pass quick from $int_if:network to $int_if:network #--- Allow vpns from anywhere to anywhere pass in quick log on $int_if proto gre from any to any keep state pass in quick log on $int_if proto tcp from any to any port pptp flags S/SA keep state On any attempt to conect to the FBSD+pf work VPN Server from home LAN, I get this (even if I uncomment pass quick all): #>mpd5 Multi-link PPP daemon for FreeBSD process 98799 started, version 5.5 (root@Papi 16:55 3-Sep-2011) CONSOLE: listening on 127.0.0.1 5005 web: listening on 127.0.0.1 5006 [B1] Bundle: Interface ng0 created [L1] [L1] Link: OPEN event [L1] LCP: Open event [L1] LCP: state change Initial --> Starting [L1] LCP: LayerStart [L1] PPTP call successful [L1] Link: UP event [L1] LCP: Up event [L1] LCP: state change Starting --> Req-Sent [L1] LCP: SendConfigReq #1 [L1] ACFCOMP [L1] PROTOCOMP [L1] ACCMAP 0x000a0000 [L1] MRU 1486 [L1] MAGICNUM 2d08ae01 [snip..] [L1] LCP: SendConfigReq #10 [L1] ACFCOMP [L1] PROTOCOMP [L1] ACCMAP 0x000a0000 [L1] MRU 1486 [L1] MAGICNUM 2d08ae01 [L1] LCP: parameter negotiation failed [L1] LCP: state change Req-Sent --> Stopped [L1] LCP: LayerFinish [L1] PPTP call terminated [L1] Link: DOWN event [L1] LCP: Close event [L1] LCP: state change Stopped --> Closed [L1] LCP: Down event [L1] LCP: state change Closed --> Initial BUT, on the 9th or 10th attempt, without touching any setting anywhere, the VPN MAY BE established. out of nothing ! Machines (Windows, unix, whatever) behind both FBSD+pfs ALSO have the same problem when trying to close VPN tunnels to outside sites. The FBSD+pf work VPN Server is working fine. My coleagues can conect to it from their homes (NATted cable modems or 3G modems) without problems. I am the only one behind a FBSD+pf router. I installed MPD5 on FBSD+pf home, and copied mpd.conf from my home workstation to it. Without touching a single setting on mpd.conf, the VPN is established from FBSD+pf home (as a client) to FBSD+pf work WITHOUT any hickups on EVERY SINGLE attempt! even I bring it up/down 200 times! And yet, if the FBSD+pf combo is out of the way, (i.e. no NAT!, as is the case of FBSD+pf home as a client) or if I let my cable modem do the NAT/routing, the problem is GONE!. FreeBSD work FreeBSD 8.2-STABLE #0: Mon Aug 22 14:50:42 BRT 2011 amd64 FreeBSD Home FreeBSD FreeBSD 8.2-STABLE #0: Wed May 18 16:53:26 BRT 2011 i386 Any suggestions? -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) From owner-freebsd-pf@FreeBSD.ORG Fri Sep 9 20:12:56 2011 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 3AA581065670 for ; Fri, 9 Sep 2011 20:12:56 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id E6F228FC0C for ; Fri, 9 Sep 2011 20:12:55 +0000 (UTC) Received: by yib19 with SMTP id 19so1403827yib.13 for ; Fri, 09 Sep 2011 13:12:55 -0700 (PDT) Received: by 10.236.22.9 with SMTP id s9mr14577462yhs.129.1315597572554; Fri, 09 Sep 2011 12:46:12 -0700 (PDT) Received: from papi.localnet ([186.212.242.15]) by mx.google.com with ESMTPS id n67sm7685471yhi.9.2011.09.09.12.46.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 12:46:11 -0700 (PDT) To: freebsd-pf@freebsd.org From: Mario Lobo Date: Fri, 9 Sep 2011 16:46:15 -0300 X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201109091646.15327.lobo@bsd.com.br> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-questions@freebsd.org Subject: VPN 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, 09 Sep 2011 20:12:56 -0000 Hi; I've been having this problem establishing a VPN behind a FreeBSD 8-STABLE with pf. I have this scenario: home LAN ---- FBSD+pf home ---- INTERNET --- FBSD+pf work --- work LAN MPD VPN server nat rules on FBSD+pf home: nat on $ext_if from $int_if:network to any -> ($ext_if) port 1024:65535 # nat on $ext_if from any to any -> ($ext_if) port 1024:65535 obs- it makes no difference which nat rule I use. The problem persists. These are the first 5 pf rules on FBSD+pf home: # pass quick all pass quick on lo0 all # my whole home lan is free pass in quick on $int_if from $int_if:network to any #--- Allow networks to see themselves and dns pass quick from $int_if:network to $int_if:network #--- Allow vpns from anywhere to anywhere pass in quick log on $int_if proto gre from any to any keep state pass in quick log on $int_if proto tcp from any to any port pptp flags S/SA keep state On any attempt to connect to the FBSD+pf work VPN Server from home LAN, I get this (even if I uncomment pass quick all): #>mpd5 Multi-link PPP daemon for FreeBSD process 98799 started, version 5.5 (root@Papi 16:55 3-Sep-2011) CONSOLE: listening on 127.0.0.1 5005 web: listening on 127.0.0.1 5006 [B1] Bundle: Interface ng0 created [L1] [L1] Link: OPEN event [L1] LCP: Open event [L1] LCP: state change Initial --> Starting [L1] LCP: LayerStart [L1] PPTP call successful [L1] Link: UP event [L1] LCP: Up event [L1] LCP: state change Starting --> Req-Sent [L1] LCP: SendConfigReq #1 [L1] ACFCOMP [L1] PROTOCOMP [L1] ACCMAP 0x000a0000 [L1] MRU 1486 [L1] MAGICNUM 2d08ae01 [snip..] [L1] LCP: SendConfigReq #10 [L1] ACFCOMP [L1] PROTOCOMP [L1] ACCMAP 0x000a0000 [L1] MRU 1486 [L1] MAGICNUM 2d08ae01 [L1] LCP: parameter negotiation failed [L1] LCP: state change Req-Sent --> Stopped [L1] LCP: LayerFinish [L1] PPTP call terminated [L1] Link: DOWN event [L1] LCP: Close event [L1] LCP: state change Stopped --> Closed [L1] LCP: Down event [L1] LCP: state change Closed --> Initial BUT, on the 9th or 10th attempt, without touching any setting anywhere, the VPN MAY BE established. out of nothing ! Machines (Windows, Unix, whatever) behind both FBSD+pfs ALSO have the same problem when trying to close VPN tunnels to outside sites. Sometimes, opening an ssh session from my workstation to FBSD+pf work may "help" in establishing the VPN. The FBSD+pf work VPN Server is working fine. My colleagues can connect to it from their homes (NATted cable modems or 3G modems) without problems. I am the only one behind a FBSD+pf router. I installed MPD5 on FBSD+pf home, and copied mpd.conf from my home workstation to it. Without touching a single setting on mpd.conf, the VPN is established from FBSD+pf home (as a client) to FBSD+pf work WITHOUT any hiccups on EVERY SINGLE attempt! even I bring it up/down 200 times! And yet, if the FBSD+pf combo is out of the way, (i.e. no NAT!, as is the case of FBSD+pf home as a client) or if I let my cable modem do the NAT/routing, the problem is GONE!. FreeBSD work FreeBSD 8.2-STABLE #0: Mon Aug 22 14:50:42 BRT 2011 amd64 FreeBSD Home FreeBSD FreeBSD 8.2-STABLE #0: Wed May 18 16:53:26 BRT 2011 i386 Any suggestions? Thanks, -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) From owner-freebsd-pf@FreeBSD.ORG Fri Sep 9 21:43:07 2011 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 14913106564A for ; Fri, 9 Sep 2011 21:43:07 +0000 (UTC) (envelope-from torsten@cnc-london.net) Received: from mailhost.cnc-london.net (mailhost.cnc-london.net [109.200.20.58]) by mx1.freebsd.org (Postfix) with ESMTP id 37D6D8FC18 for ; Fri, 9 Sep 2011 21:43:05 +0000 (UTC) Received: (qmail 24506 invoked from network); 9 Sep 2011 22:16:24 +0100 Received: from 78-105-9-127.zone3.bethere.co.uk (HELO torstenWIN7) (torsten@cnc-london.net@78.105.9.127) by mailhost.cnc-london.net with SMTP; 9 Sep 2011 22:16:24 +0100 From: "Torsten Kersandt" To: References: <201109091646.15327.lobo@bsd.com.br> In-Reply-To: <201109091646.15327.lobo@bsd.com.br> Date: Fri, 9 Sep 2011 22:15:29 +0100 Message-ID: <033001cc6f35$9a68efe0$cf3acfa0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxvLOUcU5laRAIJSOmamSsWwlLFtQACGHxQ Content-Language: en-gb Subject: RE: VPN 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, 09 Sep 2011 21:43:07 -0000 HI Mario I don't know what the experts are suggesting and I would like to get educated as well but I use a table for the VPN addresses To allow nat but block them from using the server as gateway ("use as default gateway" in VPN disabled in windows) I add the rules dynamically using mpd if-up and if-down scripts All I have in my rules is GRE pass anywhere and "nat to and from" where ever Regards Torsten -----Original Message----- From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On Behalf Of Mario Lobo Sent: 09 September 2011 20:46 To: freebsd-pf@freebsd.org Cc: freebsd-questions@freebsd.org Subject: VPN problem Hi; I've been having this problem establishing a VPN behind a FreeBSD 8-STABLE with pf. I have this scenario: home LAN ---- FBSD+pf home ---- INTERNET --- FBSD+pf work --- work LAN MPD VPN server nat rules on FBSD+pf home: nat on $ext_if from $int_if:network to any -> ($ext_if) port 1024:65535 # nat on $ext_if from any to any -> ($ext_if) port 1024:65535 obs- it makes no difference which nat rule I use. The problem persists. These are the first 5 pf rules on FBSD+pf home: # pass quick all pass quick on lo0 all # my whole home lan is free pass in quick on $int_if from $int_if:network to any #--- Allow networks to see themselves and dns pass quick from $int_if:network to $int_if:network #--- Allow vpns from anywhere to anywhere pass in quick log on $int_if proto gre from any to any keep state pass in quick log on $int_if proto tcp from any to any port pptp flags S/SA keep state On any attempt to connect to the FBSD+pf work VPN Server from home LAN, I get this (even if I uncomment pass quick all): #>mpd5 Multi-link PPP daemon for FreeBSD process 98799 started, version 5.5 (root@Papi 16:55 3-Sep-2011) CONSOLE: listening on 127.0.0.1 5005 web: listening on 127.0.0.1 5006 [B1] Bundle: Interface ng0 created [L1] [L1] Link: OPEN event [L1] LCP: Open event [L1] LCP: state change Initial --> Starting [L1] LCP: LayerStart [L1] PPTP call successful [L1] Link: UP event [L1] LCP: Up event [L1] LCP: state change Starting --> Req-Sent [L1] LCP: SendConfigReq #1 [L1] ACFCOMP [L1] PROTOCOMP [L1] ACCMAP 0x000a0000 [L1] MRU 1486 [L1] MAGICNUM 2d08ae01 [snip..] [L1] LCP: SendConfigReq #10 [L1] ACFCOMP [L1] PROTOCOMP [L1] ACCMAP 0x000a0000 [L1] MRU 1486 [L1] MAGICNUM 2d08ae01 [L1] LCP: parameter negotiation failed [L1] LCP: state change Req-Sent --> Stopped [L1] LCP: LayerFinish [L1] PPTP call terminated [L1] Link: DOWN event [L1] LCP: Close event [L1] LCP: state change Stopped --> Closed [L1] LCP: Down event [L1] LCP: state change Closed --> Initial BUT, on the 9th or 10th attempt, without touching any setting anywhere, the VPN MAY BE established. out of nothing ! Machines (Windows, Unix, whatever) behind both FBSD+pfs ALSO have the same problem when trying to close VPN tunnels to outside sites. Sometimes, opening an ssh session from my workstation to FBSD+pf work may "help" in establishing the VPN. The FBSD+pf work VPN Server is working fine. My colleagues can connect to it from their homes (NATted cable modems or 3G modems) without problems. I am the only one behind a FBSD+pf router. I installed MPD5 on FBSD+pf home, and copied mpd.conf from my home workstation to it. Without touching a single setting on mpd.conf, the VPN is established from FBSD+pf home (as a client) to FBSD+pf work WITHOUT any hiccups on EVERY SINGLE attempt! even I bring it up/down 200 times! And yet, if the FBSD+pf combo is out of the way, (i.e. no NAT!, as is the case of FBSD+pf home as a client) or if I let my cable modem do the NAT/routing, the problem is GONE!. FreeBSD work FreeBSD 8.2-STABLE #0: Mon Aug 22 14:50:42 BRT 2011 amd64 FreeBSD Home FreeBSD FreeBSD 8.2-STABLE #0: Wed May 18 16:53:26 BRT 2011 i386 Any suggestions? Thanks, -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) _______________________________________________ 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 Sep 9 21:45:26 2011 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79B42106566B; Fri, 9 Sep 2011 21:45:26 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 507388FC27; Fri, 9 Sep 2011 21:45:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p89LjQ4a060498; Fri, 9 Sep 2011 21:45:26 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p89LjQx6060494; Fri, 9 Sep 2011 21:45:26 GMT (envelope-from bz) Date: Fri, 9 Sep 2011 21:45:26 GMT Message-Id: <201109092145.p89LjQx6060494@freefall.freebsd.org> To: bz@FreeBSD.org, freebsd-pf@FreeBSD.org, freebsd-virtualization@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/160541: [vimage][pf][patch] panic: userret: Returning on td 0xxxxxxxxx (pid xxxx, pftop) with vnet 0xxxxxxxxx set in pfioctl 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, 09 Sep 2011 21:45:26 -0000 Synopsis: [vimage][pf][patch] panic: userret: Returning on td 0xxxxxxxxx (pid xxxx, pftop) with vnet 0xxxxxxxxx set in pfioctl Responsible-Changed-From-To: freebsd-pf->freebsd-virtualization Responsible-Changed-By: bz Responsible-Changed-When: Fri Sep 9 21:45:13 UTC 2011 Responsible-Changed-Why: Re-assign to right mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=160541 From owner-freebsd-pf@FreeBSD.ORG Fri Sep 9 21:53:09 2011 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 18B74106564A; Fri, 9 Sep 2011 21:53:09 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9B20B8FC12; Fri, 9 Sep 2011 21:53:08 +0000 (UTC) Received: by yxk36 with SMTP id 36so2381368yxk.13 for ; Fri, 09 Sep 2011 14:53:07 -0700 (PDT) Received: by 10.150.139.6 with SMTP id m6mr1756944ybd.302.1315605187761; Fri, 09 Sep 2011 14:53:07 -0700 (PDT) Received: from papi.localnet ([186.212.242.15]) by mx.google.com with ESMTPS id m4sm6131024ang.4.2011.09.09.14.53.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 14:53:07 -0700 (PDT) From: Mario Lobo To: freebsd-pf@freebsd.org Date: Fri, 9 Sep 2011 18:53:08 -0300 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.2; amd64; ; ) References: <201109091646.15327.lobo@bsd.com.br> <032f01cc6f35$162e1390$428a3ab0$@net> In-Reply-To: <032f01cc6f35$162e1390$428a3ab0$@net> X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201109091853.09133.lobo@bsd.com.br> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-questions@freebsd.org Subject: Re: VPN 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, 09 Sep 2011 21:53:09 -0000 On Friday 09 September 2011 18:11:47 Torsten Kersandt wrote: > HI Mario > I don't know what the experts are suggesting but I use a table for the VPN > addresses > To allow nat but block them frm using the server as gateway ("use as > default gateway" disabled in windows) > I add the rules dynamically using mpd if-up and if-down scripts > > All I have in my rules is GRE pass anywhere and nat
to and from > where ever > > Regards > Torsten > Thanks for replying, Torsten but the problem is way before all these things that you mentioned. I'm wildly guessing here but the problem seems to be inside the NAT mechanism of PF. At least the working/not working situations point to that direction. If I don't find a solution to that soon I am gonna have no choice but to switch to IPFW, which I would not like to do because the queuing mechanisms of pf are extremely useful and handy to my networks. By the way, I also do each item that you mentioned in your post. The funny thing is that there was a time (maybe a couple csups ago) that this problem didn't occur, and I am totally unable to say which csup brought this issue in. Remeber there are 3 FBSDs involved here. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) > > -----Original Message----- > From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On > Behalf Of Mario Lobo > Sent: 09 September 2011 20:46 > To: freebsd-pf@freebsd.org > Cc: freebsd-questions@freebsd.org > Subject: VPN problem > > Hi; > > I've been having this problem establishing a VPN behind a FreeBSD 8-STABLE > with pf. > > I have this scenario: > > > home LAN ---- FBSD+pf home ---- INTERNET --- FBSD+pf work --- work LAN > MPD VPN server > > nat rules on FBSD+pf home: > > > nat on $ext_if from $int_if:network to any -> ($ext_if) port 1024:65535 > # nat on $ext_if from any to any -> ($ext_if) port 1024:65535 > > > obs- it makes no difference which nat rule I use. The problem persists. > > > These are the first 5 pf rules on FBSD+pf home: > > # pass quick all > pass quick on lo0 all > > # my whole home lan is free > pass in quick on $int_if from $int_if:network to any > > #--- Allow networks to see themselves and dns > pass quick from $int_if:network to $int_if:network > > #--- Allow vpns from anywhere to anywhere > pass in quick log on $int_if proto gre from any to any keep state > pass in quick log on $int_if proto tcp from any to any port pptp flags > S/SA > keep state > > > > On any attempt to connect to the FBSD+pf work VPN Server from home LAN, > I get this (even if I uncomment pass quick all): > > #>mpd5 > Multi-link PPP daemon for FreeBSD > > process 98799 started, version 5.5 (root@Papi 16:55 3-Sep-2011) > CONSOLE: listening on 127.0.0.1 5005 > web: listening on 127.0.0.1 5006 > [B1] Bundle: Interface ng0 created > [L1] [L1] Link: OPEN event > [L1] LCP: Open event > [L1] LCP: state change Initial --> Starting > [L1] LCP: LayerStart > [L1] PPTP call successful > [L1] Link: UP event > [L1] LCP: Up event > [L1] LCP: state change Starting --> Req-Sent > [L1] LCP: SendConfigReq #1 > [L1] ACFCOMP > [L1] PROTOCOMP > [L1] ACCMAP 0x000a0000 > [L1] MRU 1486 > [L1] MAGICNUM 2d08ae01 > > [snip..] > > [L1] LCP: SendConfigReq #10 > [L1] ACFCOMP > [L1] PROTOCOMP > [L1] ACCMAP 0x000a0000 > [L1] MRU 1486 > [L1] MAGICNUM 2d08ae01 > [L1] LCP: parameter negotiation failed > [L1] LCP: state change Req-Sent --> Stopped > [L1] LCP: LayerFinish > [L1] PPTP call terminated > [L1] Link: DOWN event > [L1] LCP: Close event > [L1] LCP: state change Stopped --> Closed > [L1] LCP: Down event > [L1] LCP: state change Closed --> Initial > > > BUT, on the 9th or 10th attempt, without touching any setting anywhere, the > VPN MAY BE established. out of nothing ! Machines (Windows, Unix, whatever) > behind both FBSD+pfs ALSO have the same problem when trying to close VPN > tunnels to outside sites. > > Sometimes, opening an ssh session from my workstation to FBSD+pf work may > "help" in establishing the VPN. > > The FBSD+pf work VPN Server is working fine. My colleagues can connect to > it > > from their homes (NATted cable modems or 3G modems) without problems. I am > the > only one behind a FBSD+pf router. > > > I installed MPD5 on FBSD+pf home, and copied mpd.conf from my home > workstation > to it. > > > Without touching a single setting on mpd.conf, the VPN is established > from FBSD+pf home (as a client) to FBSD+pf work WITHOUT any hiccups on > EVERY > > SINGLE attempt! even I bring it up/down 200 times! > > And yet, if the FBSD+pf combo is out of the way, (i.e. no NAT!, as is the > case > of FBSD+pf home as a client) or if I let my cable modem do the NAT/routing, > the problem is GONE!. > > > FreeBSD work > FreeBSD 8.2-STABLE #0: Mon Aug 22 14:50:42 BRT 2011 amd64 > > FreeBSD Home > FreeBSD FreeBSD 8.2-STABLE #0: Wed May 18 16:53:26 BRT 2011 i386 > > Any suggestions? > > Thanks, From owner-freebsd-pf@FreeBSD.ORG Fri Sep 9 22:04:24 2011 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 36EEB106564A for ; Fri, 9 Sep 2011 22:04:24 +0000 (UTC) (envelope-from torsten@cnc-london.net) Received: from mailhost.cnc-london.net (mailhost.cnc-london.net [109.200.20.58]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4808FC1A for ; Fri, 9 Sep 2011 22:04:23 +0000 (UTC) Received: (qmail 26912 invoked from network); 9 Sep 2011 23:04:22 +0100 Received: from 78-105-9-127.zone3.bethere.co.uk (HELO torstenWIN7) (torsten@cnc-london.net@78.105.9.127) by mailhost.cnc-london.net with SMTP; 9 Sep 2011 23:04:22 +0100 From: "Torsten Kersandt" To: "'Mario Lobo'" , References: <201109091646.15327.lobo@bsd.com.br> <032f01cc6f35$162e1390$428a3ab0$@net> <201109091853.09133.lobo@bsd.com.br> In-Reply-To: <201109091853.09133.lobo@bsd.com.br> Date: Fri, 9 Sep 2011 23:03:27 +0100 Message-ID: <033101cc6f3c$4dfc8f20$e9f5ad60$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxvOykWt66uLhtlTF2U6JULpPrtXQAAC8bQ Content-Language: en-gb Cc: freebsd-questions@freebsd.org Subject: RE: VPN 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, 09 Sep 2011 22:04:24 -0000 Hi TUN and NG connections are not present at the time you start your server and rules for such interfaces are not applicable to PF The is there the if up and if down functions of MPD come into place unless you use IP Address/network specific rules. One server I have in the if-up script: /etc/rc.d/pf resync /sbin/pfctl -t if_pptp -T add ${4} And it works perfectly fine including on the secondary MPD instance (bound to IP address) allowing usage as default gateway functions. Other than that I think you will have to go down the bridging line. I may be corrected bu others :-) Regards Torsten -----Original Message----- From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On Behalf Of Mario Lobo Sent: 09 September 2011 22:53 To: freebsd-pf@freebsd.org Cc: freebsd-questions@freebsd.org Subject: Re: VPN problem On Friday 09 September 2011 18:11:47 Torsten Kersandt wrote: > HI Mario > I don't know what the experts are suggesting but I use a table for the VPN > addresses > To allow nat but block them frm using the server as gateway ("use as > default gateway" disabled in windows) > I add the rules dynamically using mpd if-up and if-down scripts > > All I have in my rules is GRE pass anywhere and nat
to and from > where ever > > Regards > Torsten > Thanks for replying, Torsten but the problem is way before all these things that you mentioned. I'm wildly guessing here but the problem seems to be inside the NAT mechanism of PF. At least the working/not working situations point to that direction. If I don't find a solution to that soon I am gonna have no choice but to switch to IPFW, which I would not like to do because the queuing mechanisms of pf are extremely useful and handy to my networks. By the way, I also do each item that you mentioned in your post. The funny thing is that there was a time (maybe a couple csups ago) that this problem didn't occur, and I am totally unable to say which csup brought this issue in. Remeber there are 3 FBSDs involved here. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) > > -----Original Message----- > From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On > Behalf Of Mario Lobo > Sent: 09 September 2011 20:46 > To: freebsd-pf@freebsd.org > Cc: freebsd-questions@freebsd.org > Subject: VPN problem > > Hi; > > I've been having this problem establishing a VPN behind a FreeBSD 8-STABLE > with pf. > > I have this scenario: > > > home LAN ---- FBSD+pf home ---- INTERNET --- FBSD+pf work --- work LAN > MPD VPN server > > nat rules on FBSD+pf home: > > > nat on $ext_if from $int_if:network to any -> ($ext_if) port 1024:65535 > # nat on $ext_if from any to any -> ($ext_if) port 1024:65535 > > > obs- it makes no difference which nat rule I use. The problem persists. > > > These are the first 5 pf rules on FBSD+pf home: > > # pass quick all > pass quick on lo0 all > > # my whole home lan is free > pass in quick on $int_if from $int_if:network to any > > #--- Allow networks to see themselves and dns > pass quick from $int_if:network to $int_if:network > > #--- Allow vpns from anywhere to anywhere > pass in quick log on $int_if proto gre from any to any keep state > pass in quick log on $int_if proto tcp from any to any port pptp flags > S/SA > keep state > > > > On any attempt to connect to the FBSD+pf work VPN Server from home LAN, > I get this (even if I uncomment pass quick all): > > #>mpd5 > Multi-link PPP daemon for FreeBSD > > process 98799 started, version 5.5 (root@Papi 16:55 3-Sep-2011) > CONSOLE: listening on 127.0.0.1 5005 > web: listening on 127.0.0.1 5006 > [B1] Bundle: Interface ng0 created > [L1] [L1] Link: OPEN event > [L1] LCP: Open event > [L1] LCP: state change Initial --> Starting > [L1] LCP: LayerStart > [L1] PPTP call successful > [L1] Link: UP event > [L1] LCP: Up event > [L1] LCP: state change Starting --> Req-Sent > [L1] LCP: SendConfigReq #1 > [L1] ACFCOMP > [L1] PROTOCOMP > [L1] ACCMAP 0x000a0000 > [L1] MRU 1486 > [L1] MAGICNUM 2d08ae01 > > [snip..] > > [L1] LCP: SendConfigReq #10 > [L1] ACFCOMP > [L1] PROTOCOMP > [L1] ACCMAP 0x000a0000 > [L1] MRU 1486 > [L1] MAGICNUM 2d08ae01 > [L1] LCP: parameter negotiation failed > [L1] LCP: state change Req-Sent --> Stopped > [L1] LCP: LayerFinish > [L1] PPTP call terminated > [L1] Link: DOWN event > [L1] LCP: Close event > [L1] LCP: state change Stopped --> Closed > [L1] LCP: Down event > [L1] LCP: state change Closed --> Initial > > > BUT, on the 9th or 10th attempt, without touching any setting anywhere, the > VPN MAY BE established. out of nothing ! Machines (Windows, Unix, whatever) > behind both FBSD+pfs ALSO have the same problem when trying to close VPN > tunnels to outside sites. > > Sometimes, opening an ssh session from my workstation to FBSD+pf work may > "help" in establishing the VPN. > > The FBSD+pf work VPN Server is working fine. My colleagues can connect to > it > > from their homes (NATted cable modems or 3G modems) without problems. I am > the > only one behind a FBSD+pf router. > > > I installed MPD5 on FBSD+pf home, and copied mpd.conf from my home > workstation > to it. > > > Without touching a single setting on mpd.conf, the VPN is established > from FBSD+pf home (as a client) to FBSD+pf work WITHOUT any hiccups on > EVERY > > SINGLE attempt! even I bring it up/down 200 times! > > And yet, if the FBSD+pf combo is out of the way, (i.e. no NAT!, as is the > case > of FBSD+pf home as a client) or if I let my cable modem do the NAT/routing, > the problem is GONE!. > > > FreeBSD work > FreeBSD 8.2-STABLE #0: Mon Aug 22 14:50:42 BRT 2011 amd64 > > FreeBSD Home > FreeBSD FreeBSD 8.2-STABLE #0: Wed May 18 16:53:26 BRT 2011 i386 > > Any suggestions? > > Thanks, _______________________________________________ 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 Sep 9 22:21:16 2011 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 E9DD0106566C; Fri, 9 Sep 2011 22:21:16 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6BFE68FC08; Fri, 9 Sep 2011 22:21:16 +0000 (UTC) Received: by yxk36 with SMTP id 36so2400267yxk.13 for ; Fri, 09 Sep 2011 15:21:15 -0700 (PDT) Received: by 10.150.254.16 with SMTP id b16mr2467157ybi.94.1315606875511; Fri, 09 Sep 2011 15:21:15 -0700 (PDT) Received: from papi.localnet ([186.212.242.15]) by mx.google.com with ESMTPS id u13sm6177496anf.14.2011.09.09.15.21.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 15:21:14 -0700 (PDT) From: Mario Lobo To: "Torsten Kersandt" Date: Fri, 9 Sep 2011 19:21:16 -0300 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.2; amd64; ; ) References: <201109091646.15327.lobo@bsd.com.br> <201109091853.09133.lobo@bsd.com.br> <033101cc6f3c$4dfc8f20$e9f5ad60$@net> In-Reply-To: <033101cc6f3c$4dfc8f20$e9f5ad60$@net> X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201109091921.16542.lobo@bsd.com.br> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-questions@freebsd.org, freebsd-pf@freebsd.org Subject: Re: VPN 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, 09 Sep 2011 22:21:17 -0000 On Friday 09 September 2011 19:03:27 Torsten Kersandt wrote: > Hi > TUN and NG connections are not present at the time you start your server > and rules for such interfaces are not applicable to PF You're right, but on the client end that is trying to conect to that server behind a pf firewall, nat rules DO apply, and on my tests I can see for sure that when I take NAT out of the picture, the VPN tunnel is established. > > The is there the if up and if down functions of MPD come into place unless > you use IP Address/network specific rules. > One server I have in the if-up script: > > /etc/rc.d/pf resync > /sbin/pfctl -t if_pptp -T add ${4} I do all that! in fact even go beyond and use the linkup/down scripts to create a log on the server of which user(s) is(are) conected to the VPN, from which public IP, with which ng interface, at what time/date they logged in and and logged out. > > And it works perfectly fine including on the secondary MPD instance (bound > to IP address) allowing usage as default gateway functions. > Like I said before: "The FBSD+pf work VPN Server is working fine. My colleagues can connect to it from their homes (NATted cable modems or 3G modems) without problems." > Other than that I think you will have to go down the bridging line. > I may be corrected bu others :-) > > Regards > Torsten > Thanks again, Torsten. I think this issue seems to lie deeper that just pf rules and link scripts -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) > > -----Original Message----- > From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On > Behalf Of Mario Lobo > Sent: 09 September 2011 22:53 > To: freebsd-pf@freebsd.org > Cc: freebsd-questions@freebsd.org > Subject: Re: VPN problem > > On Friday 09 September 2011 18:11:47 Torsten Kersandt wrote: > > HI Mario > > I don't know what the experts are suggesting but I use a table for the > > VPN addresses > > To allow nat but block them frm using the server as gateway ("use as > > default gateway" disabled in windows) > > I add the rules dynamically using mpd if-up and if-down scripts > > > > All I have in my rules is GRE pass anywhere and nat
to and from > > where ever > > > > Regards > > Torsten > > Thanks for replying, Torsten but the problem is way before all these things > that you mentioned. I'm wildly guessing here but the problem seems to be > inside the NAT mechanism of PF. At least the working/not working situations > point to that direction. > > If I don't find a solution to that soon I am gonna have no choice but to > switch to IPFW, which I would not like to do because the queuing mechanisms > of > pf are extremely useful and handy to my networks. > > By the way, I also do each item that you mentioned in your post. > > The funny thing is that there was a time (maybe a couple csups ago) that > this > problem didn't occur, and I am totally unable to say which csup brought > this > > issue in. Remeber there are 3 FBSDs involved here. > > > -----Original Message----- > > From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] > > On > > > Behalf Of Mario Lobo > > Sent: 09 September 2011 20:46 > > To: freebsd-pf@freebsd.org > > Cc: freebsd-questions@freebsd.org > > Subject: VPN problem > > > > Hi; > > > > I've been having this problem establishing a VPN behind a FreeBSD > > 8-STABLE with pf. > > > > I have this scenario: > > > > > > home LAN ---- FBSD+pf home ---- INTERNET --- FBSD+pf work --- work LAN > > > > MPD VPN server > > > > nat rules on FBSD+pf home: > > nat on $ext_if from $int_if:network to any -> ($ext_if) port 1024:65535 > > # nat on $ext_if from any to any -> ($ext_if) port 1024:65535 > > > > obs- it makes no difference which nat rule I use. The problem persists. > > > > These are the first 5 pf rules on FBSD+pf home: > > # pass quick all > > pass quick on lo0 all > > > > # my whole home lan is free > > pass in quick on $int_if from $int_if:network to any > > > > #--- Allow networks to see themselves and dns > > pass quick from $int_if:network to $int_if:network > > > > #--- Allow vpns from anywhere to anywhere > > pass in quick log on $int_if proto gre from any to any keep state > > pass in quick log on $int_if proto tcp from any to any port pptp flags > > > > S/SA > > keep state > > > > > > > > On any attempt to connect to the FBSD+pf work VPN Server from home LAN, > > I get this (even if I uncomment pass quick all): > > > > #>mpd5 > > Multi-link PPP daemon for FreeBSD > > > > process 98799 started, version 5.5 (root@Papi 16:55 3-Sep-2011) > > CONSOLE: listening on 127.0.0.1 5005 > > web: listening on 127.0.0.1 5006 > > [B1] Bundle: Interface ng0 created > > [L1] [L1] Link: OPEN event > > [L1] LCP: Open event > > [L1] LCP: state change Initial --> Starting > > [L1] LCP: LayerStart > > [L1] PPTP call successful > > [L1] Link: UP event > > [L1] LCP: Up event > > [L1] LCP: state change Starting --> Req-Sent > > [L1] LCP: SendConfigReq #1 > > [L1] ACFCOMP > > [L1] PROTOCOMP > > [L1] ACCMAP 0x000a0000 > > [L1] MRU 1486 > > [L1] MAGICNUM 2d08ae01 > > > > [snip..] > > > > [L1] LCP: SendConfigReq #10 > > [L1] ACFCOMP > > [L1] PROTOCOMP > > [L1] ACCMAP 0x000a0000 > > [L1] MRU 1486 > > [L1] MAGICNUM 2d08ae01 > > [L1] LCP: parameter negotiation failed > > [L1] LCP: state change Req-Sent --> Stopped > > [L1] LCP: LayerFinish > > [L1] PPTP call terminated > > [L1] Link: DOWN event > > [L1] LCP: Close event > > [L1] LCP: state change Stopped --> Closed > > [L1] LCP: Down event > > [L1] LCP: state change Closed --> Initial > > > > > > BUT, on the 9th or 10th attempt, without touching any setting anywhere, > > the > > > VPN MAY BE established. out of nothing ! Machines (Windows, Unix, > > whatever) > > > behind both FBSD+pfs ALSO have the same problem when trying to close VPN > > tunnels to outside sites. > > > > Sometimes, opening an ssh session from my workstation to FBSD+pf work may > > "help" in establishing the VPN. > > > > The FBSD+pf work VPN Server is working fine. My colleagues can connect to > > it > > > > from their homes (NATted cable modems or 3G modems) without problems. I > > am the > > only one behind a FBSD+pf router. > > > > > > I installed MPD5 on FBSD+pf home, and copied mpd.conf from my home > > workstation > > to it. > > > > > > Without touching a single setting on mpd.conf, the VPN is established > > from FBSD+pf home (as a client) to FBSD+pf work WITHOUT any hiccups on > > EVERY > > > > SINGLE attempt! even I bring it up/down 200 times! > > > > And yet, if the FBSD+pf combo is out of the way, (i.e. no NAT!, as is the > > case > > of FBSD+pf home as a client) or if I let my cable modem do the > > NAT/routing, > > > the problem is GONE!. > > > > > > FreeBSD work > > FreeBSD 8.2-STABLE #0: Mon Aug 22 14:50:42 BRT 2011 amd64 > > > > FreeBSD Home > > FreeBSD FreeBSD 8.2-STABLE #0: Wed May 18 16:53:26 BRT 2011 i386 > > > > Any suggestions? > > > > Thanks, > > _______________________________________________ > 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 Sat Sep 10 05:45:48 2011 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 2E37E106564A for ; Sat, 10 Sep 2011 05:45:48 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id B2F338FC0C for ; Sat, 10 Sep 2011 05:45:46 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id p8A5jdvG032650 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sat, 10 Sep 2011 07:45:39 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id p8A5jcEq004209; Sat, 10 Sep 2011 07:45:38 +0200 (MEST) Date: Sat, 10 Sep 2011 07:45:38 +0200 From: Daniel Hartmeier To: Mario Lobo Message-ID: <20110910054538.GA29437@insomnia.benzedrine.cx> References: <201109091646.15327.lobo@bsd.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201109091646.15327.lobo@bsd.com.br> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-pf@freebsd.org Subject: Re: VPN 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: Sat, 10 Sep 2011 05:45:48 -0000 On Fri, Sep 09, 2011 at 04:46:15PM -0300, Mario Lobo wrote: > Any suggestions? Unlike most commercial NAT devices, pf is not aware of payload in PPTP packets, which means it only supports a single PPTP connection between your single external home addresses and the constant public work address (i.e. demultiplexing incoming PPTP packets to the right local client is based solely on IP adresses, and not any information inside the PPTP payload, like a session ID or such). Run pfctl -ss on the home NAT box and check that there is no unexpected prior PPTP (GRE) state when you try to open yours. If this is the problem, you can try a PPTP proxy. Or, yes, try ipfw, but I think it's not PPTP payload-aware, either. More details in an old thread http://lists.freebsd.org/pipermail/freebsd-pf/2006-November/002834.html If this is not the problem, you'll have to provide more details, like tcpdump on the pf NAT box (on both external and internal interfaces) while trying to establish a connection, run pfctl -vvss, pfctl -si before and after, use 'set debug misc' and watch /var/log/messages, etc. Daniel From owner-freebsd-pf@FreeBSD.ORG Sat Sep 10 13:18:24 2011 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 6714F106564A for ; Sat, 10 Sep 2011 13:18:24 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 286BE8FC0A for ; Sat, 10 Sep 2011 13:18:23 +0000 (UTC) Received: by yib19 with SMTP id 19so1844342yib.13 for ; Sat, 10 Sep 2011 06:18:23 -0700 (PDT) Received: by 10.236.9.106 with SMTP id 70mr5042059yhs.105.1315660703365; Sat, 10 Sep 2011 06:18:23 -0700 (PDT) Received: from papi.localnet ([177.17.68.103]) by mx.google.com with ESMTPS id o48sm9425662yhl.4.2011.09.10.06.18.20 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Sep 2011 06:18:22 -0700 (PDT) From: Mario Lobo To: Daniel Hartmeier Date: Sat, 10 Sep 2011 10:18:25 -0300 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.2; amd64; ; ) References: <201109091646.15327.lobo@bsd.com.br> <20110910054538.GA29437@insomnia.benzedrine.cx> In-Reply-To: <20110910054538.GA29437@insomnia.benzedrine.cx> X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201109101018.25383.lobo@bsd.com.br> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org Subject: Re: VPN 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: Sat, 10 Sep 2011 13:18:24 -0000 On Saturday 10 September 2011 02:45:38 Daniel Hartmeier wrote: > On Fri, Sep 09, 2011 at 04:46:15PM -0300, Mario Lobo wrote: > > Any suggestions? > > Unlike most commercial NAT devices, pf is not aware of payload in PPTP > packets, which means it only supports a single PPTP connection between > your single external home addresses and the constant public work address > (i.e. demultiplexing incoming PPTP packets to the right local client is > based solely on IP adresses, and not any information inside the PPTP > payload, like a session ID or such). > I don't know if I understood this right but I know for shure that I can have multiple users coneccted to the work FBSD MPD server. Are you talking about multilink PPTP connections here? > Run pfctl -ss on the home NAT box and check that there is no unexpected > prior PPTP (GRE) state when you try to open yours. > Ahhh! a thread of light here. On my previous layout, home WS <---> FBSD home GW <---> Internet <---> FBSD work GW <---> work WS MPD Server The "funny" thing is that either if I'm trying to establish a VPN tunnel from a home WS or a work WS to any external site, I have to make several attempts before achieving success. Even with the tunnel established, with Windows workstations for instance, the VPN connection is very unstable and keeps dropping. Sometimes, opening an ssh session from my home WS to FBSD work GW may "help" in establishing the VPN. Like I said, the FBSD work GW MPD Server works flawlessly. My colleagues can connect to it from their homes (NATted cable modems or 3G modems) without problems. And coneecting from FBSD home GW as client --> FBSD work GW works without glitches EVERYTIME. The same holds true for FBSD work GW as a client. The problems happens ONLY to machines behind the FBSD xxx GW. That's why I made NAT a suspect. > If this is the problem, you can try a PPTP proxy. Or, yes, try ipfw, > but I think it's not PPTP payload-aware, either. > Like I said, I don't want to go to ipfw. I love the way things are done with pf!. Never heard of a PPTP proxy. Could you name one for me that works on FBSD? > More details in an old thread > http://lists.freebsd.org/pipermail/freebsd-pf/2006-November/002834.html > > If this is not the problem, you'll have to provide more details, like > tcpdump on the pf NAT box (on both external and internal interfaces) > while trying to establish a connection, run pfctl -vvss, pfctl -si > before and after, use 'set debug misc' and watch /var/log/messages, etc. > > Daniel Thanks Daniel! I'll follow your steps to the letter as soon as I can and let you know the results. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) From owner-freebsd-pf@FreeBSD.ORG Sat Sep 10 13:42:53 2011 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 EB13E1065670 for ; Sat, 10 Sep 2011 13:42:53 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id B0F908FC0C for ; Sat, 10 Sep 2011 13:42:53 +0000 (UTC) Received: by yxk36 with SMTP id 36so2749103yxk.13 for ; Sat, 10 Sep 2011 06:42:53 -0700 (PDT) Received: by 10.236.181.135 with SMTP id l7mr17730296yhm.85.1315662171442; Sat, 10 Sep 2011 06:42:51 -0700 (PDT) Received: from papi.localnet ([177.17.68.103]) by mx.google.com with ESMTPS id x65sm9185100yhh.26.2011.09.10.06.42.48 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Sep 2011 06:42:50 -0700 (PDT) To: Daniel Hartmeier From: Mario Lobo Date: Sat, 10 Sep 2011 10:42:53 -0300 X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201109101042.53575.lobo@bsd.com.br> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org Subject: Re: VPN 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: Sat, 10 Sep 2011 13:42:54 -0000 On Saturday 10 September 2011 02:45:38 Daniel Hartmeier wrote: > On Fri, Sep 09, 2011 at 04:46:15PM -0300, Mario Lobo wrote: > More details in an old thread > http://lists.freebsd.org/pipermail/freebsd-pf/2006-November/002834.html > > If this is not the problem, you'll have to provide more details, like > tcpdump on the pf NAT box (on both external and internal interfaces) > while trying to establish a connection, run pfctl -vvss, pfctl -si > before and after, use 'set debug misc' and watch /var/log/messages, etc. > Daniel; I put set debug misc on pf.conf. As soon as I made my first attempt to connect, I got this: Sep 10 10:27:16 lobos kernel: pf_map_addr: selected address 177.17.68.103 Sep 10 10:27:49 lobos last message repeated 83 times Sep 10 10:28:59 lobos last message repeated 283 times Sep 10 10:28:59 lobos kernel: pf: NAT proxy port allocation (1024-65535) failed Sep 10 10:29:00 lobos kernel: pf_map_addr: selected address 177.17.68.103 Sep 10 10:29:15 lobos last message repeated 22 times Sep 10 10:29:15 lobos kernel: pf: loose state match: TCP 174.122.209.54:110 174.122.209.54:110 10.10.10.2:20941 [lo=2747216958 high=2747223832 win=4105 modulator=0 wscale=4] [lo=2628859950 high=2628925592 win=54 mod Sep 10 10:29:15 lobos kernel: pf: loose state match: TCP 10.10.10.2:20941 177.17.68.103:27334 174.122.209.54:110 [lo=2747216958 high=2747223832 win=4105 modulator=0 wscale=4] [lo=2628859950 high=2628925592 win=54 mo Sep 10 10:29:15 lobos kernel: pf: loose state match: TCP 10.10.10.2:20941 177.17.68.103:27334 174.122.209.54:110 [lo=2747216958 high=2747223832 win=4105 modulator=0 wscale=4] [lo=2628859950 high=2628925592 win=54 mo Sep 10 10:29:16 lobos kernel: pf_map_addr: selected address 177.17.68.103 Sep 10 10:29:47 lobos last message repeated 71 times Sep 10 10:30:02 lobos last message repeated 114 times I had nat on $ext_if from any to any -> ($ext_if) port 1024:65535 replaced with nat on $ext_if from any to any -> ($ext_if) tried to connect again and and got: Sep 10 10:30:02 lobos kernel: pf: NAT proxy port allocation (50001-65535) failed Sep 10 10:30:02 lobos kernel: pf_map_addr: selected address 177.17.68.103 Sep 10 10:30:33 lobos last message repeated 373 times Sep 10 10:31:36 lobos last message repeated 559 times Sep 10 10:31:36 lobos kernel: pf: loose state match: TCP 10.10.10.2:13369 177.17.68.103:51153 189.17.94.162:1723 [lo=3293828711 high=3293894229 win=65535 modulator=0] [lo=4058414752 high=4058480270 win=65535 modulat Sep 10 10:31:36 lobos kernel: pf: loose state match: TCP 189.17.94.162:1723 189.17.94.162:1723 10.10.10.2:13369 [lo=3293828711 high=3293894229 win=65535 modulator=0] [lo=4058414752 high=4058480270 win=65535 modulato Sep 10 10:31:36 lobos kernel: pf: loose state match: TCP 189.17.94.162:1723 189.17.94.162:1723 10.10.10.2:13369 [lo=3293828711 high=3293894229 win=65535 modulator=0] [lo=4058414752 high=4058480270 win=65535 modulato Sep 10 10:31:37 lobos kernel: pf_map_addr: selected address 177.17.68.103 Sep 10 10:32:08 lobos last message repeated 227 times Both attempts failed. Can you make something out of this? -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) From owner-freebsd-pf@FreeBSD.ORG Sat Sep 10 16:08:21 2011 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 77A83106566B for ; Sat, 10 Sep 2011 16:08:21 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id F006E8FC13 for ; Sat, 10 Sep 2011 16:08:19 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id p8AG8Bso019271 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sat, 10 Sep 2011 18:08:11 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id p8AG8Ajl031984; Sat, 10 Sep 2011 18:08:10 +0200 (MEST) Date: Sat, 10 Sep 2011 18:08:10 +0200 From: Daniel Hartmeier To: Mario Lobo Message-ID: <20110910160810.GB29437@insomnia.benzedrine.cx> References: <201109101042.53575.lobo@bsd.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201109101042.53575.lobo@bsd.com.br> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-pf@freebsd.org Subject: Re: VPN 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: Sat, 10 Sep 2011 16:08:21 -0000 On Sat, Sep 10, 2011 at 10:42:53AM -0300, Mario Lobo wrote: > Sep 10 10:27:16 lobos kernel: pf_map_addr: selected address 177.17.68.103 > Sep 10 10:27:49 lobos last message repeated 83 times > Sep 10 10:28:59 lobos last message repeated 283 times This looks as if you're not allowing the packet out after NAT, so each subsequent packet also causes a pf_map_addr() call, instead of creating a state entry. Make sure you have a rule like pass out on $ext_if from ($ext_if) ... Do you see any state entry related to your VPN connection? Run pfctl -vvss after the connection attempt. It helps debugging if you add block log as the very first rule, then make sure all other block rules (if any) also have 'log'. Then reproduce the problem while running tcpdump -s 1600 -nvvveeetttpi pflog0 Now you'll see any packet being dropped by pf. Do you see any? Daniel From owner-freebsd-pf@FreeBSD.ORG Sat Sep 10 22:17:30 2011 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 B19DA106566B for ; Sat, 10 Sep 2011 22:17:30 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-gw0-f49.google.com (mail-gw0-f49.google.com [74.125.83.49]) by mx1.freebsd.org (Postfix) with ESMTP id 414088FC0A for ; Sat, 10 Sep 2011 22:17:29 +0000 (UTC) Received: by gwb1 with SMTP id 1so2986854gwb.36 for ; Sat, 10 Sep 2011 15:17:29 -0700 (PDT) Received: by 10.101.190.6 with SMTP id s6mr2955571anp.50.1315693049310; Sat, 10 Sep 2011 15:17:29 -0700 (PDT) Received: from papi.localnet ([177.17.68.103]) by mx.google.com with ESMTPS id z6sm1939906anf.22.2011.09.10.15.17.25 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Sep 2011 15:17:28 -0700 (PDT) From: Mario Lobo To: Daniel Hartmeier Date: Sat, 10 Sep 2011 19:17:30 -0300 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.2; amd64; ; ) References: <201109101042.53575.lobo@bsd.com.br> <20110910160810.GB29437@insomnia.benzedrine.cx> In-Reply-To: <20110910160810.GB29437@insomnia.benzedrine.cx> X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201109101917.30117.lobo@bsd.com.br> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org Subject: Re: VPN 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: Sat, 10 Sep 2011 22:17:30 -0000 On Saturday 10 September 2011 13:08:10 Daniel Hartmeier wrote: > On Sat, Sep 10, 2011 at 10:42:53AM -0300, Mario Lobo wrote: > > Sep 10 10:27:16 lobos kernel: pf_map_addr: selected address 177.17.68.103 > > Sep 10 10:27:49 lobos last message repeated 83 times > > Sep 10 10:28:59 lobos last message repeated 283 times > > This looks as if you're not allowing the packet out after NAT, so > each subsequent packet also causes a pf_map_addr() call, instead > of creating a state entry. > > Make sure you have a rule like > > pass out on $ext_if from ($ext_if) ... > > Do you see any state entry related to your VPN connection? > Run pfctl -vvss after the connection attempt. > > It helps debugging if you add > > block log > > as the very first rule, then make sure all other block rules (if any) > also have 'log'. Then reproduce the problem while running > > tcpdump -s 1600 -nvvveeetttpi pflog0 > > Now you'll see any packet being dropped by pf. Do you see any? > Daniel; Thanks for doing this, man! I just got home. On my first VPN connection attempt, connected and got this: [~]>tcpdump -s 1600 -nvvveeetttpi pflog0 host 10.10.10.2 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 1600 bytes 00:00:00.000000 rule 2/0(match): pass in on rl0: (tos 0x0, ttl 64, id 60903, offset 0, flags [none], proto TCP (6), length 60) 10.10.10.2.65319 > 189.17.94.162.1723: Flags [S], cksum 0xf79e (correct), seq 3937019625, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val 32966455 ecr 0], length 0 00:00:00.496970 rule 1/0(match): pass in on rl0: (tos 0x0, ttl 64, id 3446, offset 0, flags [none], proto GRE (47), length 60) 10.10.10.2 > 189.17.94.162: GREv1, Flags [key present, sequence# present], call 64372, seq 0, proto PPP (0x880b), length 40 LCP (0xc021), length 28: LCP, Conf-Request (0x01), id 1, length 26 encoded length 24 (=Option(s) length 20) 0x0000: c021 0101 0018 ACFC Option (0x08), length 2: PFC Option (0x07), length 2: ACCM Option (0x02), length 6: 0x000a0000 0x0000: 000a 0000 MRU Option (0x01), length 4: 1486 0x0000: 05ce Magic-Num Option (0x05), length 6: 0x20bd152c 0x0000: 20bd 152c 00:01:15.359756 rule 2/0(match): pass in on rl0: (tos 0x0, ttl 64, id 35400, offset 0, flags [none], proto TCP (6), length 60) 10.10.10.2.15327 > 189.17.94.162.1723: Flags [S], cksum 0xc92c (correct), seq 2129681427, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val 33042305 ecr 0], length 0 I dropped the connection, waited a bit and tried again. This time (and the next 5 times), unsuccessful [~]>tcpdump -s 1600 -nvvveeetttpi pflog0 host 10.10.10.2 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 1600 bytes 00:00:00.000000 rule 2/0(match): pass in on rl0: (tos 0x0, ttl 64, id 2673, offset 0, flags [none], proto TCP (6), length 60) 10.10.10.2.53563 > 189.17.94.162.1723: Flags [S], cksum 0x96e6 (correct), seq 180477348, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val 33472258 ecr 0], length 0 00:00:00.528029 rule 1/0(match): pass in on rl0: (tos 0x0, ttl 64, id 22121, offset 0, flags [none], proto GRE (47), length 60) 10.10.10.2 > 189.17.94.162: GREv1, Flags [key present, sequence# present], call 64372, seq 0, proto PPP (0x880b), length 40 LCP (0xc021), length 28: LCP, Conf-Request (0x01), id 1, length 26 encoded length 24 (=Option(s) length 20) 0x0000: c021 0101 0018 ACFC Option (0x08), length 2: PFC Option (0x07), length 2: ACCM Option (0x02), length 6: 0x000a0000 0x0000: 000a 0000 MRU Option (0x01), length 4: 1486 0x0000: 05ce Magic-Num Option (0x05), length 6: 0xc80d1b74 0x0000: c80d 1b74 00:00:00.000058 rule 30/0(match): pass out on tun0: (tos 0x0, ttl 63, id 22121, offset 0, flags [none], proto GRE (47), length 60) 10.10.10.2 > 189.17.94.162: GREv1, Flags [key present, sequence# present], call 64372, seq 0, proto PPP (0x880b), length 40 LCP (0xc021), length 28: LCP, Conf-Request (0x01), id 1, length 26 encoded length 24 (=Option(s) length 20) 0x0000: c021 0101 0018 ACFC Option (0x08), length 2: PFC Option (0x07), length 2: ACCM Option (0x02), length 6: 0x000a0000 0x0000: 000a 0000 MRU Option (0x01), length 4: 1486 0x0000: 05ce Magic-Num Option (0x05), length 6: 0xc80d1b74 0x0000: c80d 1b74 No block shows up. [~]>pfctl -vvss | grep -A 2 "10.10.10.2:" rl0 tcp 189.17.94.162:1723 <- 10.10.10.2:19285 ESTABLISHED:ESTABLISHED [2640059824 + 65535] [2169377171 + 65535] age 00:00:24, expires in 00:59:57, 6:5 pkts, 584:540 bytes, rule 2 -- tun0 tcp 10.10.10.2:19285 -> 177.17.68.103:16885 -> 189.17.94.162:1723 ESTABLISHED:ESTABLISHED [2169377171 + 65535] [2640059824 + 65535] age 00:00:24, expires in 00:59:57, 6:5 pkts, 584:540 bytes, rule 31 -- Bellow is my full pf.conf. Even if I uncomment the very first filtering rule: # pass quick all the problem persists. #>cat /etc/pf.conf # Required order: options, normalization, queueing, translation, filtering. # Note that translation rules are first match while filter rules are last match. ################[ Macros ]#################################### ### Interfaces ### ext_if="tun0" int_if="rl0" mid_if="re0" internal_net="10.10.10.0/24" ### Hosts ### # Users papi = "10.10.10.2" dani = "10.10.10.3" pinco = "10.10.10.4" mami = "10.10.10.5" # Groups table file "/usr/local/etc/hackers" # Non-public/weird addresses, doesn't include our subnets, anything in here shouldn't be going anywhere table { 0.0.0.0/8, 169.254.0.0/16, 224.0.0.0/3, 204.152.64.0/23 } ################[ Options ]################################### # We want to sent ICMP RST or unreachable set block-policy drop # Bind states to interfaces so we can have a queue for each interface set state-policy if-bound set ruleset-optimization basic set loginterface $ext_if set fingerprints "/etc/pf.os" set skip on { lo0, $mid_if } # set debug misc # set require-order yes # set skip on tun # set optimization normal # set optimization aggressive set timeout { frag 10, tcp.established 3600 } # set timeout { tcp.first 30, tcp.closing 10, tcp.closed 10, tcp.finwait 10 } # set timeout { udp.first 30, udp.single 30, udp.multiple 30 } # set timeout { other.first 30, other.single 30, other.multiple 30 } # set timeout { adaptive.start 5000, adaptive.end 10000 } ################[ Normalization ]############################# # scrub in on $ext_if all random-id # scrub in on $int_if all random-id scrub in all fragment reassemble no-df random-id ################[ Queueing ]################################## altq on $ext_if cbq bandwidth 970Kb queue {ack, dns, ssh, web, mail, bulk, ftp} queue ack bandwidth 10% priority 7 cbq(borrow) queue dns bandwidth 20% priority 6 cbq(borrow) queue ssh bandwidth 10% cbq(borrow) {ssh_login, ssh_bulk} queue ssh_login bandwidth 50% priority 5 queue ssh_bulk bandwidth 50% priority 4 queue mail bandwidth 20% priority 3 cbq(borrow) queue web bandwidth 10% priority 2 cbq(borrow) queue bulk bandwidth 20% priority 1 cbq(borrow default red ecn) queue ftp bandwidth 9% priority 0 cbq(borrow red ecn) ################[ Translation ]############################### ### NAT # nat on $ext_if from $int_if:network to any -> ($ext_if) port 1024:65535 nat on $ext_if from any to any -> ($ext_if) port 1024:65535 nat-anchor "ftp-proxy/*" ### RDR no rdr on lo0 from any to any # frickin ---> Yeah I tried that. It didn't fix the problem. # rdr on $int_if proto tcp from any to any port 1723 -> 127.0.0.1 port 1723 # rdr on $int_if proto gre from any to any -> 127.0.0.1 # ftp proxy rdr-anchor "ftp-proxy/*" rdr pass on $int_if proto tcp from any to any port ftp -> lo0 port 8021 # ssh rdr on $ext_if proto tcp from any to any port 5952 -> $papi port 5952 # emule rdr on $ext_if proto tcp from any to any port 4662 -> $papi port 4662 rdr on $ext_if proto tcp from any to any port 4665 -> $papi port 4665 rdr on $ext_if proto udp from any to any port 4672 -> $papi port 4672 rdr on $ext_if proto tcp from any to any port 4762 -> $dani port 4762 rdr on $ext_if proto udp from any to any port 4772 -> $dani port 4772 rdr on $ext_if proto tcp from any to any port 4862 -> $pinco port 4862 rdr on $ext_if proto udp from any to any port 4872 -> $pinco port 4872 # Azureus, ktorrent rdr on $ext_if proto { tcp, udp } from any to any port 2234 -> $papi port 2234 rdr on $ext_if proto { tcp, udp } from any to any port 6881 -> $papi port 6881 # DENY rouge redirections no rdr ################[ Filtering ]################################# # pass quick all pass quick on lo0 all #--- Allow vpns from anywhere to anywhere pass quick log on $int_if proto gre all keep state pass quick log on $int_if proto tcp from any to any port pptp flags S/SA keep state #--- IPs livres de tudo pass quick on $int_if from $int_if:network to any #--- Allow networks to see themselves and dns pass quick from $int_if:network to $int_if:network ############ To Me ############ # icmp pass in log quick on $ext_if inet proto icmp from any to ($ext_if) icmp-type { echorep, echoreq, timex, unreach } keep state # vpn pass in quick log on $ext_if proto gre all synproxy state pass in quick log on $ext_if proto tcp from any to any port pptp synproxy state anchor vpns # Anchor for ftp-proxy anchor "ftp-proxy/*" # Incoming to computers pass in log quick on $ext_if inet proto tcp from any to $papi port 5952 flags S/SA keep state pass in log quick on $ext_if inet proto {tcp,udp} from any to $papi port 2234 flags S/SA keep state pass in log quick on $ext_if inet proto {tcp,udp} from any to $papi port 6881 keep state pass in log quick on $ext_if inet proto tcp from any to $papi port 4662 flags S/SA keep state pass in log quick on $ext_if inet proto tcp from any to $papi port 4665 flags S/SA keep state pass in log quick on $ext_if inet proto udp from any to $papi port 4672 keep state pass in log quick on $ext_if inet proto tcp from any to $dani port 4762 flags S/SA keep state pass in log quick on $ext_if inet proto udp from any to $dani port 4772 keep state pass in log quick on $ext_if inet proto tcp from any to $pinco port 4862 flags S/SA keep state pass in log quick on $ext_if inet proto udp from any to $pinco port 4872 keep state # Global outgoing prioritized pass out log quick on $ext_if inet proto icmp from any to any keep state queue (dns) pass out log quick on $ext_if inet proto gre from any to any keep state queue (dns, ack) pass out log quick on $ext_if inet proto tcp from any to any port pptp flags S/SA keep state queue (dns, ack) pass out log quick on $ext_if inet proto tcp from any to any port http flags S/SA keep state queue (web, ack) pass out log quick on $ext_if inet proto tcp from any to any port https flags S/SA keep state queue (web, ack) pass out log quick on $ext_if inet proto tcp from any to any port ssh flags S/SA keep state queue (ssh_bulk, ssh_login) pass out log quick on $ext_if inet proto tcp from any to any port 2200 flags S/SA keep state queue (ssh_bulk, ssh_login) pass out log quick on $ext_if inet proto tcp from any to any port 5952 flags S/SA keep state queue (ssh_bulk, ssh_login) pass out log quick on $ext_if inet proto tcp from any to any port pop3 flags S/SA keep state queue (mail, ack) pass out log quick on $ext_if inet proto tcp from any to any port smtp flags S/SA keep state queue (mail, ack) pass out log quick on $ext_if inet proto udp from any to any port domain keep state queue dns # pass out log quick on $ext_if inet proto udp from any to any port 27960 keep state # Global outgoing non-prioritized (default) # pass out log quick on $ext_if inet proto tcp from any to any port 1863 flags S/SA keep state pass out log quick on $ext_if inet proto tcp from any to any flags S/SA keep state pass out log quick on $ext_if inet proto udp from any to any keep state # Block everything else block log all -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE)