RE: transparent bridge troubles?

RE: transparent bridge troubles?

[Daniel Chemko]

You missed a QUEUE target

/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


Becomes

/usr/local/sbin/iptables -P FORWARD DROP
/usr/local/sbin/iptables -A FORWARD -j LOG
/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
/usr/local/sbin/iptables -A FORWARD -j LOG

Re: transparent bridge troubles?

[Jason Opperisano]

On Fri, Jan 07, 2005 at 12:42:27PM -0800, Daniel Chemko wrote:
> Becomes
> 
> /usr/local/sbin/iptables -P FORWARD DROP
> /usr/local/sbin/iptables -A FORWARD -j LOG
> /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
> /usr/local/sbin/iptables -A FORWARD -j LOG

minor edit, for clarity sake:

/usr/local/sbin/iptables -P FORWARD DROP
/usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix "PRE QUEUE: "
/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
/usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix "POST QUEUE: "

-j

--
"Be careful when we capture him! We cannot claim the reward unless
 we have 51% of the carcass"
        --The Simpsons

Re: transparent bridge troubles?

[mdpeters]

OK. This is what I have loaded now.

/usr/local/sbin/iptables -P FORWARD DROP
/usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix 
/var/iptablequeue/pre_queue
/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
/usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix 
/var/iptablequeue/post_queue

I should see some sort of log file in /var/iptablequeue/post_queue or 
/var/iptablequeue/pre_queue now? Should I try sending packets through the 
bridge to generate something?

----- Original Message ----- 
From: "Jason Opperisano" <opie@817west.com>
To: <netfilter@lists.netfilter.org>
Sent: Friday, January 07, 2005 3:44 PM
Subject: Re: transparent bridge troubles?


> On Fri, Jan 07, 2005 at 12:42:27PM -0800, Daniel Chemko wrote:
>> Becomes
>>
>> /usr/local/sbin/iptables -P FORWARD DROP
>> /usr/local/sbin/iptables -A FORWARD -j LOG
>> /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
>> /usr/local/sbin/iptables -A FORWARD -j LOG
>
> minor edit, for clarity sake:
>
> /usr/local/sbin/iptables -P FORWARD DROP
> /usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix "PRE QUEUE: "
> /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
> /usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix "POST QUEUE: "
>
> -j
>
> --
> "Be careful when we capture him! We cannot claim the reward unless
> we have 51% of the carcass"
>        --The Simpsons
>
> 

Re: transparent bridge troubles?

[Jason Opperisano]

On Fri, Jan 07, 2005 at 03:55:58PM -0500, mdpeters wrote:
> OK. This is what I have loaded now.
> 
> /usr/local/sbin/iptables -P FORWARD DROP
> /usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix 
> /var/iptablequeue/pre_queue
> /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
> /usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix 
> /var/iptablequeue/post_queue
> 
> I should see some sort of log file in /var/iptablequeue/post_queue or 
> /var/iptablequeue/pre_queue now? Should I try sending packets through the 
> bridge to generate something?

uh--no.  those rules might not even load.  "--log-prefix" specifies a
string to prefix the log entries in your syslog files.  my rules were
literal:

/usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix "PRE QUEUE: "

...

/usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix "POST QUEUE: "

so the entries in /var/log/messages will have the strings "PRE QUEUE: "
and "POST QUEUE: " in them for identification purposes.

-j

--
"Kids, you tried your best and you failed miserably. The lesson is,
 never try."
        --The Simpsons

Re: transparent bridge troubles?

[mdpeters]

Du'oh!

I changed it and this is what I see so far. I'm running a Nessus scan on one 
side of the bridge and the target system is at the other side of the bridge.

PRE QUEUEIN=safetynet0 OUT=safetynet0 PHYSIN=eth2 PHYSOUT=eth1 
SRC=68.16.185.132 DST=68.16.185.130 LEN=41 TOS=0x00 PREC=0x00 TTL=64 ID=3072 
PROTO=TCP SPT=3133 DPT=45495 WINDOW=2048 RES=0x00 ACK URGP=0

