This means that for rules like:
pass in quick on $ext_if proto tcp from any to $colo port 21 flags S/SA keep state label "PASS:$proto:$srcaddr:$dstaddr:$dstport"
pass in quick on $ext_if proto tcp from any to $colo port 22 flags S/SA keep state label "PASS:$proto:$srcaddr:$dstaddr:$dstport"
pass in quick on $ext_if proto tcp from any to <colo_all> port 45000 >< 46000 flags S/SA keep state label "PASS:$proto:$srcaddr:$dstaddr:$dstport"
Instead of really exciting and useful stuff like:
# pfctl -vsl PASS:tcp:10.0.0.1:192.168.0.1:21 1232 0 0 PASS:tcp:10.5.5.20:192.168.0.1:22 1162 0 0 PASS:tcp:10.3.2.1:192.168.55.100:62444 1232 0 0
I'm stuck with really useless and static information like:
# pfctl -vsl PASS:tcp:any:192.168.0.1:21 1232 0 0 PASS:tcp:any:192.168.0.1:22 1162 0 0 PASS:tcp:any:<colo_all>:60000 >< 65000 1232 0 0
In case you couldn't tell the difference, the former did dynamic parsing of $dstaddr, $srcaddr and $dstport in runtime, while the latter simply interpolates the value from the filter definition. A sampling of the kind of stuff that can be extracted can be found in an earlier beta of my work at http://www.dixongroup.net/pflabel.jpg, but this pales in comparison to what I had/have planned.
I don't mean to sound like a leach or ingrate, because I most certainly am not. I'll be the first to pitch in where I can, but those who know me well don't want me hacking on PF. On the other hand, I've been happy to donate hardware and cash in the past and would be happy to do it again for this feature. I've discussed the possibilities for PF labels with Theo et al off-list in the past, so I'm hoping this might be something the PF team would be interested in pursuing.
Thanks,
-- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
