hrmm, iptables -A vs. iptables-restore

2002-03-28 Thread Nigel Kukard
hrmm, interesting question this would it be faster to reload say about 100 rule tables one by one when needed, or push all the firewall tables/rules (say bout 20,000 rules) with iptables-restore at one time? i have a firewall script which can say reload SNAT or DNAT tables without clearing

Re: [PATCH] ipv6header fix

2002-03-28 Thread Harald Welte
On Mon, Mar 25, 2002 at 12:18:00AM +0100, Andras Kis-Szabo wrote: Hi, there's a patch to the ipv6header match module. (I handled the skb structure in a wrong way) [in debug mode with the tcpreplay6 is a very usefull thing :)] ++if 0

Re: BUG: max number of expected connections

2002-03-28 Thread Frank
Hallo and this BUG appeared again today but with Kernel 2.4.19-pre4-ac2 and Iptables CVS from 27.03.02. Applied all pending-patches cleanly but newnat would so i forced it and compiled fine. Mar 28 01:26:32 Frankux kernel: ip_conntrack: max number of expected connections 1 of ftp reached for

Re: TPROXY and original dest address question

2002-03-28 Thread Balazs Scheidler
It doesn't handle currently any of them. Fragmentation can be solved by defragmenting incoming packets. (they are destined to the local ip stack anyway) Defragmentation is defenitely needed for this thing to be used in production. For experimentation conntrack can be used to

RE: Request for a Beginning in libiptc and libipq

2002-03-28 Thread Sumit Pandya
Hi Paul, I'm still not sure why you wanted to automate such process at kernel level. But Its really an interesting thought. Ya It took a little long time to move on your problem, but I've a hope to achieve this. You know me too usually take interest in such adventures, so I took you

[PATCH] transparent proxying, #2 release

2002-03-28 Thread Balazs Scheidler
Hi, I have prepared a work-in-progress patch showing which directions I'm heading with my transparent proxy patches. Here is a summary of changes: 1) It is now possible to query where a connection was destined. It is using the method Henrik Nordstrom suggested: I defined the IP_ORIGADDRS

Re: TPROXY and original dest address question

2002-03-28 Thread Henrik Nordstrom
Balazs Scheidler wrote: Where is the possible transparent proxy entries defined? Internally in TPROXY, or in the host IP stack socket table? in TPROXY. Is TPROXY is a stand-alone netfilter module, not a iptables target? I thought it was a iptables target, but from your answer it seems

Re: TPROXY and original dest address question

2002-03-28 Thread Balazs Scheidler
On Thu, Mar 28, 2002 at 04:02:46PM +0100, Henrik Nordstrom wrote: Balazs Scheidler wrote: Where is the possible transparent proxy entries defined? Internally in TPROXY, or in the host IP stack socket table? in TPROXY. I guess this would be the rule table telling what should be

Strange Contracker problem in conjuction with Cisco Content Switch

2002-03-28 Thread Martin Sperl
Hi! We are experiencing problems with connection tracking with a Cisco Content Switch behind a firewall and think that it might partly be a problem with netfilter in stock Linux 2.4.17. We just started using CSS in a productive environment and now the number of connections in

Re: TPROXY and original dest address question

2002-03-28 Thread Balazs Scheidler
On Thu, Mar 28, 2002 at 04:39:51PM +0100, Henrik Nordstrom wrote: Thanks. Explains it quite well. So there is yet another state table involved here. Now I am a little confused. What exacly is it that makes this new state table better suited for the job than conntrack? because we don't

Re: TPROXY and original dest address question

2002-03-28 Thread Henrik Nordstrom
Balazs Scheidler wrote: because we don't do full TCP tracking, and our NAT is quite limited. (only DNAT, and only to local IP stack). And in addition entries are not timeouted from the table. a new entry is added to this table when 1) a TPROXY destination is encountered 2) when a socket

[PATCH] add --reject-with tcp-synack to REJECT

2002-03-28 Thread Aaron Hopkins
Here's a minimalist patch-in-patch against 1.2.6a to add a --reject-with tcp-synack option to the REJECT extension. TCP SYN packets are replied to with a valid SYN-ACK, all others are dropped. This will leave incoming connections in the ESTABLISHED state on the remote side, significantly slowing