POST QUEUEIN=safetynet0 OUT=safetynet0 PHYSIN=eth2 PHYSOUT=eth1 
SRC=68.16.185.132 DST=68.16.185.130 LEN=41 TOS=0x00 PREC=0x00 TTL=64 ID=3072 
PROTO=TCP SPT=3133 DPT=45495 WINDOW=2048 RES=0x00 ACK URGP=0


----- Original Message ----- 
From: "Jason Opperisano" <opie@817west.com>
To: <netfilter@lists.netfilter.org>
Sent: Friday, January 07, 2005 4:01 PM
Subject: Re: transparent bridge troubles?


> On Fri, Jan 07, 2005 at 03:55:58PM -0500, mdpeters wrote:
>> OK. This is what I have loaded now.
>>
>> /usr/local/sbin/iptables -P FORWARD DROP
>> /usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix
>> /var/iptablequeue/pre_queue
>> /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
>> /usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix
>> /var/iptablequeue/post_queue
>>
>> I should see some sort of log file in /var/iptablequeue/post_queue or
>> /var/iptablequeue/pre_queue now? Should I try sending packets through the
>> bridge to generate something?
>
> uh--no.  those rules might not even load.  "--log-prefix" specifies a
> string to prefix the log entries in your syslog files.  my rules were
> literal:
>
> /usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix "PRE QUEUE: "
>
> ...
>
> /usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix "POST QUEUE: "
>
> so the entries in /var/log/messages will have the strings "PRE QUEUE: "
> and "POST QUEUE: " in them for identification purposes.
>
> -j
>
> --
> "Kids, you tried your best and you failed miserably. The lesson is,
> never try."
>        --The Simpsons
>
> 

Re: transparent bridge troubles?

[mdpeters]

I only get the two entries and that is it? Should I not see many many lines 
showing everything I try to put through the bridge?

Does this indicate that the Snort-inline is broken in that QUEUE userspace 
or could this be something wrong with another component of this whole thing?

----- Original Message ----- 
From: "Jason Opperisano" <opie@817west.com>
To: <netfilter@lists.netfilter.org>
Sent: Friday, January 07, 2005 4:01 PM
Subject: Re: transparent bridge troubles?


> On Fri, Jan 07, 2005 at 03:55:58PM -0500, mdpeters wrote:
>> OK. This is what I have loaded now.
>>
>> /usr/local/sbin/iptables -P FORWARD DROP
>> /usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix
>> /var/iptablequeue/pre_queue
>> /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
>> /usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix
>> /var/iptablequeue/post_queue
>>
>> I should see some sort of log file in /var/iptablequeue/post_queue or
>> /var/iptablequeue/pre_queue now? Should I try sending packets through the
>> bridge to generate something?
>
> uh--no.  those rules might not even load.  "--log-prefix" specifies a
> string to prefix the log entries in your syslog files.  my rules were
> literal:
>
> /usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix "PRE QUEUE: "
>
> ...
>
> /usr/local/sbin/iptables -A FORWARD -j LOG --log-prefix "POST QUEUE: "
>
> so the entries in /var/log/messages will have the strings "PRE QUEUE: "
> and "POST QUEUE: " in them for identification purposes.
>
> -j
>
> --
> "Kids, you tried your best and you failed miserably. The lesson is,
> never try."
>        --The Simpsons
>
> 

RE: transparent bridge troubles?

[Daniel Chemko]

mdpeters wrote:
> Du'oh!
> 
> I changed it and this is what I see so far. I'm running a Nessus scan
> on one side of the bridge and the target system is at the other side
> of the bridge. 
> 
> PRE QUEUEIN=safetynet0 OUT=safetynet0 PHYSIN=eth2 PHYSOUT=eth1
> SRC=68.16.185.132 DST=68.16.185.130 LEN=41 TOS=0x00 PREC=0x00 TTL=64
> ID=3072 PROTO=TCP SPT=3133 DPT=45495 WINDOW=2048 RES=0x00 ACK URGP=0
> 
> POST QUEUEIN=safetynet0 OUT=safetynet0 PHYSIN=eth2 PHYSOUT=eth1
> SRC=68.16.185.132 DST=68.16.185.130 LEN=41 TOS=0x00 PREC=0x00 TTL=64
> ID=3072 PROTO=TCP SPT=3133 DPT=45495 WINDOW=2048 RES=0x00 ACK URGP=0

