From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jay Levitt Subject: Interaction of Ethereal and iptables? Date: Sun, 11 Apr 2004 01:38:24 -0400 Sender: netfilter-admin@lists.netfilter.org Message-ID: <065601c41f87$34f209e0$9701a8c0@office> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0653_01C41F65.ADCFC810" Return-path: Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: To: netfilter@lists.netfilter.org This is a multi-part message in MIME format. ------=_NextPart_000_0653_01C41F65.ADCFC810 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm occasionally seeing lines like the following, always to the same = machine which is on my internal network: Apr 11 01:11:52 linux kernel: Rejected output by default:IN=3D = OUT=3Deth0 SRC=3D192.168.1.150 DST=3D192.168.1.151 LEN=3D40 TOS=3D0x00 = PREC=3D0x00 TTL=3D64 ID=3D30662 DF PROTO=3DTCP SPT=3D993 DPT=3D3736 = WINDOW=3D6432 RES=3D0x00 ACK FIN URGP=3D0=20 This corresponds to a LOG and then a DROP rule. So I set up Ethereal to = capture the packet trace. I didn't see the packet there, so I changed = the DROP to an ACCEPT, assuming that iptables is probably dropping the = outbound packet before Ethereal (ok, libpcap) can see it. =20 The weird thing is - even with just a LOG/ACCEPT rule, the packet is = STILL missing from Ethereal's trace! All other packets from that time = frame are there, but this particular one isn't. Could iptables be = imagining it somehow? I'm using libpcap 0.7.2, which was current till a = few days ago... I've done an iptables --list OUTPUT and verified that = the last item on the OUTPUT chain is an ACCEPT of all packets, although = the default policy is still technically DROP. Any clues? Jay Levitt ------=_NextPart_000_0653_01C41F65.ADCFC810 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm occasionally seeing lines like the = following,=20 always to the same machine which is on my internal network:
 
Apr 11 01:11:52 linux kernel: Rejected = output by=20 default:IN=3D OUT=3Deth0 SRC=3D192.168.1.150 DST=3D192.168.1.151 = LEN=3D40 TOS=3D0x00=20 PREC=3D0x00 TTL=3D64 ID=3D30662 DF PROTO=3DTCP SPT=3D993 DPT=3D3736 = WINDOW=3D6432 RES=3D0x00 ACK=20 FIN URGP=3D0
 
This corresponds to a LOG and then a = DROP=20 rule.  So I set up Ethereal to = capture the=20 packet trace.  I didn't see the packet there, so I changed the DROP = to an=20 ACCEPT, assuming that iptables is probably dropping the outbound packet = before=20 Ethereal (ok, libpcap) can see it. 
 
The weird thing is - even with just a = LOG/ACCEPT=20 rule, the packet is STILL missing from Ethereal's trace!  All other = packets=20 from that time frame are there, but this particular one isn't.  = Could=20 iptables be imagining it somehow?  I'm using libpcap 0.7.2, which = was=20 current till a few days ago...  I've done an iptables --list OUTPUT = and=20 verified that the last item on the OUTPUT chain is an ACCEPT of all = packets,=20 although the default policy is still technically DROP.
 
Any clues?
 
