I'd like to leverage preauth, if possible, to add an optionally tighter access control to certain services. For example, let's look at SSH:
block in quick on fxp0 proto tcp from any to any port = 22 head 22 block in quick from <bad-ip-1> to any group 22 block in quick from <bad-ip-2> to any group 22 #...etc... pass in quick proto tcp from any to <ip-range-1> \ flags S/SAFR keep state group 22 pass in quick proto tcp from any to <ip-range-2> \ flags S/SAFR keep state group 22 #...etc... Could a preauth rule be added as the second rule in the group...? block in quick on fxp0 proto tcp from any to any port = 22 head 22 preauth in quick from any to any group 22 block in quick from <bad-ip-1> to any group 22 block in quick from <bad-ip-2> to any group 22 #...etc... pass in quick proto tcp from any to <ip-range-1> \ flags S/SAFR keep state group 22 pass in quick proto tcp from any to <ip-range-2> \ flags S/SAFR keep state group 22 #...etc... I'm concerned over the man page entry, which says, "If no further matching rule is found, the packet will be dropped..." Is this the case even for a preauth in a group? I'm hoping that, upon not finding a matching rule in the pre-auth. list, processing would "bounce back" to the group and continue processing the group rules. Or, should the paraenthetical statement, "...the FR_PREAUTH is not the same as FR_PASS," be interpreted to mean that rule processing doesn't work the same for preauth, and if a matching rule doesn't exist in the pre-auth. list, the packet really will be dropped right then and there (regardless of any pre-existing "group context")? Thanks, Mike
