hello; reply below. On 6/20/05, Sven-Haegar Koch <haegar@xxxxxxxxx> wrote: > On Mon, 20 Jun 2005, terry l. ridder wrote: > > > On 6/20/05, Sven-Haegar Koch <haegar@xxxxxxxxx> wrote: > >> On Mon, 20 Jun 2005, terry l. ridder wrote: > >> > >>>>> one example of the leak is below: > >>>>> > >>>>> 200.0.0.0/8 is dropped if the destination port is 25 (smtp). > >>>> > >>>> iptables-save(8) output, please. What you posted here doesn't tell us > >>>> much. > >>>> > >>> > >>> 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 > >> > >> You are filtering in the nat table. > >> > > > > yes, i am. > > > >> The nat table gets only the first packet from each connection (the one > >> that would match -m state --state NEW). > >> > > > > that is incorrect. the nat table is getting all packets. > > no, it's not. > no, that is incorrect. > > please have a look at "man iptables": > > nat: > This table is consulted when a packet that creates a new > connection is encountered. It consists of three built-ins: > PREROUTING (for altering packets as soon as they come in), > OUTPUT (for altering locally-generated packets before rout- > ing), and POSTROUTING (for altering packets as they are > about to go out). > there is no connection, netfilter or tcp. any packets from 200.0.0.0/8 with destination port 25 (smtp) are dropped, end of story. they are being dropped in nat prerouting. they are not source nat'ed or destination nat'ed, they are dropped. there is no connection, netfilter or tcp, ever established. > > Note the "is consulted when a packet that creates a new connection is > encountered" - once for every new connection, not for all following > packets. > again there is no connection. they are dropped before any connection, netfilter or tcp, can be established. > > >> A retransmit from the blocked IP will not be a new connection, > >> so it will pass through your rules. > > > > again this is incorrect. > see above, your logic is flawed. > > no - once a connection entry in /proc/net/ip_conntrack is created, a > restransmit will match this entry even if it's a tcp-syn again. > > netfilter-connections are different from tcp connections. > it does not matter whether they are different or the same. there is no connection, netfilter or tcp. the packets are being dropped in nat prerouting before any type of connection can be established. > > >> And on your comment to another mail that you are not using connection > >> tracking: > >> This is wrong. If you have the nat table, you must have ip_conntrack > >> loaded - and if its loaded it tracks your connections, even if you > >> dont use -m state at all. There is no iptables nat without connection > >> tracking. > > > > i may have been looking at the wrong window, i will check on that. > > thr textfile referenced your other mail contains IP_NF_CONNTRACK=m for > your firewall - connection-tracking is at least built. > > And if you load the nat support (aka iptable_nat module) the ip_conntrack > module will be loaded, too. > yes it it. so what? from the firewall box: Module Size Used by ipt_LOG 7008 1 af_packet 21316 0 ipt_limit 2848 3 iptable_nat 27780 1 ip_conntrack 46928 1 iptable_nat iptable_filter 3264 1 ip_tables 17712 4 ipt_LOG,ipt_limit,iptable_nat,iptable_filter <snip> i said i looked at the wrong window and i corrected that mistake. > > c'ya > sven > -- terry l. ridder ><>
