DNS moze byt 53/TCP aj 53/UDP. Ak je to vacsia siet napriklad firemna, alebo nieco podobne, mozno by bolo vhodnejsie DNSka riesit skor, nez cez NAT zavedenim miestnej DNS cache. Jednak to zrychli vybavovanie DNS resolve poziadaviek na tie najpouzivanejsie servery a za druhe mas moznost zabezpecit, ze ti budu tunelovat traffic cez o 1 menej port, aj ked som videl tunelovanie trafficu uz aj cez DNS a ICMP packety.
Potom u toho posledneho pravidla je chyba v tom, ze ho mas definovane ako "zahod vsetky packety tcp prichadzajuce na interface eth1 z danej siete", co ti okrem toho, ze zahodi vsetky packety, ktore by sa snazili cez natku prejst a doteraz neboli akceptovane, zahodi aj vsetky packety, ktore sa snazili dojst len k serveru (intranetova webova stranka). Mozno je tam to pravidlo zbytocne, lebo ak to tak vezmes, mas tam pravidlo, ktore vsetok traffic na porte 80 presmeruje na transparentny squid proxy, vsetok traffic na portoch 21,22,110 atd. hodi na NATovanie. Z toho vyplyva, ze keby sa niekto snazil o konekciu na iny port, automaticky ho nechyti ani jedno z NAT pravidiel a tento packet netreba routovat, do chainu INPUT by sa nemal ani dostat (kedze tam idu len packety, ktore su urcene pre lokalny stroj) a ostatne packety netreba zahadzovat.

Konkretne ma teraz napada jeden problem, ktory vznikne s FTP, ktore vyuziva debilny system pridelovania portov a s tymto nastavenim ti zrejme nepotrebuje, treba si precitat manualove stranky k rozsireniu conntrack-ftp, alebo ako sa presne vola, to umi sledovat FTP komunikaciu a zistit, na ktory port pojde komunikacia a nasledne to do istej miery poriesit.