Ok, since there was no return traffic, I'm assuming that the destination
host doesn't know the firewall's in between the two PC's. In
68.16.185.130's arp table, does it have 68.16.185.132 mapped to your
firewall's eth1 interface? Is proxyARPing setup on both firewall
interfaces? This is leaving my knowledge realm, so if someone else can
help..

Re: transparent bridge troubles?

[mdpeters]

Both host and target have no information about the bridge | firewall in the 
middle.


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


mdpeters wrote:
> Du'oh!
>
> I changed it and this is what I see so far. I'm running a Nessus scan
> on one side of the bridge and the target system is at the other side
> of the bridge.
>
> PRE QUEUEIN=safetynet0 OUT=safetynet0 PHYSIN=eth2 PHYSOUT=eth1
> SRC=68.16.185.132 DST=68.16.185.130 LEN=41 TOS=0x00 PREC=0x00 TTL=64
> ID=3072 PROTO=TCP SPT=3133 DPT=45495 WINDOW=2048 RES=0x00 ACK URGP=0
>
> POST QUEUEIN=safetynet0 OUT=safetynet0 PHYSIN=eth2 PHYSOUT=eth1
> SRC=68.16.185.132 DST=68.16.185.130 LEN=41 TOS=0x00 PREC=0x00 TTL=64
> ID=3072 PROTO=TCP SPT=3133 DPT=45495 WINDOW=2048 RES=0x00 ACK URGP=0

Ok, since there was no return traffic, I'm assuming that the destination
host doesn't know the firewall's in between the two PC's. In
68.16.185.130's arp table, does it have 68.16.185.132 mapped to your
firewall's eth1 interface? Is proxyARPing setup on both firewall
interfaces? This is leaving my knowledge realm, so if someone else can
help..

Re: transparent bridge troubles?

[Jason Opperisano]

On Fri, Jan 07, 2005 at 05:01:47PM -0500, mdpeters wrote:
> Both host and target have no information about the bridge | firewall in the 
> middle.

the arp caches of hosts on either side of the firewall should have
entries for hosts on the other side though.  try and ping from a host
on one side of the firewall to a host on the other side of the firewall.
after the ping, type "arp -an" on the host you pinged from; if you don't
have an entry for the host you pinged--you have a bridge problem.  if
you do have an arp entry, but the ping didn't work--you have a firewall
problem.

-j 

--
"English - Who needs that? I'm never going to England!"
        --The Simpsons

Re: transparent bridge troubles?

[mdpeters]

Well I did this and I guess I have a firewall problem which I guess is the 
good news and the right user group.


----- Original Message ----- 
From: "Jason Opperisano" <opie@817west.com>
To: <netfilter@lists.netfilter.org>
Sent: Friday, January 07, 2005 5:18 PM
Subject: Re: transparent bridge troubles?


> On Fri, Jan 07, 2005 at 05:01:47PM -0500, mdpeters wrote:
>> Both host and target have no information about the bridge | firewall in 
>> the
>> middle.
>
> the arp caches of hosts on either side of the firewall should have
> entries for hosts on the other side though.  try and ping from a host
> on one side of the firewall to a host on the other side of the firewall.
> after the ping, type "arp -an" on the host you pinged from; if you don't
> have an entry for the host you pinged--you have a bridge problem.  if
> you do have an arp entry, but the ping didn't work--you have a firewall
> problem.
>
> -j
>
> --
> "English - Who needs that? I'm never going to England!"
>        --The Simpsons
>
> 

Re: transparent bridge troubles?

[Jason Opperisano]

On Fri, 2005-01-07 at 19:40, mdpeters wrote:
> Well I did this and I guess I have a firewall problem which I guess is the 
> good news and the right user group.

good--we're narrowing things down.  now--do we have a firewall problem,
or a snort-inline problem?

can you humor me, and change all your "-j QUEUE" to "-j ACCEPT" and see
if that makes any difference?

-j

--
"I bet Einstein turned himself all sorts of colors before he invented
 the light bulb."
	--The Simpsons

