<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Nftables on Margrop Blog</title>
    <link>https://blog.margrop.net/en/tag/nftables/</link>
    <description>Recent content in Nftables on Margrop Blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-US</language>
    <lastBuildDate>Sat, 30 May 2026 15:45:00 +0800</lastBuildDate>
    <atom:link href="https://blog.margrop.net/en/tag/nftables/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>You Can SSH Out, but Not Back In: A Fail2Ban False Positive That Broke Reverse Access</title>
      <link>https://blog.margrop.net/en/post/reverse-ssh-fail2ban-vpn-gateway-investigation/</link>
      <pubDate>Sat, 30 May 2026 15:45:00 +0800</pubDate>
      <guid>https://blog.margrop.net/en/post/reverse-ssh-fail2ban-vpn-gateway-investigation/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;Bottom line&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;The symptom looked simple: I could SSH from the local machine into a remote internal host, but the reverse SSH path failed when the remote host tried to connect back. &lt;code&gt;sshd&lt;/code&gt; was listening, the route table looked fine, and the failure still happened.&lt;/p&gt;&#xA;&lt;p&gt;The real root cause was not a broken SSH daemon. &lt;code&gt;Fail2Ban&lt;/code&gt; had banned the &lt;strong&gt;VPN gateway address&lt;/strong&gt; that represented the return path. From the local machine&amp;rsquo;s point of view, the incoming SSH session did not appear to come directly from the remote host. It appeared to come from the gateway, so the ban cut off the whole reverse path.&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>Avoiding the Trap: Why Fail2Ban Fails on Ubuntu 26.04 &amp; PVE 9.2 (And How to Fix It)</title>
      <link>https://blog.margrop.net/en/post/ubuntu-2604-pve-92-fail2ban-nftables-guide/</link>
      <pubDate>Tue, 26 May 2026 22:20:00 +0800</pubDate>
      <guid>https://blog.margrop.net/en/post/ubuntu-2604-pve-92-fail2ban-nftables-guide/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;The Bottom Line&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;With the releases of Ubuntu 26.04 LTS and Proxmox VE (PVE) 9.2, many system administrators, DevOps engineers, and self-hosting enthusiasts have eagerly upgraded or clean-installed these latest systems. However, during the post-installation security hardening phase, you may encounter a highly frustrating scenario: &lt;strong&gt;simply copying over your legacy Fail2Ban configuration files from older versions (such as Ubuntu 20.04/22.04 or PVE 7.x/8.x) will either cause the Fail2Ban service to crash during startup or, worse, run silently in the background while completely failing to block external brute-force attacks!&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;This issue is not caused by a bug in Fail2Ban itself. Instead, it is the result of three &amp;ldquo;invisible bombs&amp;rdquo; hidden beneath the surface of these modern Linux distributions, namely changes in the logging architecture, service activation mechanisms, and firewall backends. This article provides an in-depth analysis of these three architectural shifts and introduces a modern, bulletproof Fail2Ban configuration guide fully integrated with &lt;code&gt;systemd-journald&lt;/code&gt; and &lt;code&gt;nftables&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
  </channel>
</rss>
