Tun and ALTQ

[Marko Cuk]

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