Jay Levitt
 
 
------=_NextPart_000_0653_01C41F65.ADCFC810-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "John A. Sullivan III" Subject: Re: Interaction of Ethereal and iptables? Date: Mon, 12 Apr 2004 07:55:58 -0400 Sender: netfilter-admin@lists.netfilter.org Message-ID: <1081770958.16832.3.camel@localhost> References: <065601c41f87$34f209e0$9701a8c0@office> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <065601c41f87$34f209e0$9701a8c0@office> Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: Jay Levitt Cc: netfilter@lists.netfilter.org On Sun, 2004-04-11 at 01:38, Jay Levitt wrote: > I'm occasionally seeing lines like the following, always to the same > machine which is on my internal network: > > Apr 11 01:11:52 linux kernel: Rejected output by default:IN= OUT=eth0 > SRC=192.168.1.150 DST=192.168.1.151 LEN=40 TOS=0x00 PREC=0x00 TTL=64 > ID=30662 DF PROTO=TCP SPT=993 DPT=3736 WINDOW=6432 RES=0x00 ACK FIN > URGP=0 > > This corresponds to a LOG and then a DROP rule. So I set up Ethereal > to capture the packet trace. I didn't see the packet there, so I > changed the DROP to an ACCEPT, assuming that iptables is probably > dropping the outbound packet before Ethereal (ok, libpcap) can see > it. > > The weird thing is - even with just a LOG/ACCEPT rule, the packet is > STILL missing from Ethereal's trace! All other packets from that time > frame are there, but this particular one isn't. Could iptables be > imagining it somehow? I'm using libpcap 0.7.2, which was current till > a few days ago... I've done an iptables --list OUTPUT and verified > that the last item on the OUTPUT chain is an ACCEPT of all packets, > although the default policy is still technically DROP. Is there any chance it is being dropped by some other rule before it hits the accept rule? If you add a log rule just in front of the ACCEPT rule, is the packet still logged? -- John A. Sullivan III Chief Technology Officer Nexus Management +1 207-985-7880 john.sullivan@nexusmgmt.com --- If you are interested in helping to develop a GPL enterprise class VPN/Firewall/Security device management console, please visit http://iscs.sourceforge.net From mboxrd@z Thu Jan 1 00:00:00 1970 From: Unknown Subject: Re: Interaction of Ethereal and iptables? Date: Mon, 12 Apr 2004 08:46:09 -0400 Sender: netfilter-admin@lists.netfilter.org Message-ID: <7000.79349703646$1081775642@news.gmane.org> References: <065601c41f87$34f209e0$9701a8c0@office> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: From: Alistair Tonner <> In-Reply-To: <065601c41f87$34f209e0$9701a8c0@office> Content-Disposition: inline Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: Jay Levitt , netfilter@lists.netfilter.org On April 11, 2004 01:38 am, Jay Levitt wrote: > I'm occasionally seeing lines like the following, always to the same > machine which is on my internal network: > > Apr 11 01:11:52 linux kernel: Rejected output by default:IN= OUT=eth0 > SRC=192.168.1.150 DST=192.168.1.151 LEN=40 TOS=0x00 PREC=0x00 TTL=64 > ID=30662 DF PROTO=TCP SPT=993 DPT=3736 WINDOW=6432 RES=0x00 ACK FIN URGP=0 > > This corresponds to a LOG and then a DROP rule. So I set up Ethereal to > capture the packet trace. I didn't see the packet there, so I changed the > DROP to an ACCEPT, assuming that iptables is probably dropping the outbound > packet before Ethereal (ok, libpcap) can see it. > > The weird thing is - even with just a LOG/ACCEPT rule, the packet is STILL > missing from Ethereal's trace! All other packets from that time frame are > there, but this particular one isn't. Could iptables be imagining it > somehow? I'm using libpcap 0.7.2, which was current till a few days ago... > I've done an iptables --list OUTPUT and verified that the last item on the > OUTPUT chain is an ACCEPT of all packets, although the default policy is > still technically DROP. Umm == This packet appears to be outbound from your system ... What service do you have running at port 993? (by default is IMAP + SSL) --> what do your IMAP server logs show? Are you monitoring *all* traffic on *all* interfaces with ethereal? -- is eth0 your LAN interface or your INET interface? -- when I last used ethereal (admittedly the GUI) I was in a siimilar situation when I noted that the missing data was actually on a different interface than I was first looking at. --- Also -- are you accepting at the end of the OUTPUT? -- where else are there drop rules in the OUTPUT chain? Are they catching this guy? Try setting up a LOG rule to catch this packet at the top, and bottom of OUTPUT and slowly move the LOG packet from bottom up to see where it shows up ... then you will know which rule is dropping the packet. If iptables is dropping the packet on a connection out from the box -- (someone correct me if I'm wrong) it WONT make it OUT the interface in question, thus will not appear on the wire, thus not making an appearance to ethereal (ducks the logic arrows) Alistair Tonner > > Any clues? > > Jay Levitt