Thanks, Humberto. That certainly allows me to see what policy and rule is being applied. Thanks! If anyone is aware of a book or blog or something that explains the state stuff discussed above without ANY ambiguity at all, I'd love to read it! Oliver On Wed, Jan 3, 2018 at 9:34 AM, Humberto Jucá <betolj@xxxxxxxxx> wrote: > Hi, > > Try something like this: > iptables -t raw -I PREROUTING -p icmp -j TRACE > > After this, use the "tail -f" command in your syslog or messages file: > tail -f /va > > 2018-01-03 11:01 GMT-03:00 Oliver O'Boyle <oliver.oboyle@xxxxxxxxx>: >> All, >> >> Thanks for the replies, your help is much appreciated. >> >> Andre, the link you included in your last message is one of the ones >> I've been referencing and it'sm in the fact, the one that's causing >> the confusion. >> >> a) I agree that ICMP is a connectionless protocol and we would not >> normally expect to see an established two-way session with it, such as >> we would see with TCP. >> b) As per Neal's and Pascal's comments above, I agree that >> Netfilter/Conntrack impose a connected (or unconnected) state between >> two endpoints/streams which is what's seen in the output of 'sudo >> contrack -E'. >> >> But I'm still not getting the result I'm hoping to see. Maybe it's >> just not possible, though. I'll re-phrase what I'm looking for to see >> if there's a different avenue for answers: >> >> Referencing the following quote from the link Andre sent: 'When the >> firewall sees a request packet, it considers it as NEW. When the host >> sends a reply packet to the request it is considered ESTABLISHED.' >> >> I'd like to see which packets are considered 'ESTABLISHED'. Or, I'd >> like a clear confirmation that the connection stream these ESTABLISHED >> packets are part of is considered "approved/allowed" to pass. I don't >> care which tool I use to see these. If the approval I'm looking for is >> in the form of a missing statement (meaning that the >> packet/stream/connection is considered allowed/established because >> there is no statement that explicitly declares a >> packet/stream/connection as NOT allowed/established) then I can work >> with that too, I just need confirmation that this is the case. >> >> Thanks! >> Oliver >> >> >> >> On Wed, Jan 3, 2018 at 5:13 AM, André Paulsberg-Csibi (IBM Consultant) >> <Andre.Paulsberg-Csibi@xxxxxxxx> wrote: >>> I think here are some semantics confused ( could be my fault ). >>> >>> My statement is meant to explain that the term "ESTABLISHED" used in CONNTRACK , does not match the state "ESTABLISHED" used in iptables rules-set . >>> ESTABLISHED in iptables ruleset simply means there is an entry directly related to the packet that is being examined in the connection table . >>> >>> ESTABLISHED in the conntrack TERM is only used for TCP as here the packets have multiple timers as at least TCP is session/connection based protocol , >>> I am not aware of other protocols who have other times and multiple sets of session/connection states in netfilter/iptables/conntrack and using this TERM in same manner . >>> >>> RELATED is actually not the FIRST/NEW packet of new connection , it is any packet ( first second or later ) from any system that could be indirectly connected to any one connection table entry . >>> Including ICMP messages like type 11 ( TTL exceeded ) typically sent from every router on the way until you reached the end target destination when doing a traceroute . >>> >>> When conntrack deals with other none TCP it uses only UNREPLIED / ASSURED and not the term ESTABLISHED >>> And for ICMP it does not use ASSURED , only UNREPLIED ( which is removed after the first reply ) >>> >>> As far as I can tell there are 6 states for the connection table part ( 7 if you include those NOT/NEVER there ) >>> NEW >>> ESTABLISHED >>> RELATED >>> INVALID >>> UNTRACKED >>> CLOSED >>> >>> For me these semantics is also not so self explanatory , specially since the terms somewhat overlap and are missing for others . >>> ( but now maybe this is a bit more clear ) If not here is more details http://www.iptables.info/en/connection-state.html >>> >>> >>> Best regards >>> André Paulsberg-Csibi >>> Senior Network Engineer >>> IBM Services AS >>> >>> -----Original Message----- >>> From: netfilter-owner@xxxxxxxxxxxxxxx [mailto:netfilter-owner@xxxxxxxxxxxxxxx] On Behalf Of Neal P. Murphy >>> Sent: Wednesday, January 3, 2018 12:37 AM >>> Cc: netfilter@xxxxxxxxxxxxxxx >>> Subject: Re: conntrack and ICMP echo replies not showing as ESTABLISHED >>> >>> On Tue, 2 Jan 2018 21:56:07 +0000 >>> André Paulsberg-Csibi (IBM Consultant) <Andre.Paulsberg-Csibi@xxxxxxxx> wrote: >>> >>>> As far as I can tell - ESTABLISHED - is only for session based protocols like TCP . >>>> You will not see that for UDP or ICMP , as far as CONNTRACK is concerned . >>> >>> With netfilter, there are five connection states: NEW, RELATED, ESTABLISHED, INVALID and RAW. >>> - A NEW packet is the first packet of a new peer-to-peer communication connection >>> (a conn), be it TCP, SCTP, UDP, GRE, or any other protocol. >>> - A RELATED packet is the first packet of a new conn that netfilter determined is >>> related to an existing conn (the data conn of an FTP conn, for example). >>> - When two-way communication is established with a reply packet, the conn's state >>> changes to ESTABLISHED. >>> - INVALID packets are those that netfilter has received but has no idea what to do >>> with them; they are packets that can only belong to an ESTABLISHED conn but it can >>> find no such conn in its database. >>> - I think RAW packets are those that netfilter has been told not to process; but I'm >>> not sure of this as I've never had reason to use RAW packets. >>> >>> In netfilter, 'connection' is not related to connection-oriented protocols. It has to do with the relationship--the logical connection--between two endpoints on a LAN or on some internetwork of them. It is much like two people talking on a walkie-talkie, two people exchanging TXT MSGs, or two people talking on a phone that has a circuit-switched connection set up between them. >>> -- >>> To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger.kernel.org%2Fmajordomo-info.html&data=02%7C01%7C%7C8cd63c84f69240d4239308d5523e4c6d%7C40cc2915e2834a2794716bdd7ca4c6e1%7C1%7C0%7C636505349884829535&sdata=hwc8E8kipzNl9HDW3SWhZfc9w2WgFoOXHH43uV5ugNk%3D&reserved=0 >> >> >> >> -- >> :o@> >> -- >> To unsubscribe from this list: send the line "unsubscribe netfilter" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- :o@> -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
