0

Our PF firewall contains this:

. . .
scrub in all fragment reassemble no-df max-mss 1440
### em1 ipv4 = 123.12.3.234
nat               log   on $ext_if \
                  from  $net_nat \
                  to    any -> ($ext_if)
. . .
antispoof         log   for $ext_if
block return  out log   all
block drop    in  log   all
. . .

Followed somewhat later by this:

pass          in  log   quick \
                  from  11.22.33.164 \
                  to    any

pass          out log   quick \
                  from  any \
                  to    11.22.33.164

However, TCPDUMP shows this happening:

 00:00:00.116888 rule 3/0(match): block in on em1: 11.22.33.164.2148 > 123.12.3.234.59865: Flags [R.], seq 1, ack 1, win 5707, length 0

 00:00:00.115632 rule 3/0(match): block in on em1: 11.22.33.164.2148 > 123.12.3.234.62733: Flags [R.], seq 1, ack 1, win 159, length 0

 00:00:00.011031 rule 2/0(match): block out on em1: 123.12.3.234.64105 > 11.22.33.164.2148: Flags [P.], seq 2111901423:2111901475, ack 316150303, win 258, length 52

 00:00:00.074555 rule 3/0(match): block in on em1: 11.22.33.164.2148 > 123.12.3.234.58208: Flags [.], ack 1, win 159, length 0

 00:00:00.065409 rule 3/0(match): block in on em1: 11.22.33.164.2148 > 123.12.3.234.56489: Flags [.], ack 1, win 159, length 0

 00:00:00.077103 rule 3/0(match): block in on em1: 11.22.33.164.2148 > 123.12.3.234.62245: Flags [P.], seq 0:36, ack 1, win 136, length 36

 00:00:00.040241 rule 3/0(match): block in on em1: 11.22.33.164.2148 > 123.12.3.234.58208: Flags [.], ack 1, win 159, length 0

 00:00:00.026616 rule 3/0(match): block in on em1: 11.22.33.164.2148 > 123.12.3.234.56489: Flags [R.], seq 1, ack 1, win 159, length 0

My question is: Why? What is causing the later 'quick' rule to not match and instead letting the default rules take effect?

  • Run "pfctl -sr -vv", identify and post the the blocking rules. – Vladimir Botka Feb 23 '19 at 6:59
  • Rule 2 is: block return out log all Rule 3 is: block drop in log all – James B. Byrne Feb 26 '19 at 16:57
0

If I'm reading this right, you have a NAT router, and a client behind it that you wish to allow out to the internet. I'm noticing that almost all of my rules state the interface they apply to, and don't bother stating the direction. Yours are the other way around, heavy on the direction but don't specify the interface.

Looking at your only two 'pass' rules,
pass in quick from 11.22.33.164 to any pass out quick from any to 11.22.33.164
These only make sense when applied to your router's LAN interface. The first permits that particular IP to talk to the router and whatever it's connected to, the other lets things talk to that IP via the router. That's an okay first step. However, I believe the packet is not allowed to proceed any further, beause the corresponding rules for the WAN interface are missing. Though I don't remember if 'nat' requires this (and if the IP used in the rule needs to be pre-nat or post-nat). A quick thing to try would be to remove the 'in' and 'out' keywords from those two rules.

In my home setup, I dodge most of the work by using these kinds of sloppy shortcuts:
set skip on { lo0 $lan_if $vpn_if } # trusted interfaces nat on $wan_if inet from !$wan_if to any -> ($wan_if:0) pass out quick all # outbound default to allow block return in quick all no state # inbound default to deny, return icmp(unreachable)

| improve this answer | |
0

It looks more like there's some kind of state mal-synchronisation other than rules logic's issue.

You could try to loosen scrub partially or removing it completely. For e. g., no-df is being cut-copied blindly, but removing DF would interfere with Path MTU discovery.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.