Le code, le code, le code ?

(Il paraît que se répéter est à la mode, à la mode, à la mode...)

Quand lire la doc de la distribution (et des autres, notamment celle d'ArchLinux suggère qu'il peut manquer des morceaux...) ne suffit pas, j'ai tendance à aller regarder le code, et surtout l'historique.

Je te suggère donc ceci dans systemd.git :

git log --grep IPMasquerade

Certains messages de commit sont plutôt verbeux, par exemple 715a70e7218710d6a6c033e9157bf97fdf5d8ede, qui mentionne :

table ip io.systemd.nat {
 set masq_saddr {
 type ipv4_addr
 flags interval
 elements = { 192.168.59.160/28 }
 }
[...]
 chain postrouting {
 type nat hook postrouting priority srcnat + 1; policy accept;
 ip saddr @masq_saddr masquerade
 }
}

Et oui, la transition entre iptables et nftables est complètement chaotique, puisque les deux sont co-installables (avec iptables qui tire nftables), des alternatives disponibles pour iptables en mode legacy ou nft mais bien évidemment, en fonction de comment les règles sont positionnées, les différents outils les voient ou non...

Et bien évidemment, de nombreux outils continuent à dépendre (via Depends plutôt que Recommends, donc non négociable...) d'iptables, ce qui exclut de purger ce paquet pour limiter les interactions foireuses...

En fonction de l'ensemble des paquets installés, tu peux essayer de virer iptables pour voir si ça aide.

Si c'est plutôt un problème côté systemd, tu peux essayer de regarder ce que fait src/shared/firewall-util-nft.c pour voir si ça te donne une piste quant à un éventuel réglage manquant dans ta configuration ?

Enfin, il existe un backport pour Debian stable, si tu soupçonnes un éventuel problème upstream qui serait déjà corrigé, mais ça fait plein de paquets à mettre à jour (dont udev et différentes bibliothèques), et c'est un peu pénible de revenir en arrière ensuite.

Debian Consultant @ DEBAMAX