From owner-freebsd-doc@FreeBSD.ORG Wed Nov 9 12:23:33 2005 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1012B16A420; Wed, 9 Nov 2005 12:23:33 +0000 (GMT) (envelope-from cuk@cuk.nu) Received: from jedi.netinet.si (jedi.netinet.si [213.143.65.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20D4643D45; Wed, 9 Nov 2005 12:23:21 +0000 (GMT) (envelope-from cuk@cuk.nu) Received: from localhost (localhost [127.0.0.1]) by jedi.netinet.si (Postfix) with ESMTP id 45A96125493; Wed, 9 Nov 2005 02:43:12 +0100 (CET) Received: from jedi.netinet.si ([127.0.0.1]) by localhost (jedi.netinet.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62363-09; Wed, 9 Nov 2005 02:43:11 +0100 (CET) Received: from [192.168.6.60] (tm.213.143.78.60.lc.telemach.net [213.143.78.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jedi.netinet.si (Postfix) with ESMTP id 9CFB4125461; Wed, 9 Nov 2005 02:43:11 +0100 (CET) Message-ID: <43715469.9030505@cuk.nu> Date: Wed, 09 Nov 2005 02:44:09 +0100 From: Marko Cuk Organization: NetInet User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Laier References: <436FDC90.3020108@cuk.nu> <4370AA76.8000309@cuk.nu> <20051108171544.GI37350@green.homeunix.org> <200511081946.19860.max@love2party.net> In-Reply-To: <200511081946.19860.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at NetInet.si Cc: Brian Fundakowski Feldman , freebsd-doc@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Tun and ALTQ X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 12:23:33 -0000 Max, tnx for explanation and others to help. Second thing is route-to routing capability of pf. I have one dual homed firewall and the configuration is very complicated, because I must have two NAT's ( certain subnets through one ISP, certain through another ) , routing, filtering, ALTQ, ... The firewall has one default route and that NAT, which is on default route, works ok. The problem is NAT on another ISP, which works, but the packet ( translated from RFC1918 to public IP ) is sent through DEFAULT route instead on the ISP2's default gateway ( next hop ). I have solved it like that: em0 is default ISP and has default route, em1 is ISP2 pass out on em0 route-to (em1 x.x.x.1.) from x.x.x.2 to any but still it won't "catch" all packets and tcpdumping em0 show me, that on em0 i get outgoing x.x.x.2 IP's ... The reply comes on em1 , that's ok. I have managed it with ipf, like that: pass out quick on em0 to em1:x.x.x.1 from x.x.x.2 to any but I still don't like to have 2 packet filters on host... Does anyone have a clue for that ? I can't catch the packet on internal interface, because there is RFC1918 IP ( 192.168.x.x ) and if I route-to it, it will "bypass" NAT and that not ok :) . If I do NAT and catch it on outer interface, there are some packets "leaking" through on default route. Anyone with that setup here ? Bye, Marko Max Laier wrote: >On Tuesday 08 November 2005 18:15, Brian Fundakowski Feldman wrote: > > >>On Tue, Nov 08, 2005 at 02:39:02PM +0100, Marko Cuk wrote: >> >> >>>It seems that it work. Thanks. >>> >>>Damn, for vlan's ( 802.1Q) you should specify "em", for "tun", vice >>>versa... what a mess, hehe. >>> >>> >>No prob; I don't see why using the em(4) backing the tun(4) wouldn't >>work for ALTQ _IF_ you actually tagged the (PPPoE?) traffic on em(4). >>I think that might be really hard, though, so for ALTQ you should >>probably just specify the "logical" interface that you intend to >>limit (that would be the IP tun(4) rather than the PPPoE em(4)). >> >> > >The problem with tun(4) in contrast to vlan(4) is that in some cases the >packet has to go through userland (i.e. userland PPPoE). During this detour >the packet loses the ALTQ mbuf_tag and thus can no longer be stuck into the >right queue. That is why there is ALTQ support on tun(4) eventhough it >doesn't make that much sense to introduce "unnatural" queueing in the pseudo >interface. For vlan(4) there is no such problem (VLANs are handled in the >kernel all the way) so it's easy to stick the ALTQ tags on the packet and >queue on the hardware interface underneath. > > > >>Do you have suggestion on what would be good text to go into pf.conf(5) >>so that this particular case is documented? >> >> > >[-> doc@, maybe somebody is interested/creative? ] > > > -- NetInet d.o.o. http://www.NetInet.si Private: http://cuk.nu MountainBikeSlovenia team: http://mtb.si Slovenian FreeBSD mirror admin http://www2.si.freebsd.org