Re: Resolving inner ICMP connections

[Patrick McHardy <kaber@trash.net>]

Mark Huang wrote:
> Hi all,
> 
> Is it a bug that 
> net/ipv4/netfilter/ip_conntrack_proto_icmp.c:icmp_error_message()
> associates ICMP error message packets with the connection specified in 
> the inner IP packet, even if the direction of that connection makes no 
> sense?

That depends. What do you mean with "makes no sense"?

> I found a router in France that accidentally swaps the direction of the 
> inner IP packet, instead of preserving it verbatim inside the ICMP error 
> message. So, for instance, if you (A) traceroute it (B):

Maybe an old version of linux? :) NAT used to do stange things to
locally generated ICMP packets until about a year ago.

> IP: A -> B
>   UDP: a -> b
> 
> You get back an ICMP destination unreachable message that looks like:
> 
> IP: B -> A
>   ICMP: type 3, code 3
>     IP: B -> A
>     UDP: b -> a
> 
> Instead of:
> 
> IP: B -> A
>   ICMP: type 3, code 3
>     IP: A -> B
>     UDP: a -> b
> 
> Obviously there's something seriously wrong with this router. What 
> happens is that the ICMP error message gets associated with the original 
> side of the connection (as in IP_CT_DIR_ORIGINAL), not the reply side, 
> messing up a few assumptions I was making in my NF_IP_LOCAL_IN hook.

What are these assumptions?