* transparent bridge troubles?
@ 2005-01-07 18:53 mdpeters
2005-01-07 19:44 ` Jason Opperisano
2005-01-07 21:53 ` Jason Opperisano
0 siblings, 2 replies; 21+ messages in thread
From: mdpeters @ 2005-01-07 18:53 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
2005-01-07 18:53 transparent bridge troubles? mdpeters
@ 2005-01-07 19:44 ` Jason Opperisano
2005-01-07 21:53 ` Jason Opperisano
1 sibling, 0 replies; 21+ messages in thread
From: Jason Opperisano @ 2005-01-07 19:44 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
2005-01-07 18:53 transparent bridge troubles? mdpeters
2005-01-07 19:44 ` Jason Opperisano
@ 2005-01-07 21:53 ` Jason Opperisano
2005-01-07 22:02 ` mdpeters
1 sibling, 1 reply; 21+ messages in thread
From: Jason Opperisano @ 2005-01-07 21:53 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
2005-01-07 21:53 ` Jason Opperisano
@ 2005-01-07 22:02 ` mdpeters
0 siblings, 0 replies; 21+ messages in thread
From: mdpeters @ 2005-01-07 22:02 UTC (permalink / raw)
To: Jason Opperisano, netfilter
[-]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
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
2005-01-08 4:15 ` Jason Opperisano
@ 2005-01-08 12:12 ` mdpeters
0 siblings, 0 replies; 21+ messages in thread
From: mdpeters @ 2005-01-08 12:12 UTC (permalink / raw)
To: Jason Opperisano, netfilter
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
>
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
2005-01-08 3:53 ` mdpeters
@ 2005-01-08 4:15 ` Jason Opperisano
2005-01-08 12:12 ` mdpeters
0 siblings, 1 reply; 21+ messages in thread
From: Jason Opperisano @ 2005-01-08 4:15 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
2005-01-08 2:00 ` Jason Opperisano
@ 2005-01-08 3:53 ` mdpeters
2005-01-08 4:15 ` Jason Opperisano
0 siblings, 1 reply; 21+ messages in thread
From: mdpeters @ 2005-01-08 3:53 UTC (permalink / raw)
To: Jason Opperisano, netfilter
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
>
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
2005-01-08 0:40 ` mdpeters
@ 2005-01-08 2:00 ` Jason Opperisano
2005-01-08 3:53 ` mdpeters
0 siblings, 1 reply; 21+ messages in thread
From: Jason Opperisano @ 2005-01-08 2:00 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
2005-01-07 22:18 ` Jason Opperisano
@ 2005-01-08 0:40 ` mdpeters
2005-01-08 2:00 ` Jason Opperisano
0 siblings, 1 reply; 21+ messages in thread
From: mdpeters @ 2005-01-08 0:40 UTC (permalink / raw)
To: Jason Opperisano, netfilter
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
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
2005-01-07 22:01 ` mdpeters
@ 2005-01-07 22:18 ` Jason Opperisano
2005-01-08 0:40 ` mdpeters
0 siblings, 1 reply; 21+ messages in thread
From: Jason Opperisano @ 2005-01-07 22:18 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
2005-01-07 21:38 Daniel Chemko
@ 2005-01-07 22:01 ` mdpeters
2005-01-07 22:18 ` Jason Opperisano
0 siblings, 1 reply; 21+ messages in thread
From: mdpeters @ 2005-01-07 22:01 UTC (permalink / raw)
To: Daniel Chemko, Jason Opperisano, netfilter
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..
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: transparent bridge troubles?
@ 2005-01-07 21:38 Daniel Chemko
2005-01-07 22:01 ` mdpeters
0 siblings, 1 reply; 21+ messages in thread
From: Daniel Chemko @ 2005-01-07 21:38 UTC (permalink / raw)
To: mdpeters, Jason Opperisano, netfilter
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..
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
2005-01-07 21:01 ` Jason Opperisano
2005-01-07 21:16 ` mdpeters
@ 2005-01-07 21:35 ` mdpeters
1 sibling, 0 replies; 21+ messages in thread
From: mdpeters @ 2005-01-07 21:35 UTC (permalink / raw)
To: Jason Opperisano, netfilter
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
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
2005-01-07 21:01 ` Jason Opperisano
@ 2005-01-07 21:16 ` mdpeters
2005-01-07 21:35 ` mdpeters
1 sibling, 0 replies; 21+ messages in thread
From: mdpeters @ 2005-01-07 21:16 UTC (permalink / raw)
To: Jason Opperisano, netfilter
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
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
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
0 siblings, 2 replies; 21+ messages in thread
From: Jason Opperisano @ 2005-01-07 21:01 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
2005-01-07 20:44 ` Jason Opperisano
@ 2005-01-07 20:55 ` mdpeters
2005-01-07 21:01 ` Jason Opperisano
0 siblings, 1 reply; 21+ messages in thread
From: mdpeters @ 2005-01-07 20:55 UTC (permalink / raw)
To: Jason Opperisano, netfilter
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
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
2005-01-07 20:42 Daniel Chemko
@ 2005-01-07 20:44 ` Jason Opperisano
2005-01-07 20:55 ` mdpeters
0 siblings, 1 reply; 21+ messages in thread
From: Jason Opperisano @ 2005-01-07 20:44 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: transparent bridge troubles?
@ 2005-01-07 20:42 Daniel Chemko
2005-01-07 20:44 ` Jason Opperisano
0 siblings, 1 reply; 21+ messages in thread
From: Daniel Chemko @ 2005-01-07 20:42 UTC (permalink / raw)
To: mdpeters, netfilter
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: transparent bridge troubles?
2005-01-07 20:24 Daniel Chemko
@ 2005-01-07 20:36 ` mdpeters
0 siblings, 0 replies; 21+ messages in thread
From: mdpeters @ 2005-01-07 20:36 UTC (permalink / raw)
To: Daniel Chemko, netfilter
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: transparent bridge troubles?
@ 2005-01-07 20:24 Daniel Chemko
2005-01-07 20:36 ` mdpeters
0 siblings, 1 reply; 21+ messages in thread
From: Daniel Chemko @ 2005-01-07 20:24 UTC (permalink / raw)
To: mdpeters, netfilter
> 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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* transparent bridge troubles?
@ 2005-01-07 20:14 mdpeters
0 siblings, 0 replies; 21+ messages in thread
From: mdpeters @ 2005-01-07 20:14 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2005-01-08 12:12 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-07 18:53 transparent bridge troubles? mdpeters
2005-01-07 19:44 ` Jason Opperisano
2005-01-07 21:53 ` Jason Opperisano
2005-01-07 22:02 ` mdpeters
2005-01-07 20:14 mdpeters
2005-01-07 20:24 Daniel Chemko
2005-01-07 20:36 ` 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 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
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.