Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Feb 2019 10:26:26 -0500
From:      "James B. Byrne" <byrnejb@harte-lyne.ca>
To:        freebsd-questions@freebsd.org
Subject:   PF firewall filter question
Message-ID:  <59c9343e65915ba4136cb1d9142b6c69.squirrel@webmail.harte-lyne.ca>

next in thread | raw e-mail | index | archive | help
We are required to use a third-party Windows terminal emulator to
connect to a specific application VAN provider.  It passes from our
internal network to the provider via NAT on our new FreeBSD-12 f/w
gateway.  Since switching to this new gateway users are experiencing
occasional fatal errors with this application and the communications
session involved is dropped.

We have looked at the PF fireall logging using tcpdump and note that
some packets to and from the provider are being blocked by the default
rules even though specific pass rules with the quick option appear to
apply.  For some reason these rules are not being triggered and the
packets are dropped.  This appears to be the source of the fatal
errors on the clients.

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?  How do I fix
this such that these blocks do not take place, without disabling the
firewall altogether?



-- 
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?59c9343e65915ba4136cb1d9142b6c69.squirrel>