Your sysctl says one thing, the kernel says another

You set net.ipv4.ip_forward=1 in /etc/sysctl.conf. You rebooted. The value is still 0.

Nothing is broken, and you did not make a typo. On a host running UFW, there is a second sysctl file, and it wins.

Two files, one kernel

UFW ships /etc/ufw/sysctl.conf and loads it when the firewall comes up. It takes precedence over /etc/sysctl.conf. Anything you set in the familiar file that UFW also sets is quietly overwritten on the next ufw enable.

Quietly is the operative word. There is no warning, no log line, no diff. The file you edited still contains exactly what you typed — which is why this costs hours rather than minutes: you keep re-reading a correct file.

The symptom that most often brings people here: a WireGuard tunnel that comes up, a client that receives its address, and no traffic going anywhere. ip_forward fell back to 0.

Read the effective value, not the file

sysctl net.ipv4.ip_forward          # what the kernel applies
cat /proc/sys/net/ipv4/ip_forward   # same thing, one file

If that disagrees with what you wrote, look in /etc/ufw/sysctl.conf. Note the notation there uses slashes:

net/ipv4/ip_forward=1

Both net.ipv4.ip_forward and net/ipv4/ip_forward name the same knob. Grepping for only one of them is a good way to conclude the setting is absent when it is not.

A small script to stop guessing

I wrote a read-only checker that compares effective sysctl values against hardening recommendations and, more importantly, flags the ones that are declared somewhere and not applied:

 ECART  kernel.kptr_restrict            effectif=0      attendu=2
 ECART  fs.protected_hardlinks          effectif=0      attendu=1
         declare a 1 dans /etc/sysctl.conf, mais le noyau applique 0

That second line is the whole point. No dependencies, Python 3 only, changes nothing:
https://gitlab.com/ler.eric/sysctl-hardening-check

While we are here: what hardening does not cover

Tightening sysctl narrows what a compromised process reaches on that machine. It says nothing about the paths that never touch the machine — a password reused on a service that leaked, a session left open on a device you no longer carry, the one account that receives every recovery link.

That distinction is worth keeping in view: Linux hardening, what it covers and what it does not.

One line to keep: the file you edited is not necessarily the file that wins.