Re: sendto: Operation not permitted

Re: sendto: Operation not permitted

[Antony Stone]

On Thursday 30 May 2002 3:13 pm, alex@pilosoft.com wrote:

> > This type of ICMP message will be RELATED to an existing TCP connection,
> > therefore it will be allowed through the firewall by the sort of rulset
> > Claudio was using - if you recall, this was:
>
> Ah, I didn't know iptables are smart enough to realize that!

Yes, this is one of the beautiful things about netfilter / iptables - ICMP 
packets are automatically recognised as being RELATED to the TCP packets 
which they're, well, related to.

That's almost a definition of the difference between ESTABLISHED and RELATED 
- ESTABLISHED packets are part of the ongoing TCP communication, whereas 
RELATED ones are things like ICMP messages which say something about the TCP 
link.

Great, isn't it !?


Antony.

Re: sendto: Operation not permitted

[Nick Drage]

On Thu, May 30, 2002 at 08:55:17PM +0100, Antony Stone wrote:
> On Thursday 30 May 2002 3:13 pm, alex@pilosoft.com wrote:

> > > This type of ICMP message will be RELATED to an existing TCP
> > > connection, therefore it will be allowed through the firewall by the
> > > sort of rulset Claudio was using - if you recall, this was:
> >
> > Ah, I didn't know iptables are smart enough to realize that!
> 
> Yes, this is one of the beautiful things about netfilter / iptables - ICMP 
> packets are automatically recognised as being RELATED to the TCP packets 
> which they're, well, related to.

How does netfilter determine if the ICMP packet is RELATED to anything in
the state table?  Anyone suggest documentation that details this?

-- 
FunkyJesus System Administration Team

RE: sendto: Operation not permitted

[Joe Patterson]

kind of the same way that a system determines what an ICMP message relates
to.  For example, the format of an ICMP unreachable message, which includes
such messages as the fragmentation needed and all the network/host/port
unreachables, is:

(8 bits of type{which is value 3 for unreachables})
(8 bits of code {0-15, depending on what kind of unreachable it is})
(16 bits of checksum)
(32 bits of zeros)
(ip header, options, and first 8 bytes of original ip datagram)

or for TTL exceeded (most often used for traceroute, otherwise used for
detecting routing loops):

(8 bits of type{which is value 11 for ttl exceeded})
(8 bits of code {0 or 1, depending on if it was during transmit or
reassembly})
(16 bits of checksum)
(32 bits of zeros)
(ip header, options, and first 8 bytes of original ip datagram)

That last part can be reconstructed to determine what flow caused this
message to be generated.  The IP header will contain the original source and
destination address and the protocol of the packet that caused the icmp
packet to be generated.  For udp, the first 8 bytes of the datagram will
contain the sport, dport, length, and checksum.  For tcp, it will contain
the sport, dport, and sequence number.  For icmp it will contain the type,
code, checksum, and another 4 bytes that are type/code dependant.  Since a
connection with respect to iptables is defined by a
(proto-saddr/sport-daddr/dport) construct, then the information in an icmp
packet is sufficient to match it to a connection description.  The above two
are, I believe, the only icmp messages that should be RELATED to a tcp or
udp connection (or, for that matter, an ICMP "connection".  If I send an
icmp echo request that goes through a router with no route to the
destination network, it should send back an icmp network unreachable from
its own ip address, which would be RELATED to the original icmp echo
request).  Other icmp messages are generally either NEW (i.e., echo
requests) or, I believe, ESTABLISHED (i.e., echo replies to said echo
requests.)  For example, a line from my /proc/net/ip_conntrack shows:

icmp     1 29 src=a.b.c.d dst=207.46.197.102 type=8 code=0 id=1280
[UNREPLIED] src=207.46.197.102 dst=e.f.g.h type=0 code=0 id=1280 use=1

This shows that I'm nat'ing a.b.c.d to e.f.g.h, and have sent a packet of
type=8, code=0, (icmp echo request) with id=1280 to 207.46.197.102, and am
expecting back a packet of type=0, code=0 (icmp echo reply) with id=1280
from that same host.

Excellent documentation on all of this is in "TCP/IP Illustrated, Volume 1:
The Protocols" by W. Richard Stevens.  If you really want to know everything
about IP and don't care that your brain might explode, read it cover to
cover.  :)

-Joe

> -----Original Message-----
> From: netfilter-admin@lists.samba.org
> [mailto:netfilter-admin@lists.samba.org]On Behalf Of Nick Drage
> Sent: Thursday, May 30, 2002 7:59 PM
> To: netfilter@lists.samba.org
> Subject: Re: sendto: Operation not permitted
>
>
> On Thu, May 30, 2002 at 08:55:17PM +0100, Antony Stone wrote:
> > On Thursday 30 May 2002 3:13 pm, alex@pilosoft.com wrote:
>
> > > > This type of ICMP message will be RELATED to an existing TCP
> > > > connection, therefore it will be allowed through the firewall by the
> > > > sort of rulset Claudio was using - if you recall, this was:
> > >
> > > Ah, I didn't know iptables are smart enough to realize that!
> >
> > Yes, this is one of the beautiful things about netfilter /
> iptables - ICMP
> > packets are automatically recognised as being RELATED to the
> TCP packets
> > which they're, well, related to.
>
> How does netfilter determine if the ICMP packet is RELATED to anything in
> the state table?  Anyone suggest documentation that details this?
>
> --
> FunkyJesus System Administration Team
>
>
>
>

Re: sendto: Operation not permitted

[Nick Drage]

On Thu, May 30, 2002 at 09:01:32PM -0400, Joe Patterson wrote:
> kind of the same way that a system determines what an ICMP message relates
> to.  For example, the format of an ICMP unreachable message, which includes
> such messages as the fragmentation needed and all the network/host/port
> unreachables, is:

<snip>

Thank you very much for this detailed explanation, much appreciated.

> Excellent documentation on all of this is in "TCP/IP Illustrated, Volume
> 1: The Protocols" by W. Richard Stevens.  If you really want to know
> everything about IP and don't care that your brain might explode, read it
> cover to cover.  :)

Heh, I have two copies of this around, one at work and one at home.  I've
yet to read it all the way through, but it's at the top of the "to read"
pile.

Actually I know this book has been mentioned before - I commute by train a
lot, is it a good book to read on the train, or best to read while I'm sat
online so I can watch "live" what it describes?

Thank you.

-- 
FunkyJesus System Administration Team

Re: sendto: Operation not permitted

[Antony Stone]

On Thursday 30 May 2002 2:46 pm, alex@pilosoft.com wrote:

> Antony, ever heard of TCP MTU Discovery?

Er, yes, it's a mechanism whereby machines communicating by TCP find out the 
maximum size of packets which can be transmitted between them, across 
whatever underlying protocol connects them.

> Please read up on it and try again.

What is the point you are trying to make ?


Antony.