View Single Post
  #2   (View Single Post)  
Old 17th October 2019
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,983
Default

Be VERY CAREFUL with the restriction directives from, to, in, out, and on. They don't necessarily mean what you think they mean. My specific comments are shown after each referenced code block.
Code:
set block-policy drop
.
.
block return log
Your block-policy is not in use.
Code:
pass log from $OPS
$OPS resolves to the interface em0. PF will convert "from interface" directives without modifiers to "from the assigned addresses for the interface." For example, if em0 is assigned the address 10.11.1.1, then this rule will be interpreted as "from 10.11.1.1" -- which I assume is not your intent. Interfaces can have modifiers, such as "em0:network", and while you could shoehorn that in as a solution, I believe your intent is to allow traffic in on em0, rather than from em0.
Code:
pass in on $OPS inet proto tcp from $OPSUBNET to $OPS port $mgmt_ports
This is odd for two reasons.
  1. Two systems on the $OPS subnet can communicate with each other without involving this system. So "in on $OPS" combined with "to $OPS" isn't going to match any inbound traffic unless the destination address is an assigned address for the interface em0.
  2. If $OPS is a single-router endpoint network, then $OPSUBNET is unneeded, as all traffic from em2 will have a 10.11/16 source address anyway.
Code:
pass out on $OPS inet proto tcp to MGMT port $mgmt_ports
Here, you pass out on interface em0 your traffic which is actually destined for em2.

At this point, I think I'll suggest you draw a picture of your physical topography. As I think I recommended in your last several PF threads.
Reply With Quote