PF issue since 11.2-RELEASE

[Kristof Provost]

On 27 Jan 2019, at 19:03, ASV wrote:
> 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.
>
Please share the full pf.conf. I’m sure you understand that I cannot debug your problem without *full* information.

Regards,
Kristof
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 549 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20190128/3197f626/attachment.sig>