your ipv6 traffic is bypassing your firewall rules

the door you forgot you installed

you locked down iptables, you're feeling good about your firewall rules, you tested them, they work. cool. except almost every modern linux box has a second stack running right next to the one you just secured, and it's called ipv6. it's on by default, it's usually wide open, and your v4 rules do absolutely nothing to protect it. this isn't some exotic edge case, it's just a blind spot that most people never think to check.

check what's actually listening on ipv6

before you fix anything, find out what's exposed. this command shows you every listening socket and tells you whether it's v4 or v6:

ss -tulnp

look for anything with an address like :::22 or :::80. the triple colon is shorthand for "all ipv6 interfaces," which means that service is reachable over ipv6 the same way it would be over v4, sometimes with zero firewall coverage. ssh is the classic one people find here, since a lot of ssh daemons bind to both stacks by default without anyone noticing.

why your v4 rules don't help

iptables only filters ipv4 traffic. it has no idea ipv6 packets exist. so if you spent an afternoon building a tight default-deny policy with iptables, that policy is invisible to anything arriving over ipv6. an attacker doing basic recon will scan both stacks, and if they find your v6 side unguarded while v4 is locked up tight, they've just found the easier way in. it's not clever hacking, it's just walking through the door you left open because you were busy locking the other one.

mirror your policy with ip6tables

the fix is straightforward: ip6tables is the ipv6 counterpart to iptables, and it uses the same syntax. if you already have a solid v4 ruleset, you're mostly copying it over with v6-appropriate addresses.

start with a default deny posture:

ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT ACCEPT

then allow loopback and established connections so you don't break your own traffic:

ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

then explicitly allow whatever you actually need, matching whatever you already allowed in iptables. if ssh is meant to be reachable, allow it deliberately instead of by accident:

ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT

the goal is parity. whatever your v4 policy says "allow" and "deny," your v6 policy should say the same thing. don't just default-allow v6 because it felt too annoying to configure, that's exactly the gap attackers are hoping you left.

one more thing: these rules don't survive a reboot unless you save them. depending on your distro that's something like ip6tables-save piped into a persistent rules file, or using your distro's firewall persistence tool. check that your rules actually stick around after a restart, because "it worked when i set it up" is not the same as "it's actually protecting me."

or just turn it off if you don't need it

if you're not using ipv6 at all, the simpler and arguably safer move is disabling it outright. fewer moving parts, fewer things to forget to firewall. you can do this at the kernel level with sysctl:

sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1

to make that stick across reboots, add those same two lines to /etc/sysctl.conf or a file in /etc/sysctl.d/. run ss -tulnp again afterward and confirm nothing's listening on v6 anymore. if you do need ipv6 for something, like a hosting provider that requires it, then don't disable it, go the ip6tables route instead. don't disable a thing you actually rely on just because it's easier, that just creates a different outage later.

the takeaway

a firewall that only covers half your network stack isn't really a firewall, it's a partial firewall with a confident attitude. take five minutes today: check what's listening on ipv6 with ss -tulnp, decide if you actually use it, and either mirror your existing rules with ip6tables or shut the stack down at the kernel level. either answer is fine. what's not fine is not knowing, because that second door doesn't care that you locked the first one.