> pf can filter fine on gif interfaces, including matching ToS. You have
> to apply your rules on the gifN interface, e.g.
> 
> pass in on gif0 from any to any tos 0x08
Ahh, I assumed that because no traffic was listed when I tcpdump'd my
gif interface that nothing could be done about it.  Its ok as the ToS
values are passed up from the gif interface to the tun interface, so it
doesn't matter where I match it.

But anyway, for some reason the tos matching is only somewhat working.

relevant rules are as follows:
pass out on $ext_if proto esp from ($ext_if) to $cobalt
pass in  on $ext_if proto esp from $cobalt to ($ext_if)
pass out on $ext_if proto { tcp , udp } from ($ext_if) to $cobalt port
500
pass in  on $ext_if proto { tcp , udp } from $cobalt to ($ext_if) port
500
pass out on $ext_if proto esp from ($ext_if) to $cobalt tos 0x68 queue (
high_out )
pass out log on $ext_if proto esp from ($ext_if) to $cobalt tos 0xb8
queue ( ef_out )

and the queue stats give me the following:
[EMAIL PROTECTED] pfctl -s q -v
queue std_out priq( default )
  [ pkts:        146  bytes:      37840  dropped pkts:      0 bytes:
0 ]
  [ qlength:   0/ 50 ]
queue low_out priority 2 priq( red )
  [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:
0 ]
  [ qlength:   0/ 50 ]
queue high_out priority 4
  [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:
0 ]
  [ qlength:   0/ 50 ]
queue tcp_ack_out priority 5
  [ pkts:         50  bytes:       2200  dropped pkts:      0 bytes:
0 ]
  [ qlength:   0/ 50 ]
queue ef_out priority 6
  [ pkts:        317  bytes:      75228  dropped pkts:      0 bytes:
0 ]
  [ qlength:   0/ 50 ]

Logs show that both ToS values are present:
7. 707142 rule 13/0(match): pass out on tun0: (tos 0x68, ttl  64, id
19839, offset 0, flags [none], proto: ESP (50), length: 136)
203.214.76.15 > <cobalt>: ESP(spi=0x32502e5f,seq=0x942), length 116
059524 rule 13/0(match): pass out on tun0: (tos 0xb8, ttl  64, id 19840,
offset 0, flags [none], proto: ESP (50), length: 264) 203.214.76.15 >
<cobalt>: ESP(spi=0x32502e5f,seq=0x943), length 244

Note how the high_out queue has nothing against it.  My general traffic
over the VPN is put into std_out, which is fine, but all voice traffic
from my voip phone is places into the ef_out queue, I only want the
traffic with 0x68 to be put there.

pf version is whatever is with FreeBSD 6.0



The TOS/DSCP byte in the packet is somewhat confusing, and maybe I don't
realise what is being matched.

Correct me if I am wrong, but the ToS byte is built as follows:
3 bit IP Precedence value, followed by a 4 bit ToS value, followed by a
zero
P2 P1 P0 T3 T2 T1 T0 zero

Is the tos statement matching on all 8 bits, just the P bits or just the
T bits?

I have investigated this somewhere, and no matter what the answer is,
none of the methods described above with provide the same match.

0x68 011 0100 0
0xb8 101 1100 0

And given the ToS field is actually described in the logs as 0x68 and
0xb8 you would assume it would use all 8 bits to match against.




Adam Clark
Network Administrator

National Gallery of Victoria
PO Box 7259 Melbourne Vic 8004
Telephone: +61 3 8620 2369 
Fax: +61 3 8620 2565
www.ngv.vic.gov.au

Keep informed of the latest NGV exhibitions, special events and programs at The 
Ian Potter Centre: NGV Australia and NGV International by subscribing to [EMAIL 
PROTECTED], the NGV's free e-newsletter.

DISCLAIMER: This email and any files transmitted with it are confidential and 
intended solely for [EMAIL PROTECTED],[EMAIL PROTECTED] If you are not the 
named addressee you should not disseminate, copy or alter this email. WARNING: 
Although National Gallery of Victoria has taken reasonable precautions to 
ensure no viruses are present in this email, the organisation cannot accept 
responsibility for any loss or damage arising from the use of this email or 
attachment.

Reply via email to