PF: matching gif(4) encapsulated IPv6

K

kpa

For some reason I can't figure this out. I want to match outgoing IPv6 traffic that is encapsulated in a gif(4) tunnel (I have an IPv6 tunnel from SixXS) for the purpose of traffic shaping. The traffic looks like this on tcpdump(8):

Code: 
00:48:11.317165 00:1b:21:14:ca:5e > 00:16:c7:98:08:80, 
ethertype IPv4 (0x0800), length 129: (tos 0x0, ttl 30,
id 48032, offset 0, flags [none], proto IPv6 (41), length 115)

mytunnelendpoint > remoteendpoint: (hlim 64, next-header UDP (17) payload length: 55)
 2001:14b8:abc:xyz::2.12350 > 2001:500:14:6011:ad::1.53: [udp sum ok] 32006% [1au]
AAAA? shikhar.mos.com.np. ar: . OPT UDPsize=4096 OK (47)

I thought this rule would match this traffic but for some reason it isn't. This is the first pass rule for outgoing traffic in my rules so it should match, what am I missing?

Code: 
pass out log quick on $WAN inet proto 41 from ($WAN) to any queue(qWAN_proto41)
 
Try filtering/shaping on the gif0 interface instead of trying to shape the IPv6-over-IPv4 traffic.
 
That would probably work if I wanted to prioritize certain IPv6 traffic over other types of of IPv6 traffic in the tunnel but I want to prioritize the encapsulated IPv6 vs other IPv4 traffic in the real WAN interface.
 
Ah, yes, that makes sense. The protocol 41 should be correct but perhaps the source and destination addresses aren't. Are you sure the tunnel is set up with the first IP address of $WAN?
 
I have an alias on WAN interface to access an ADSL modem web configurator. The tunnel however is set up with the public IP of the interface:

Code: 
# ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
        tunnel inet myendpoint --> remoteendpoint
        inet6 fe80::6ef0:49ff:fed3:b400%gif0 prefixlen 64 scopeid 0x6 
        inet6 2001:14b8:abc:xyz::2 --> 2001:14b8:abc:xyz::1 prefixlen 128 
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        options=1<ACCEPT_REV_ETHIP_VER>

And my pf rule is now using the endpoint addresses directly, still no match.
 
Does the rule get any hits or is the shaping not working?
 
The rule gets 0 hits. The shaping works for other IPv4 traffic.

How do I interpret this state entry?
Code: 
all ipv6 myendpoint -> remoteendpoint       MULTIPLE:MULTIPLE
   age 16:34:45, expires in 00:00:59, 98569:96671 pkts, 15674926:55181128 bytes

This is clearly the state entry for the encapsulated IPv6 traffic, however there's no rule number mentioned. How was this state created?
 
I could probably solve this by changing the tunnel type to AYIYA that uses a tun(4) device and UDP transport. I'm still curious about the proto 41 mystery though, guess I'll take this to the mailing list.
 
This turned out to be my mistake after all, I should have reseted states after changing configuration. Now the rule works and the encapsulated IPv6 is assigned to a queue.
 
You must log in or register to reply here.
Back
Top