From owner-freebsd-questions@FreeBSD.ORG Tue Nov 13 14:35:16 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1315F16A418 for ; Tue, 13 Nov 2007 14:35:16 +0000 (UTC) (envelope-from costin.alupului@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id DEAAA13C49D for ; Tue, 13 Nov 2007 14:35:15 +0000 (UTC) (envelope-from costin.alupului@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2069269waf for ; Tue, 13 Nov 2007 06:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+D0jEbOMAMuNa0uVUJrzNi3k3GXzFLtBluKs2G74uYA=; b=UzBjcUW4IR7dAkL+aWTDzgg5ww2/N9Fqr9zNh6AHAofLxUYjL86kHRoXTt+SNiQz+Tk3AU00KlmiWADX/2BXkeiAfid9i9ZuhyovwrI9jMduQ62/LODiLsMQCPp4p581IUyTtMCEWAtQtZ2huTCb4U07zkhxXkbDHNq1latZEbw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WN/+tM5qPz2rSGxH1ofeYOoUIheSL/DKPElqBuoPV0CJ1aOj1z8kUlAXAeR6iKkpuoEmJhbCg2DcERSMuyAIKphwhBkrw4s0KdKkhZEckRBbo58B4Zuawe8uimHPR5xYgRIZbf8O1A+IXNODH8PVws9u3/XfY6bEHEM+deRN/xk= Received: by 10.114.59.1 with SMTP id h1mr168491waa.1194964508276; Tue, 13 Nov 2007 06:35:08 -0800 (PST) Received: by 10.114.24.18 with HTTP; Tue, 13 Nov 2007 06:35:08 -0800 (PST) Message-ID: <669132de0711130635t4cc86e71x2eac32668d1b52b0@mail.gmail.com> Date: Tue, 13 Nov 2007 16:35:08 +0200 From: "Alupului Costin" To: J65nko In-Reply-To: <19861fba0711130430p6cc08013ibfd14b6fb9d2df60@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <669132de0711121208n32bfb827p4984c6d3383da713@mail.gmail.com> <19861fba0711130430p6cc08013ibfd14b6fb9d2df60@mail.gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: PF, bridge, states and window scaling problem X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2007 14:35:16 -0000 On Nov 13, 2007 2:30 PM, J65nko wrote: > > On Nov 12, 2007 9:08 PM, Alupului Costin wrote: > > Hello all, > > > > I seem to have quite a problem with PF. I have set up a bridge to > > shape my upstream traffic. I use ALTQ with hfsc discipline; but that's > > not really important. My problem comes with the filter rules. I have > > to use keep state because of the speed benefits (really I don't have a > > choice), but PF has a problem when the clients passing traffic through > > the bridge use TCP window scaling. Here is an example of four filter > > rules that I thought should work to pass the traffic from one client > > through the bridge and create a state: > > > > pass in quick on vlan0 from any to anIP/32 > > pass out quick on vlan0 from anIP/32 to any keep state queue ul_client > > pass in quick on vlan1 from anIP/32 to any > > pass out quick on vlan1 from any to anIP/32 keep state queue dl_client > > > > The above rules generate state-mismatches. I thought that would be > > because pf doesn't see the SYN packet, although it does (one of the > > out rules) and should create the state then... I tried writing all the > > rules with keep state (even the inbound ones) but then nothing would > > work at all. My intention was to create if-bound states, but I > > switched back to floating states in the hope that pf would associate > > the state created by an outbound rule with the traffic returning on > > another interface of the bridge; still didn't work. > > > > I have read the man page for if_bridge and set the following sysctl variables: > > > > net.link.bridge.pfil_onlyip: 1 > > net.link.bridge.pfil_bridge: 0 > > net.link.bridge.pfil_member: 1 > > > > I have also read some posts on the web that said that pf simply > > doesn't have all the hooks necesary to do the filtering inbound and > > outbound, but reading the pfil man page I seem to disaggree with that. > > > > Has anyone encountered the same problem? And, more important: if i > > give up the bridge setup and switch to routing, would that have any > > effect? I.E: will I then be able to use keep state with the inbound > > rules? > > > > Any help at all would be hugely appreciated as I am trying for about a > > week to sort out this problem and can't seem to get any closer. The > > only solution was to kindly ask my clients using TCP window scaling > > (Vista mostly) to turn off this feature... Now I am seriously > > considering bumping my bridge to a router but I am not sure that the > > problem will be solved then. > > > > Oh, here is the setup of the bridge from rc.conf, although there > > shouldn't be any problems there (the bridge works fine without pf, or > > with pf stateless): > > > > # > > # Core: em2 -> vlan1 > > # Border: em1 -> vlan0 > > # Bridge0 vlan0 -><- vlan1 > > # > > cloned_interfaces="bridge0 vlan0 vlan1" > > ifconfig_em0="up" > > ifconfig_em1="up" > > ifconfig_em2="up" > > ifconfig_vlan0="vlan 132 vlandev em1 up" > > ifconfig_vlan1="vlan 132 vlandev em2 up" > > ifconfig_bridge0="addm vlan0 addm vlan1 up" > > # Admin iface > > ifconfig_em0="inet adminIP netmask 255.255.255.0" > > > > See "Create TCP states on the initial SYN packet" from > http://undeadly.org/cgi?action=article&sid=20060928081238 > > That paragraph explains nicely the necessity of pf to create state on > the first packet of the 3-way TCP handshake to prevent TCP window > scaling issues. I aggree with you. My problem is why doesn't pf establish the connection correctly with the first outbound rule (the SYN packet passes that rule). Furthermore: why everything stalls if I use keep state on the inbound rules also? Because that would make the most sense: using keep state with every rule... In a routing environment it all works fine, but not with the bridge. So I guess that the problem could be the bridge, although everything else works fine besides "keep state" on inbound rules... Costin > > =Adriaan= > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" >