Re: transparent bridge troubles?

[mdpeters]

Yes it did. Packets are flowing through with ACCEPT. So it is a problem with 
QUEUE or something wrong with Snort-inline right?

Snort-inline runs, and logs packets coming into the box but obviously the 
packets are not making it through.

----- Original Message ----- 
From: "Jason Opperisano" <opie@817west.com>
To: <netfilter@lists.netfilter.org>
Sent: Friday, January 07, 2005 9:00 PM
Subject: Re: transparent bridge troubles?


> On Fri, 2005-01-07 at 19:40, mdpeters wrote:
>> Well I did this and I guess I have a firewall problem which I guess is 
>> the
>> good news and the right user group.
>
> good--we're narrowing things down.  now--do we have a firewall problem,
> or a snort-inline problem?
>
> can you humor me, and change all your "-j QUEUE" to "-j ACCEPT" and see
> if that makes any difference?
>
> -j
>
> --
> "I bet Einstein turned himself all sorts of colors before he invented
> the light bulb."
> --The Simpsons
>
>
> 

Re: transparent bridge troubles?

[Jason Opperisano]

On Fri, 2005-01-07 at 22:53, mdpeters wrote:
> Yes it did. Packets are flowing through with ACCEPT. So it is a problem with 
> QUEUE or something wrong with Snort-inline right?
> 
> Snort-inline runs, and logs packets coming into the box but obviously the 
> packets are not making it through.

since snort-inline is seeing the packets--i would say that the QUEUE
part is working.  the fact the the packets don't make it out of the box
would point the finger towards a snort-inline problem.

unfortunately--i don't know a thing about snort-inline; so i'm not of
much use anymore.

-j

--
"Call this an unfair generalization if you must, but old people are
 no good at everything."
	--The Simpsons

Re: transparent bridge troubles?

[mdpeters]

You have been a tremendous help. Thank you for helping me eliminate part of 
the mystery.

----- Original Message ----- 
From: "Jason Opperisano" <opie@817west.com>
To: <netfilter@lists.netfilter.org>
Sent: Friday, January 07, 2005 11:15 PM
Subject: Re: transparent bridge troubles?


> On Fri, 2005-01-07 at 22:53, mdpeters wrote:
>> Yes it did. Packets are flowing through with ACCEPT. So it is a problem 
>> with
>> QUEUE or something wrong with Snort-inline right?
>>
>> Snort-inline runs, and logs packets coming into the box but obviously the
>> packets are not making it through.
>
> since snort-inline is seeing the packets--i would say that the QUEUE
> part is working.  the fact the the packets don't make it out of the box
> would point the finger towards a snort-inline problem.
>
> unfortunately--i don't know a thing about snort-inline; so i'm not of
> much use anymore.
>
> -j
>
> --
> "Call this an unfair generalization if you must, but old people are
> no good at everything."
> --The Simpsons
>
>
> 

RE: transparent bridge troubles?

[Daniel Chemko]

> 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.

Re: transparent bridge troubles?

[mdpeters]

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.

transparent bridge troubles?

[mdpeters]

Here is the output you requested:

#/usr/local/sbin/iptables -vnxL

