On Wed, 18 Apr 2007, Tillman Hodgson wrote: > Previously you pointed out the ipfw man page which seems to be say the same > thing (albeit with much less detail): > > gid group > Matches all TCP or UDP packets sent by or received for a group. > A group may be specified by name or number. This option should > be used only if debug.mpsafenet=0 to avoid possible deadlocks due > to layering violations in its implementation. > > Setting debug.mpsafenet=0 worked for me until the TCP timer change. Is the > LOR situation always true for every inbound packet, or only with certain > firewall rules in place? > > That question has me wondering if I can avoid the issue by avoiding certain > PF features. My current ruleset is pretty simple. If I drop the variables > definitions and comments, the whole thing is 13 lines: The LOR occurs in the context of rules that perform PCB lookups at higher network stack layers from the firewall. Specifically, rules looking up the user and group of the connection. If you omit user and group rules from your rule set, that should catch it. I'm not sure if pf supports jail matching or not, but the same would apply to that. Robert N M Watson Computer Laboratory University of Cambridge > > nat on $ext_if from $internal_net to any -> ($ext_if) > rdr on $int_if proto tcp from $internal_net to any port ftp -> 127.0.0.1 port 8021 > block log all > pass quick on lo0 all > pass quick on $int_if proto ospf all > pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_services flags S/SA keep state > pass in on $ext_if inet proto udp from any to ($ext_if) port $udp_services keep state > pass in on $ext_if inet proto icmp all icmp-type $icmp_types keep state > pass in on $ext_if inet proto tcp from any to $ext_if user proxy keep state > pass in on $int_if from $metanetwork to any > pass out on $int_if from any to $metanetwork > pass out on $ext_if proto tcp all modulate state flags S/SA > pass out on $ext_if proto { udp, icmp } all keep state > > -T > > > -- > "There is a time in the life of every problem when it is big enough to > see, yet small enough to solve." > -- Mike Leavitt > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >Received on Wed Apr 18 2007 - 14:00:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:08 UTC