Re: NAT, not doing route_me_harder?

Balazs Scheidler wrote: Hi, I was wondering what the reason is for NAT not rerouting modified packets? If anything important is modified by a mangle rule that affects routing, the routing decision is automatically redone as this code fragment shows: [snip] This is done only in the OUTPUT

Re: NAT, not doing route_me_harder?

Balazs Scheidler wrote: But what happens when you initiate a connection on the host running netfilter, thus you have no PREROUTING chain? You have the OUTPUT chain. If I'm doing SNAT in POSTROUTING, the routing decision is not redone, thus it leaves with the specified source address, but

Connection Tracking and FIN+ACK packets

I am not sure if this matter has been discussed previously... If that's true, please, point me to the place where the answer is... I am using netfilter on a screening router, and I detected that FIN+ACK packets coming from web sites are blocked by the firewall. For the moment, I am using a

Re: NAT, not doing route_me_harder?

On Wed, Jun 26, 2002 at 12:04:23PM +0200, Henrik Nordstrom wrote: Balazs Scheidler wrote: I think I now understand, have my packets marked in local OUTPUT, route based on that mark, and SNAT based on the marks. Is this the way you suggested? Hmm.. this sounds reasonable on the programmer's

Re: performance issues (nat / conntrack)

On Tue, Jun 25, 2002 at 11:47:12PM +0200, Jean-Michel Hemstedt wrote: agreed. (strange thing is that ethernet irq's reported by procinfo are decreasing when the machine is overloaded. It suppose that it means either that irq's are not even caught by the kernel/driver, which is quite

Re: Connection Tracking and FIN+ACK packets

On Wed, Jun 26, 2002 at 12:09:48PM +0200, Antonio E. Mart?nez wrote: I am not sure if this matter has been discussed previously... If that's true, please, point me to the place where the answer is... yes. please look at the list archives. -- Live long and prosper - Harald Welte / [EMAIL

Re: performance issues (nat / conntrack)

(strange thing is that ethernet irq's reported by procinfo are decreasing when the machine is overloaded. It suppose that it means either that irq's are not even caught by the kernel/driver, which is quite worrying, or either that irq's counters refer to 'processessed'

MSN Messenger ALG

Hi, Is there a ALG for MSN Messenger in iptables? I need that to get file transfer and voice working between NATed clients. thanks for any help, -amir

[PATCH] (trivial) memory leakage in userspace iptables.c::merge_options()

Hello, This is just a small patch that free's unused memory in iptables.c::merge_options(). It's vs the file in the CVS. -- cheers, Bart --- iptables.c.old Mon Jun 24 14:37:29 2002 +++ iptables.c Wed Jun 26 23:05:34 2002 -986,6 +986,8 merge[num_old + i].val += *option_offset; }

Re: performance issues (nat / conntrack)

On Tue, 25 Jun 2002, Jean-Michel Hemstedt wrote: connections. As good as possible. If the conntrack table becomes full, there are two possibilities: - conntrack table size is underestimated for the real traffic flowing trough. Get more RAM and increase the table size. -