In die opsporing van brandmuurverbindings, veral op MikroTik-toestelle wat RouterOS gebruik, kan u vind dat sommige verbindings nie 'n spesifieke TCP-staat gelys het nie.

Dit is gewoonlik omdat hierdie verbindings nie TCP-tipe is nie. Verbindingsopsporing in 'n firewall is nie beperk tot TCP-verbindings nie; Dit volg ook ander soorte verkeer soos UDP, ICMP, en meer, wat nie die verbinding-georiënteerde model en gedefinieerde state gebruik wat TCP gebruik nie.

Dit is bekend dat die TCP-protokol 'n verbindingsvestigings- en beëindigingsproses het wat verskeie state behels (soos SYN_SENT, ESTABLISHED, FIN_WAIT, ens.). Hierdie toestande laat gedetailleerde dop van die lewensiklus van 'n TCP-verbinding toe.

Aan die ander kant, protokolle soos UDP (User Datagram Protocol) y ICMP (Internet Control Message Protocol) is voorbeelde van protokolle wat nie 'n staatsgeoriënteerde verbinding op dieselfde manier as TCP tot stand bring nie. Daarom het hulle nie "TCP-state" as sodanig nie.

• Vir UDP-verkeer, wat verbindingloos is, word geen verbindingsvestiging of beëindigingsproses verwag nie, dus is die konsep van verbindingstaat, in die TCP-sin, nie van toepassing nie. Die firewall kan egter steeds UDP-sessies opspoor deur die kombinasie van bron- en bestemmings-IP-adres en poortnommers, maar dit sal nie by spesifieke TCP-toestande geregistreer word nie.
• Vir ICMP-verkeer, wat hoofsaaklik gebruik word om fout- of beheerboodskappe te stuur (soos dié wat deur die ping-opdrag gebruik word), pas ook nie die konsep van TCP-verbindingstatus toe nie.

Ter opsomming, as 'n inskrywing in jou firewall se verbindingspoor nie 'n TCP-toestand wys nie, verteenwoordig dit waarskynlik nie-TCP-verkeer en pas dit dus nie die verbindingtoestandmodel toe wat TCP gebruik nie.

Om hierdie verkeer te bestuur en te verstaan, word ander aspekte van verbindingnasporing oorweeg, soos protokoltipes, bron- en bestemmingsadresse en betrokke poorte.