* tcpdump and iptables .. [not found] <FD1B6DC5FFF43C4888DCC155FE8C1FFEBC0EB5@7xch10ka.sevenspace.local> @ 2004-03-06 15:59 ` Mussie Gebregziabiher 2004-03-06 16:16 ` John A. Sullivan III 0 siblings, 1 reply; 5+ messages in thread From: Mussie Gebregziabiher @ 2004-03-06 15:59 UTC (permalink / raw) To: netfilter Dear All, When I run tcpdump I seem to be getting data after it is being processed by iptables. Can someone tell me where 'tcpdump' resides in the order of priority? Have the packets I'm seeing been subjected to 'PREROUTING' rules such as 'MANGLE' and 'NAT'? Thanks in advance. Mussie G. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tcpdump and iptables .. 2004-03-06 15:59 ` tcpdump and iptables Mussie Gebregziabiher @ 2004-03-06 16:16 ` John A. Sullivan III 2004-03-06 18:12 ` Antony Stone 0 siblings, 1 reply; 5+ messages in thread From: John A. Sullivan III @ 2004-03-06 16:16 UTC (permalink / raw) To: Mussie Gebregziabiher; +Cc: netfilter On Sat, 2004-03-06 at 10:59, Mussie Gebregziabiher wrote: > Dear All, > > When I run tcpdump I seem to be getting data after it is being processed by > iptables. Can someone tell me where 'tcpdump' resides in the order of > priority? Have the packets I'm seeing been subjected to 'PREROUTING' rules > such as 'MANGLE' and 'NAT'? <snip> I'll relate my experiences trying to trace the interchange between iptables and openswan but it is only from observation. If someone who knows the code responds, please take their word for it over mine. I believe you will see the packet on the inbound interface before it hits the PREROUTING chain of the mangle table. You will see it on the outbound interface after it has passed through POSTROUTING (I don't recall off the top of my head if nat or mangle is last. If there is a hand-off to another interface during packet processing, you will see it again in tcpdump on the new interfaces again, pre-PREROUTING and then post-POSTROUTING. -- John A. Sullivan III Chief Technology Officer Nexus Management +1 207-985-7880 john.sullivan@nexusmgmt.com ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tcpdump and iptables .. 2004-03-06 16:16 ` John A. Sullivan III @ 2004-03-06 18:12 ` Antony Stone 2004-03-06 18:46 ` Cedric Blancher 0 siblings, 1 reply; 5+ messages in thread From: Antony Stone @ 2004-03-06 18:12 UTC (permalink / raw) To: netfilter On Saturday 06 March 2004 4:16 pm, John A. Sullivan III wrote: > On Sat, 2004-03-06 at 10:59, Mussie Gebregziabiher wrote: > > Dear All, > > > > When I run tcpdump I seem to be getting data after it is being processed > > by iptables. Can someone tell me where 'tcpdump' resides in the order > > of priority? Have the packets I'm seeing been subjected to 'PREROUTING' > > rules such as 'MANGLE' and 'NAT'? > > I'll relate my experiences trying to trace the interchange between > iptables and openswan but it is only from observation. If someone who > knows the code responds, please take their word for it over mine. > > I believe you will see the packet on the inbound interface before it > hits the PREROUTING chain of the mangle table. You will see it on the > outbound interface after it has passed through POSTROUTING (I don't > recall off the top of my head if nat or mangle is last). I agree with John here (with the same disclaimer - if someone who knows the code thinks otherwise - believe them, not me). If you think about the information you can see with tcpdump (or other packet sniffers which work at the same level such as ethereal), there's a lot more low-level stuff than netfilter knows about - tcpdump sees ethernet frames, IPX and similar traffic which are not even IP based, as well as completely different media types such as 802.11b headers. All this gets stripped off before reaching netfilter (with the exception of MAC addresses, but even there, netfilter can't tell whether a packet arrived by ethernet or 802.11). Therefore tcpdump works at a much lower level, before netfilter on the input side, and after it on the output side. Regards, Antony. -- "Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns - the ones we don't know we don't know." - Donald Rumsfeld, US Secretary of Defence Please reply to the list; please don't CC me. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tcpdump and iptables .. 2004-03-06 18:12 ` Antony Stone @ 2004-03-06 18:46 ` Cedric Blancher 2004-03-06 23:44 ` Antony Stone 0 siblings, 1 reply; 5+ messages in thread From: Cedric Blancher @ 2004-03-06 18:46 UTC (permalink / raw) To: Antony Stone; +Cc: netfilter Le sam 06/03/2004 à 19:12, Antony Stone a écrit : > tcpdump sees ethernet frames, > IPX and similar traffic which are not even IP based, as well as completely > different media types such as 802.11b headers. All this gets stripped off > before reaching netfilter (with the exception of MAC addresses, but even > there, netfilter can't tell whether a packet arrived by ethernet or 802.11). Just a notice about 802.11 stuff. The way tcpdump will see traffic coming from a wireless link depends on the wifi interface state. If the interface is in normal operation mode (managed, ad-hoc or master), it will see frames as usual ethernet ones, just as it was sniffing a wired link. If the interface is in monitor mode, then it will see the frames will full 802.11 header. BTW, I can confirm tcpdump will see outgoing traffic as it is after POSTROUTING chain, and incoming one as it is before PREROUTING. I've just checked playing with TTL on pings. -- http://www.netexit.com/~sid/ PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE >> Hi! I'm your friendly neighbourhood signature virus. >> Copy me to your signature file and help me spread! ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tcpdump and iptables .. 2004-03-06 18:46 ` Cedric Blancher @ 2004-03-06 23:44 ` Antony Stone 0 siblings, 0 replies; 5+ messages in thread From: Antony Stone @ 2004-03-06 23:44 UTC (permalink / raw) To: netfilter On Saturday 06 March 2004 6:46 pm, Cedric Blancher wrote: > Le sam 06/03/2004 à 19:12, Antony Stone a écrit : > > > tcpdump sees ethernet frames, > > IPX and similar traffic which are not even IP based, as well as > > completely different media types such as 802.11b headers. > > Just a notice about 802.11 stuff. > > The way tcpdump will see traffic coming from a wireless link depends on > the wifi interface state. If the interface is in normal operation mode > (managed, ad-hoc or master), it will see frames as usual ethernet ones, > just as it was sniffing a wired link. If the interface is in monitor > mode, then it will see the frames will full 802.11 header. True - I guess I'm just used to always doing my 802.11 sniffing in monitor mode, so I get the maximum information out of the exercise :) > BTW, I can confirm tcpdump will see outgoing traffic as it is after > POSTROUTING chain, and incoming one as it is before PREROUTING. I've > just checked playing with TTL on pings. Thanks. Antony. -- "Note: Windows 98, Windows 98SE and Windows 95 are not affected by [MS Blaster]. However, these products are no longer supported. Users of these products are strongly encouraged to upgrade to later versions." (which *are* affected by MS Blaster...) http://www.microsoft.com/security/security_bulletins/ms03-026.asp Please reply to the list; please don't CC me. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-03-06 23:44 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <FD1B6DC5FFF43C4888DCC155FE8C1FFEBC0EB5@7xch10ka.sevenspace.local>
2004-03-06 15:59 ` tcpdump and iptables Mussie Gebregziabiher
2004-03-06 16:16 ` John A. Sullivan III
2004-03-06 18:12 ` Antony Stone
2004-03-06 18:46 ` Cedric Blancher
2004-03-06 23:44 ` Antony Stone
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.