I was in the process of investigating conntrack when your message came in. This all happened while the machine was active and the interface for the faulty ISP was still "up". There was a cached SNAT entry in conntrack that was bypassing the application of the updated rules. I flushed everything with conntrack -D -p udp (the main issue was SIP traffic) and everything cleared up immediately. Respectfully, ~Bradley Hook, J.D. Network Administrator Google Certified Project Manager Kansas State Schools for the Deaf and the Blind bhook@xxxxxxxxxxxxxx Mobile: 913-275-9982 On Mon, Mar 31, 2025 at 11:51 AM Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > On Mon, Mar 31, 2025 at 11:19:31AM -0500, Bradley Hook wrote: > [...] > > The issue we are seeing is that packets from 192.168.122.252 to > > 8.8.8.8 are not traversing the postrouting chain at all. We can see > > the packets leaving the interface without NAT applied. We can see the > > packets hitting the forward chain with the trace. Other traffic from > > other subnets are being masqueraded just fine. We just aren't seeing > > the packets from 192.168.122.x/24 hit any postrouting rules at all. > > Can you check if connection tracking is tagging these packets as > invalid? -- *Kansas State Schools for the Deaf and the Blind Confidentiality Notice**:* The information contained in this e-mail transmission is confidential and legally protected. It is intended for the sole use of the individual(s) entity named in the message header. If you are not the intended recipient, you are hereby notified that any dissemination or copying of this information is strictly prohibited. If you received this message in error, please notify the sender of the error and delete this message and any attachments.
