C'est un comportement normal à mes yeux.
L'ajout d'une règle avec la target TRACE devrait te confirmer que les paquets sont bloqués par le firewall.
Cordialement,
Thomas
C'est même pire que ça ! Si je fais un nmap depuis l'extérieur sur le serveur en question, j'obtiens bien : legendre# nmap 192.168.15.18 Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-03 14:09 CEST Nmap scan report for 192.168.15.18 Host is up (0.00078s latency). Not shown: 987 filtered tcp ports (no-response) PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 443/tcp open https 465/tcp closed smtps 587/tcp open submission 993/tcp open imaps 995/tcp open pop3s 2401/tcp closed cvspserver 4443/tcp closed pharos 5222/tcp open xmpp-client 9418/tcp open git MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer) Nmap done: 1 IP address (1 host up) scanned in 5.01 seconds legendre# ce qui semble correspondre aux ports effectivement ouverts. Mais un tcpdump sur l'interface publique de la machine testée voit bien passer tous les paquets (pas seulement ceux correspondant ax ports ouverts). Idem en UDP : legendre# nmap -sU 192.168.15.18 Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-03 14:11 CEST Nmap scan report for 192.168.15.18 Host is up (0.00053s latency). Not shown: 997 open|filtered udp ports (no-response) PORT STATE SERVICE 53/udp open domain 123/udp open ntp 10000/udp closed ndmp MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer) Nmap done: 1 IP address (1 host up) scanned in 5.81 seconds legendre# Lorsque j'utilisais iptables-legacy, je n'ai jamais observé cela. Par ailleurs, ça n'explique pas que des paquets à destination d'un port fermé aboutissent bien à mon serveur asterisk... Bien cordialement, JKB