this is not a complaint or a worry or a question. i believe
the statement of the subject line is pf working properly.
here is just a heads up, in case someone who uses 'rdr pass'
wonders why their queueing doesn't seem to put packets into
the queue they want, but rather puts packets into the default queue.
i had:
nat on $e inet from 192.168.7.1 to any tag "192.168.7.1" -> ($e)
rdr pass on $e inet proto tcp from any to ($e) port 6881:6889 \
tag 192.168.7.1 -> 192.168.7.1 port 6881:*
later on in the ruleset, i:
pass in on $e inet all modulate state label "ob_192.168.7.1" \
queue( ul-hklocal-1 extack ) tagged 192.168.7.1
pass out on $e inet all modulate state label "ib_192.168.7.1" \
queue( ul-hklocal-1 extack ) tagged 192.168.7.1
an edited down snippet from my altq declarations is:
altq on $e hfsc bandwidth $e_bw queue {extdef extack ext-lan}
queue extdef bandwidth 10% hfsc( realtime( 0% 4000 1% ) \
linkshare( 0% 1000 10% ) upperlimit $e_bw default )
queue extack bandwidth 10% hfsc( realtime( 0% 1000 1% ) \
linkshare( 0% 100 5% ) upperlimit 5% )
queue ext-lan bandwidth 10% hfsc( realtime( 0% 9000 1% ) \
linkshare( 0% 199 5% ) ) { ul-hklocal-1 }
queue ul-hklocal-1 bandwidth 10% hfsc ( realtime( 0% 9000 5% ) \
linkshare( 0% 200 5% ) upperlimit $e_bw )
i am queueing all outbound from 192.168.7.1 into that 'ul-hklocal-1'
queue. there are also other queues for the other 192.168.7.xxx hosts,
but that doesn't matter for the example.
i found that my bittorrent uploads were being queued into 'extdef'
and not 'ul-hklocal-1' even though the ruleset seemed to make sense
otherwise.
by removing the 'pass' from the rdr, the packets are queued as i hope.
this makes sense, as 'pass' to rdr is like a "quick" on a normal pf-rule,
and therefore the packet was probably indeed being tagged as '192.168.7.1',
but since it was 'pass'ed right then and there, never saw the rule
down below which queued '192.168.7.1' tagged packets into 'ul-hklocal-1'.
unless i'm completely wrong again; that is always possible. <G>
jared
--
[ openbsd 3.5 GENERIC ( mar 26 ) // i386 ]
