Good day, Brian, all,
(Many thanks to George Bakos, one of my fellow researchers, for
clarifying the following material about unreachables.)
On Thu, 2 May 2002, Brian J. Murrell wrote:
> On Thu, May 02, 2002 at 10:20:49AM -0400, William Stearns wrote:
> > Please forgive me if I've misunderstood, but I though "-m state
> > --state RELATED" would match port unreachables, allowing them to return to
> > sender.
>
> Well, the way I see it is this:
>
> If you think about the inner workings of an ICMP (port unreachable for
> instance), you get a packet, of type ICMP with a source address of the
> host you were trying to reach and a destination of your host. You
> _can_ also get a "fragment" of the packet that you sent originally
> which generated the error.
According to the RFC's (rfc 792 and 1122, at
http://www.rfc-editor.org/rfc/rfc792.txt and
http://www.rfc-editor.org/rfc/rfc1122.txt ) for unreachables, the router
creating the unreachable message _must_ include at least the IP header and
at least 8 bytes (a stack can return more if it chooses, rfc1122 clarified
this) of the next header after IP. In the case of straightforward tcp or
udp packets, 8 bytes is enough for the unreachable message to guarantee
that the port information comes back in the unreachable message. The only
case we can think of where the port information might get bumped out of an
unreachable is if there's an ipsec authentication header between the IP
header and the tcp header.
> If the packet fragment is complete enough to have at least IP
> addresses and TCP/UDP port numbers, then conntrack _could_ match it to
> a connection and send it back on it's way to the originator.
>
> But in the example packet I got, there were no (UDP) port numbers,
> only IP addresses. Conntrack could take a guess at who's packet it is
Is there any chance you're using an older kernel? I seem to
remember there were some fixes to the logging of unreachables, but I can't
remember when.
One approach might be to capture one of these packets with
tcpdump, decode it, and see if it does include port info.
tcpdump -nx 'icmp and icmp[0] = 3'
> by looking in the table for matching entries with the right IP
> address, but what if more than one host has generated traffic for the
> same host and same protocol (i.e. UDP, TCP, etc.)? Conntrack can not
> know which one really generated the ICMP packet. I don't think
> anyway. :-)
If that case ever showed up (say, in the AH header pushing the tcp
or udp ports out of the packet), you'd be right.
Cheers,
- Bill
---------------------------------------------------------------------------
"Klein bottle for rent -- inquire within."
(Courtesy of Brad Johnson <[EMAIL PROTECTED]>)
--------------------------------------------------------------------------
William Stearns ([EMAIL PROTECTED]). Mason, Buildkernel, named2hosts,
and ipfwadm2ipchains are at: http://www.stearns.org
--------------------------------------------------------------------------
