Resolving inner ICMP connections

[Patrick McHardy]

Mark Huang wrote:
> Patrick McHardy wrote:
> 
>> That depends. What do you mean with "makes no sense"?
> 
> 
> Well, in the case of the French router, plain wrong.

The question is, how can conntrack know its "wrong"? There is
no relationship between the inner and the outer addresses that
we could rely on.

> But I can imagine a 
> few other scenarios as well. The inner IP packet could be completely 
> unrelated to any current connection, or it could be a cracker trying to 
> break some current connection on the machine by spoofing inner ICMP 
> packets. I'm just speculating and don't have any tests to back this 
> claim up, but I might try it just to see what happens.

It its completely unrelated it will be tracked as state INVALID.
Spoofed ICMP packets don't affect conntrack directly, ICMP replies
are only tracked to make filtering easier and to correctly reverse
NAT the inner packet. It doesn't affect the connection state.

>> Maybe an old version of linux? :) NAT used to do stange things to
>> locally generated ICMP packets until about a year ago.
> 
> 
> Do you mean on the French router or on my box? I don't know what's 
> running on the French router, but I'm running a 2.6.12ish kernel.

The router.

>> What are these assumptions?
> 
> Well, the worst assumption was that
> 
> conntrack->tuplehash[dir].tuple.dst.ip == skb->nh.iph->ipaddr
> 
> I.e., the conntrack associated with the packet I received on the local 
> IN hook, has the same destination IP address as the packet itself, which 
> in retrospect is probably a bad assumption. When the French router 
> returned the inverted ICMP error message, the conntract dst.ip was that 
> of the French router, not my IP address!

OK, thats weird. I don't think this can be used to confuse conntrack
itself, but I'm going to check.