Podczas śledzenia połączeń w zaporze sieciowej, zwłaszcza na urządzeniach MikroTik korzystających z RouterOS, może się okazać, że niektóre połączenia nie mają określonego stanu TCP na liście.

Dzieje się tak zazwyczaj dlatego, że te połączenia nie są typu TCP. Śledzenie połączeń w zaporze sieciowej nie ogranicza się do połączeń TCP; Śledzi także inne typy ruchu, takie jak UDP, ICMP i inne, które nie korzystają z modelu zorientowanego na połączenie i zdefiniowanych stanów stosowanych przez protokół TCP.

Wiadomo, że protokół TCP ma proces ustanawiania i kończenia połączenia, który obejmuje różne stany (takie jak SYN_SENT, ESTABLISHED, FIN_WAIT itp.). Stany te umożliwiają szczegółowe śledzenie cyklu życia połączenia TCP.

Z drugiej strony protokoły takie jak UDP (User Datagram Protocol) y ICMP (protokół komunikatów kontroli Internetu) to przykłady protokołów, które nie ustanawiają połączenia zorientowanego na stan w taki sam sposób jak TCP. Dlatego nie mają „stanów TCP” jako takich.

• Dla ruchu UDP, który jest bezpołączeniowy, nie oczekuje się żadnego procesu ustanawiania ani kończenia połączenia, więc koncepcja stanu połączenia w sensie protokołu TCP nie ma zastosowania. Jednak zapora może nadal śledzić sesje UDP na podstawie kombinacji źródłowego i docelowego adresu IP oraz numerów portów, ale nie będą one rejestrowane w określonych stanach TCP.
• Dla ruchu ICMP, który jest używany głównie do wysyłania komunikatów o błędach lub komunikatów kontrolnych (takich jak te używane przez polecenie ping), również nie ma zastosowania koncepcji stanu połączenia TCP.

Podsumowując, jeśli wpis w śledzeniu połączenia zapory sieciowej nie wskazuje stanu TCP, prawdopodobnie reprezentuje ruch inny niż TCP i dlatego nie stosuje modelu stanu połączenia używanego przez protokół TCP.

Aby zarządzać tym ruchem i go zrozumieć, uwzględniane są inne aspekty śledzenia połączeń, takie jak typy protokołów, adresy źródłowe i docelowe oraz zaangażowane porty.