Date: Sun, 27 Jan 2019 19:03:40 +0100 From: ASV <asv@inhio.net> To: Kristof Provost <kp@FreeBSD.org> Cc: questions list <freebsd-questions@freebsd.org> Subject: Re: PF issue since 11.2-RELEASE Message-ID: <e336fd332455cc9fe9f722482aae09ed6eeab610.camel@inhio.net> In-Reply-To: <F26DA908-F2AC-4CBF-8227-A4C3D21865EE@FreeBSD.org> References: <989e79372513e9769c6857b531f14df8ce0b6f3a.camel@inhio.net> <F26DA908-F2AC-4CBF-8227-A4C3D21865EE@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-04pZx59WfHo0ykabVCoo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=20 > > 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. >=20 > That sounds like your established connection continues (because it > keeps=20 > 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. =20 > 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 >=20 > > The quickest fix is to revert the PF configuration to the previous > > one > > and reload. Everything starts working again. > >=20 >=20 > What do you mean by =E2=80=98previous one=E2=80=99? Do you have two rules= ets? What=20 > 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. >=20 > It=E2=80=99s very difficult to debug this with the extremely limited=20 > information you=E2=80=99ve included. > Please post, at the very least, your pf ruleset and a full > description=20 > of what you=E2=80=99re 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 =3D sip block drop quick proto udp from <f2b-asterisk-udp> to any port =3D 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 262= 144 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 =20 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 =20 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 =20 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 =20 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" --=-04pZx59WfHo0ykabVCoo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEE5dE8BwbhhcQw2TsezaQsUNd+zIkFAlxN8n0ACgkQzaQsUNd+ zIlRfQgApXpTzBgACdjHLFUPeeosLf/D3J3sof3x0se6MZGUY0+2On2ZdKxloE6u wRUxZVFSyjMACVnDzTLLD2kaNX0PfcPT2JsVAdXBVfecHNnlm03nRE6HJYs/k8et pfETDsCQBv+VtXrniRnyMCIWbhrU3iehrqH/GFYtEfrvfDeu9qPuX8QrYUAtEAIr Szp+zKSyuNik2leMA/eNl2IP6uMLnuxxwM6tVCcp0/4NO9znIa1ebpFiSEKacq68 x7DZSNLMW+CP5qhKw+kR43ZOKNfa0YOR3eMsJnD8ygND3HsD/c7WGay6FxIckKbH fmgsUeWMMntMi+YCufMvyhn5z0eArg== =dQU0 -----END PGP SIGNATURE----- --=-04pZx59WfHo0ykabVCoo--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e336fd332455cc9fe9f722482aae09ed6eeab610.camel>