Pour des serveurs NTP, le connection tracking ne sert à rien à part consommer des entrées dans une table. C'est un paquet UDP de requête, un paquet de réponse, basta, plus rien pendant 30min-1h de la part du client, et encore.. si il n'a pas changé d'IP d'ici là.
Dans ces cas là, notrack est très utile.

Tout à fait Thierry Simon, mais ça ce n’est qu’une partie des trucs à faire 

0 dans le sens expire de suite ou n'expire jamais? Un timeout de ~50ms-1s  peut probablement fonctionner pour le traffic NTP, je suppose. Notrack, c'est plus propre, mais il faut pouvoir le spécifier en effet.

Par contre, ce réglage, c'est global ou ca se fait règle par règle? Car si c'est global, ca risque de ne pas être top.

illimité l'OS va avoir des vapeurs assez rapidement. Non c'est pas de conservation du contexte. C'est en global sur l'interface Unifi, par type de protocole (ICMP,UDP...) ou état de la connexion TCP (SYN, FIN WAIT etc.). Après tu prends pas un Unifi pour aller gratter des IPTABLE à la main en SSH.

Corollaire : je vais choquer un paquet de monde, mais quand tu offres un service tu mets son IP publique en direct sur Internet. Et pour deux raisons :
1 - tu maitrises ton OS ton serveur est une brique au delà du port du service que tu souhaites offrir et n'a aucun risque y a rien qui écoute ur d'autres ports.
2 - si ton firewall ne vérifie pas que c'est bien du NTP dans le paquet entrant et du NTP/UDP propre il ne sert strictement à rien en se contentant de bêtement transmettre le paquet. La NAT est le degrés zéro de la sécu.


Le tracking c'est plutôt quand on doit aller dans le paquets et changer l'IP source pour des protocoles qui ne supporte pas la NAT (SIP, GRE,FTP...) et qu'on doit surveiller le paquet de réponse pour l'acheminer à la bonne machine source