Guillaume Morin wrote:
Dans un message du 07 jun à 11:31, Emmanuel Fleury écrivait :
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -j ACCEPT
iptables -A FORWARD -j DROP
Does that mean that you DROP all the ACKs, even those which are valid
Of
Emmanuel Fleury wrote:
Henrik Nordstrom wrote:
This configuration can be done just fine with iptables as demonstrated in
my earlier message, but here we go again (but slightly different):
# Allow existing connections
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Emmanuel Fleury wrote:
Does this means that you are mapping the packets to a state (NEW,
ESTABLISHED, RELATED, INVALID) only based on information on their
header and a query to the connection table ? And that you do not
care about the previous state of the connection ?
No,
Guillaume Morin wrote:
I really do not understand what you mean. The conntrack stores the
previous state of TCP connection. So indeed when a packet arrives, it
checks the information of the TCP and IP headers and tries to see if
there is something stored about this TCP connection.
On Fri, 7 Jun 2002, Oskar Andreasson wrote:
Another, related, usage is
if we have a redundant firewall (I haven't seen this discussed so far
so Consider this:
1 main firewall
1 router
and a secondary firewall.
The three are set up in a routing zone. If the main firewall goes
down,
Joerg Mayer [EMAIL PROTECTED] writes:
On Fri, Jun 07, 2002 at 12:10:09PM +1000, Rusty Russell wrote:
If their firewall reboots and is running iptables and thus Linux: How
long will it be down?
120 seconds to reboot with a fixed kernel...
Umm, OK, I shouldn't have compared the
Rusty Russell wrote:
If their firewall reboots and is running iptables and thus Linux: How
long will it be down?
120 seconds to reboot with a fixed kernel...
More like 20 seconds with a standard modular kernel for firewall boxes with a
slimmed OS running on commodity hardware..
With a
Hi,
Guillaume Morin wrote:
I looked at the code and I was kind of wrong. Every untracked packets
are considered as NEW. That means that a syn/ack packet, a rst packet
will be matched as NEW.
Yes, I just checked it in the piece of code you pointed out (see below).
The documentation is
Hey all,
There have been some questions on these lists regarding my 'recent'
module and just wanted to drop a short note letting people know that
I've released a *BETA* version of the module on my site
(http://snowman.net) at http://snowman.net/projects/ipt_recent/ .
This is still very
Hi Emmanuel,
Dans un message du 07 Jun à 17:13, Emmanuel Fleury écrivait :
The documentation is correct because it means
the connection in the conntrack sense NOT in the TCP sense.
I disagree on this point. The documentation is not correct.
Or, at least, the documentation is not precise
The funny thing is that if you have a bad ruleset, you can easily be
DOSed by some external people which are just sending random ACK packets.
Those ACKs will create entries in your connection table as ESTABLISHED
connections with a time-out of 5 days ! 8-)
Well no, since the
Damiano Bolzoni wrote:
Hi people,
I wrote a kernel module that uses netfilter. I'm interested on incoming IP
packets that carry a TCP segment with SYN flag active. What I want to do is
to know which socket has been created in order to handle that connection
and I want to close it. sk_buff
On Fri, Jun 07, 2002 at 10:15:26AM +0200, Emmanuel Fleury wrote:
Precisely.
Actually, my exact complain is now that the documentation is not
making you awared of what you are exactly doing...
Somehow, this is dangerous and can lead you to have a flaw in your
firewall without being awared
Hi,
Attached is a small optimization for __ip_conntrack_find().
The way I read the use of the LIST_FIND macro it seems that we are
calling hash_conntrack() for each iteration with the same inparameters.
My change calls it once before looping.
--
/Martin
Never argue with an idiot. They drag
Hi Guillaume,
Guillaume Morin wrote:
The documentation is correct because it assumes you understand
connection as a conntrack entry.
Hum.
I do agree that it should be more explicit.
We met an agreement so.
The funny thing is that if you have a bad ruleset, you can easily be
DOSed by
Patrick Schaaf wrote:
The funny thing is that if you have a bad ruleset, you can easily be
DOSed by some external people which are just sending random ACK packets.
Those ACKs will create entries in your connection table as ESTABLISHED
connections with a time-out of 5 days ! 8-)
Well no,
Hi,all
I have write a module for DNAT to achieve the purpose as follows:
iptables -A PREROUTING -t nat -p udp -d 159.226.1.1 --dport 5001 -j DNAT --to
192.168.1.2:
my code is in
http://lists.samba.org/pipermail/netfilter-devel/2002-June/004621.html
The expected conntrack in
17 matches
Mail list logo