Chain INPUT (policy ACCEPT 1177615 packets, 73906075 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 QUEUE      tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
       0        0 QUEUE      udp  --  *      *       0.0.0.0/0            0.0.0.0/0
       0        0 QUEUE      icmp --  *      *       0.0.0.0/0            0.0.0.0/0

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

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?

Best regards,

Michael

transparent bridge troubles?

[mdpeters]

I am trying to set up a transparent bridge between two interfaces. I believe that my bridge is working but all I can see going through the box is APR packets. I have been told by the folks on the bridge list that it is probably my IPTABLES but I am pretty green with it. This is what I know for sure:

Kernel Linux-2.6.5-1.358, Fedora Core 2.

#/sbin/lsmod
Module                  Size  Used by
ipt_state               5504  2
ip_conntrack           30348  1 ipt_state
ipv6                  214624  16
iptable_filter          6016  1
ip_tables              18048  2 ipt_state,iptable_filter
bridge                 32024  0
ip_queue               11672  0
autofs4                15488  0
sunrpc                110280  1
e1000                  73356  0
e100                   30852  0
mii                     7552  1 e100
sg                     32288  0
microcode              10400  0
dm_mod                 37536  0
button                  8472  0
battery                10892  0
asus_acpi              12440  0
ac                      7308  0
ext3                  108136  2
jbd                    50328  1 ext3
ata_piix                9348  3
libata                 33536  1 ata_piix,[permanent]
sd_mod                 20352  4
scsi_mod               97224  3 sg,libata,sd_mod

++++++++++++++++++++++++++++++++++++++++

This is my bridge setup:

/sbin/modprobe ip_queue
/sbin/ifconfig eth1 0.0.0.0
/sbin/ifconfig eth2 0.0.0.0
/usr/local/sbin/brctl addbr br0
/usr/local/sbin/brctl addif br0 eth1
/usr/local/sbin/brctl addif br0 eth2
/sbin/ifconfig br0 up
/usr/local/sbin/brctl stp br0 off
/sbin/ifconfig br0 0.0.0.0 -arp

++++++++++++++++++++++++++++++++++++++++

This is what my iptables setup looks like.

/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

#/usr/local/sbin/iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination
QUEUE      all  --  anywhere             anywhere
QUEUE      tcp  --  anywhere             anywhere            tcp
flags:SYN,RST,ACK/SYN state NEW
QUEUE      tcp  --  anywhere             anywhere            state
RELATED,ESTABLISHED
QUEUE      udp  --  anywhere             anywhere
QUEUE      icmp --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

++++++++++++++++++++++++++++++++++++++++

# /sbin/ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:11:11:50:EE:D2
          inet addr:172.16.200.211  Bcast:172.16.255.255  Mask:255.255.0.0
          inet6 addr: fe80::211:11ff:fe50:eed2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:77160 errors:5 dropped:0 overruns:0 frame:5
          TX packets:38287 errors:0 dropped:0 overruns:0 carrier:3
          collisions:2126 txqueuelen:1000
          RX bytes:7950909 (7.5 Mb)  TX bytes:14485654 (13.8 Mb)

eth1      Link encap:Ethernet  HWaddr 00:04:23:AD:ED:BA
          inet6 addr: fe80::204:23ff:fead:edba/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:413 errors:0 dropped:0 overruns:0 frame:0
          TX packets:673 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:31654 (30.9 Kb)  TX bytes:71099 (69.4 Kb)
          Base address:0xc800 Memory:ff8c0000-ff8e0000

eth2      Link encap:Ethernet  HWaddr 00:04:23:AD:ED:BB
          inet6 addr: fe80::204:23ff:fead:edbb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10067 errors:0 dropped:0 overruns:0 frame:0
          TX packets:190 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:741428 (724.0 Kb)  TX bytes:16514 (16.1 Kb)
          Base address:0xcc00 Memory:ff8e0000-ff900000

eth3      Link encap:Ethernet  HWaddr 00:04:23:AD:ED:D6
          inet6 addr: fe80::204:23ff:fead:edd6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:398 (398.0 b)
          Base address:0xc000 Memory:ff780000-ff7a0000

eth4      Link encap:Ethernet  HWaddr 00:04:23:AD:ED:D7
          inet6 addr: fe80::204:23ff:fead:edd7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1429283 errors:1835 dropped:0 overruns:0 frame:1835
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:307722248 (293.4 Mb)  TX bytes:398 (398.0 b)
          Base address:0xc400 Memory:ff7a0000-ff7c0000

eth5      Link encap:Ethernet  HWaddr 00:04:23:AD:ED:A8
          inet6 addr: fe80::204:23ff:fead:eda8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:164 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:11008 (10.7 Kb)  TX bytes:398 (398.0 b)
          Base address:0xb800 Memory:ff640000-ff660000

eth6      Link encap:Ethernet  HWaddr 00:04:23:AD:ED:A9
          inet6 addr: fe80::204:23ff:fead:eda9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9078 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:898198 (877.1 Kb)  TX bytes:398 (398.0 b)
          Base address:0xbc00 Memory:ff660000-ff680000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:107 errors:0 dropped:0 overruns:0 frame:0
          TX packets:107 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:14503 (14.1 Kb)  TX bytes:14503 (14.1 Kb)

br0      Link encap:Ethernet  HWaddr 00:04:23:AD:ED:BA
          inet6 addr: fe80::204:23ff:fead:edba/64 Scope:Link
          UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:9861 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:506916 (495.0 Kb)  TX bytes:210 (210.0 b)

sit0      Link encap:IPv6-in-IPv4
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

++++++++++++++++++++++++++++++++++++++++

Am I missing something? I appreciate tremendously your help.

Best regards,

Michael

Re: transparent bridge troubles?

[Jason Opperisano]

On Fri, Jan 07, 2005 at 01:53:48PM -0500, mdpeters wrote:
> This is what my iptables setup looks like.
> 
> /usr/local/sbin/iptables -P FORWARD DROP

k--so all packets traversing FORWARD that don't match one of the
following rules will get dropped.

> /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

and all we've done is QUEUE packets.

> #/usr/local/sbin/iptables -L

please use "iptables -vnxL" in the future when posting output.

> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination
> 
> Chain FORWARD (policy DROP)
> target     prot opt source               destination
> QUEUE      all  --  anywhere             anywhere
> QUEUE      tcp  --  anywhere             anywhere            tcp
> flags:SYN,RST,ACK/SYN state NEW
> QUEUE      tcp  --  anywhere             anywhere            state
> RELATED,ESTABLISHED
> QUEUE      udp  --  anywhere             anywhere
> QUEUE      icmp --  anywhere             anywhere
> 
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination

well--you're queuing all your packets to a userspace daemon--what are
you doing with them when they get there?

-j

--
"To alcohol: the cause of, and solution to, all of life's problems."
        --The Simpsons

Re: transparent bridge troubles?

[Jason Opperisano]

On Fri, Jan 07, 2005 at 01:53:48PM -0500, mdpeters wrote:
> This is my bridge setup:
> 
> /sbin/modprobe ip_queue
> /sbin/ifconfig eth1 0.0.0.0
> /sbin/ifconfig eth2 0.0.0.0
> /usr/local/sbin/brctl addbr br0
> /usr/local/sbin/brctl addif br0 eth1
> /usr/local/sbin/brctl addif br0 eth2
> /sbin/ifconfig br0 up
> /usr/local/sbin/brctl stp br0 off
> /sbin/ifconfig br0 0.0.0.0 -arp

i'm a little rusty on my linux bridging commands--but why did you
execute that last command?  the "ifconfig br0 0.0.0.0 -arp" one.  it
seems like that would block arp traffic from traversing the bridge, but
i could be mistaken...

-j

--
"I bet Einstein turned himself all sorts of colors before he invented
 the light bulb."
        --The Simpsons

Re: transparent bridge troubles?

[mdpeters]

[-]arp Enable or disable the use of the ARP protocol on this interface.

I was told to do that by the Snort folks but maybe .... not?

----- Original Message ----- 
From: "Jason Opperisano" <opie@817west.com>
To: <netfilter@lists.netfilter.org>
Sent: Friday, January 07, 2005 4:53 PM
Subject: Re: transparent bridge troubles?


> On Fri, Jan 07, 2005 at 01:53:48PM -0500, mdpeters wrote:
>> This is my bridge setup:
>> 
>> /sbin/modprobe ip_queue
>> /sbin/ifconfig eth1 0.0.0.0
>> /sbin/ifconfig eth2 0.0.0.0
>> /usr/local/sbin/brctl addbr br0
>> /usr/local/sbin/brctl addif br0 eth1
>> /usr/local/sbin/brctl addif br0 eth2
>> /sbin/ifconfig br0 up
>> /usr/local/sbin/brctl stp br0 off
>> /sbin/ifconfig br0 0.0.0.0 -arp
> 
> i'm a little rusty on my linux bridging commands--but why did you
> execute that last command?  the "ifconfig br0 0.0.0.0 -arp" one.  it
> seems like that would block arp traffic from traversing the bridge, but
> i could be mistaken...
> 
> -j
> 
> --
> "I bet Einstein turned himself all sorts of colors before he invented
> the light bulb."
>        --The Simpsons
> 
>