PF issue since 11.2-RELEASE

[ASV]

On Sun, 2019-01-27 at 16:08 +0100, Kristof Provost wrote:
> On 26 Jan 2019, at 17:00, ASV wrote:
> > since I've upgraded to 11.2 (from 11.1) I've observed that anytime
> > I
> > change something on pf.conf and reload (pfctl -f /etc/pf.conf) I
> > partially loose connectivity. Partially means that I still am 
> > connected
> > to the server but the server cannot connect anywhere or ping
> > anything
> > (no hosts no IPs) also the jails instantly suffers from the same.
> 
> That sounds like your established connection continues (because it
> keeps 
> using the old rules), and something is wrong with the new rules.
Hi and thanks for your reply!
This is not the case as I'm modifying NAT rules so I'm not expecting
anything to start being blocked but the reverse.
 
> The logical debugging steps would be:
>   - check the ruleset matches what you expect (pfctl -s rules)
>   - check the state table (pfctl -s states)
>   - use pflog to determine what rule causes traffic to be dropped
> 
> > The quickest fix is to revert the PF configuration to the previous
> > one
> > and reload. Everything starts working again.
> > 
> 
> What do you mean by ‘previous one’? Do you have two rulesets? What 
> are the two rulesets?
The configuration hasn't been changed in ages and when I need to
upgrade the ports of a couple of jails which are NOT routed to the
internet I simply un-comment few NAT lines and reload the pf conf. I've
been doing this specific action for almost 7 years, never a problem.
Therefore there is no problem in the rules.

For previous ruleset I mean that since the jails start losing
connectivity (as long as I "push" the new ruleset) with internet and
with each other, I re-comment these lines and reload. Sometime it works
sometime it doesn't and I need to:

service pf restart

which obviously forces me to re-login.

> > I've been trying to find the root cause of this without success.
> > Did I
> > miss some major change on the PF port on FreeBSD? I've never seen
> > this
> > serious issue before nor on FreeBSD neither on OpenBSD.
> 
> It’s very difficult to debug this with the extremely limited 
> information you’ve included.
> Please post, at the very least, your pf ruleset and a full
> description 
> of what you’re doing when things break and how you recover.
#nat on $ext_if from $SRV01 to any -> ($ext_if:0)
#nat on $ext_if from $SRV02 to any -> ($ext_if:0)
#nat on $ext_if from $SRV03 to any -> ($ext_if:0)

not much really. But the same happens with other rules. Basically
whatever I modify there now requires a full pf restart, which is not
very practical as it kicks me out.

I'm also having plenty of issues using fail2ban, just to mention
another as it is somehow related (even though a broader topic), where
rules are in place but aren't enforced.

# pfctl -a f2b/asterisk-udp -t f2b-asterisk-udp -Ts
   <offending ip address>
   <offending ip address>
   <offending ip address>

# pfctl -a f2b/asterisk-udp -t f2b-asterisk-udp -s rules
block drop quick proto udp from <f2b-asterisk-udp> to any port = sip
block drop quick proto udp from <f2b-asterisk-udp> to any port = sip-tls

then killing the state (if any) and check:
# pfctl -k <offending ip address> ; tcpdump udp -nettt -i pflog0 port 5060 and host <offending ip address>
killed 1 states from 1 sources and 0 destinations
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 262144 bytes
 00:00:00.000000 rule 24/0(match): pass in on lagg0: <offending ip address>.6175 > <target ip address>.5060: SIP: REGISTER sip:<target ip address> SIP/2.0                                                     
 00:01:07.344401 rule 24/0(match): pass in on lagg0: <offending ip address>.6115 > <target ip address>.5060: SIP: REGISTER sip:<target ip address> SIP/2.0                                                     
 00:00:39.690851 rule 24/0(match): pass in on lagg0: <offending ip address>.6158 > <target ip address>.5060: SIP: REGISTER sip:<target ip address> SIP/2.0                                                     
 00:00:43.058753 rule 24/0(match): pass in on lagg0: <offending ip address>.6179 > <target ip address>.5060: SIP: REGISTER sip:<target ip address> SIP/2.0                                                     
 00:00:43.912680 rule 24/0(match): pass in on lagg0: <offending ip address>.6119 > <target ip address>.5060: SIP: REGISTER sip:<target ip address> SIP/2.0

it is clearly not enforcing the rules.

> Regards,
> Kristof
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe at freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20190127/2c6511a5/attachment.sig>