hello. reply below. On 6/21/05, Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx> wrote: > On Tue, 21 Jun 2005, terry l. ridder wrote: > > > > > On 6/21/05, Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx> wrote: > > > On Mon, 20 Jun 2005, terry l. ridder wrote: > > > > > > > while i have reservations concerning posting the output of iptables-save > > > > i have placed it on my web server: > > > > > > > > http://204.238.34.206/iptables-save-20jun2005.txt > > > > > > Thou salt not filter in the nat table. > > > > there is no good reason not to filter in the nat table. > > Your firewall setup is a perfect example why one should not filter in the > nat table. > my firewall has worked for many years just the way it is, never had any problems with any leaks of any kind. > > Look at the packets which "leaked in": all of them TCP RST packets. > yes, they are all tcp rst packets. > > According to the TCP connection tracking, a RST packet which belongs to no > known connection will be marked as INVALID. Because it's a NEW INVALID > packet, connection tracking drops the conntrack reference immediately. > Consequently, as having no conntrack reference attached to the packet, the > nat table skips processing it. And because you intentionally not filter in > the filter table, the packets "leak in". > there is not connection to track. all packets from 200.0.0.0/8 with destination port 25 (smtp) are dropped. the only addresses leaking in are the 200.0.0.0/8 with destination port 25 (smtp). none of the other network address blocks which are blocked are leaking. if what you wrote above were true i should be seeing more tcp rst packets from blocked network address blocks leaking in. i am not. therefore, what you wrote above is not true. > > Thou salt not filter in the nat table. > will you please stop with the 'party line'. > > Best regards, > Jozsef > -- terry l. ridder ><>
