Date: Wed, 09 Nov 2005 02:44:09 +0100 From: Marko Cuk <cuk@cuk.nu> To: Max Laier <max@love2party.net> Cc: Brian Fundakowski Feldman <green@freebsd.org>, freebsd-doc@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Tun and ALTQ Message-ID: <43715469.9030505@cuk.nu> In-Reply-To: <200511081946.19860.max@love2party.net> References: <436FDC90.3020108@cuk.nu> <4370AA76.8000309@cuk.nu> <20051108171544.GI37350@green.homeunix.org> <200511081946.19860.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43715469.9030505>