All of lore.kernel.org
 help / color / mirror / Atom feed
From: "mdpeters" <michael.peters@lazarusalliance.com>
To: Daniel Chemko <dchemko@smgtec.com>, netfilter@lists.netfilter.org
Subject: Re: transparent bridge troubles?
Date: Fri, 7 Jan 2005 15:36:06 -0500	[thread overview]
Message-ID: <001e01c4f4f8$83367ef0$3e0010ac@esonet18> (raw)
In-Reply-To: 7C9884991ADAE0479C14F10C858BCDF5679642@alderaan.smgtec.com

I'm afraid I don't understand what you mean by "Write a log rule before and 
after the QUEUE rules".

This is what I have:

/usr/local/sbin/iptables -P FORWARD DROP
/usr/local/sbin/iptables -A FORWARD -p tcp --syn -m state --state NEW -j 
QUEUE
/usr/local/sbin/iptables -A FORWARD -p tcp -m state --state 
RELATED,ESTABLISHED -j QUEUE
/usr/local/sbin/iptables -A FORWARD -p udp -j QUEUE
/usr/local/sbin/iptables -A FORWARD -p icmp -j QUEUE

Do you mean this?

/usr/local/sbin/iptables -P FORWARD DROP
/usr/local/sbin/iptables -A FORWARD -p tcp --syn -m state --state NEW -j 
QUEUE
/usr/local/sbin/iptables -A FORWARD -p tcp --syn -m state --state NEW -j LOG
/usr/local/sbin/iptables -A FORWARD -p tcp -m state --state 
RELATED,ESTABLISHED -j QUEUE
/usr/local/sbin/iptables -A FORWARD -p tcp -m state --state 
RELATED,ESTABLISHED -j LOG
/usr/local/sbin/iptables -A FORWARD -p udp -j QUEUE
/usr/local/sbin/iptables -A FORWARD -p udp -j LOG
/usr/local/sbin/iptables -A FORWARD -p icmp -j QUEUE
/usr/local/sbin/iptables -A FORWARD -p icmp -j LOG

#/usr/local/sbin/iptables -vnxL

Chain INPUT (policy ACCEPT 1179077 packets, 74033865 bytes)
    pkts      bytes target     prot opt in     out     source 
destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source 
destination
       0        0 QUEUE      tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x16/0x02 state NEW
       0        0 LOG        tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x16/0x02 state NEW LOG flags 0 level 4
       0        0 QUEUE      tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           state RELATED,ESTABLISHED
       0        0 LOG        tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           state RELATED,ESTABLISHED LOG flags 0 level 4
       0        0 QUEUE      udp  --  *      *       0.0.0.0/0 
0.0.0.0/0
       0        0 LOG        udp  --  *      *       0.0.0.0/0 
0.0.0.0/0           LOG flags 0 level 4
       0        0 QUEUE      icmp --  *      *       0.0.0.0/0 
0.0.0.0/0
       0        0 LOG        icmp --  *      *       0.0.0.0/0 
0.0.0.0/0           LOG flags 0 level 4

Chain OUTPUT (policy ACCEPT 2284490 packets, 3277660612 bytes)
    pkts      bytes target     prot opt in     out     source 
destination

----- Original Message ----- 
From: "Daniel Chemko" <dchemko@smgtec.com>
To: "mdpeters" <michael.peters@lazarusalliance.com>; 
<netfilter@lists.netfilter.org>
Sent: Friday, January 07, 2005 3:24 PM
Subject: RE: transparent bridge troubles?



> I am queuing all of the packets to a userspace daemon for
> Snort-inline to process. If Snort is the problem then could you
> advise me on the iptables to pass everything through the transparent
> bridge to eliminate it from the equation?

Write a log rule before and after the QUEUE rules.

You'll probably find that they enter the QUEUE targets section and never
leave. The QUEUE target will never return a packet to the system unless
the userspace program has processed the packet, so it snort-inline is
turned off or broken, none of the matched packets will pass through
QUEUE.

The problem is that there's no graceful timeout period in which QUEUE
assumes that the userspace process is dead. There should be a flag that
says the packet will 'continue'/'drop'/'accept' based on the userspace
program's timeout.




  reply	other threads:[~2005-01-07 20:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-07 20:24 transparent bridge troubles? Daniel Chemko
2005-01-07 20:36 ` mdpeters [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-01-07 21:38 Daniel Chemko
2005-01-07 22:01 ` mdpeters
2005-01-07 22:18   ` Jason Opperisano
2005-01-08  0:40     ` mdpeters
2005-01-08  2:00       ` Jason Opperisano
2005-01-08  3:53         ` mdpeters
2005-01-08  4:15           ` Jason Opperisano
2005-01-08 12:12             ` mdpeters
2005-01-07 20:42 Daniel Chemko
2005-01-07 20:44 ` Jason Opperisano
2005-01-07 20:55   ` mdpeters
2005-01-07 21:01     ` Jason Opperisano
2005-01-07 21:16       ` mdpeters
2005-01-07 21:35       ` mdpeters
2005-01-07 20:14 mdpeters
2005-01-07 18:53 mdpeters
2005-01-07 19:44 ` Jason Opperisano
2005-01-07 21:53 ` Jason Opperisano
2005-01-07 22:02   ` mdpeters

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='001e01c4f4f8$83367ef0$3e0010ac@esonet18' \
    --to=michael.peters@lazarusalliance.com \
    --cc=dchemko@smgtec.com \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.