sun miller <sunminlei@xxxxxxxxx> wrote: > I'm sorry, I forgot to cc netfilter in my previous reply, so I'm > sending it again. I apologize for my oversight. I hope I didn't > disturb you. > > > For some reason the comment that explains this got dropped when > > code was moved around. The original comment was: > > > > /* Redirects on non-null nats must be dropped, else they'll > > start talking to each other without our translation, and be > > confused... --RR */ > > > > ... which is exactly what this does, it drops the redirect > > if it can't verify that no nat is in place in either direction. > > Thank you for your reply and explanation. > > I searched globally for ip_rt_send_redirect and icmp_send(skb, > ICMP_REDIRECT, ICMP_REDIR_HOST...), and it seems that the related code > paths do not meet ct->status & IPS_NAT_DONE_MASK == IPS_NAT_DONE_MASK. > > Does this mean that icmp_redirect caused by the same subnet request > packet will be DROPPED when the firewall is enabled? Does this break > the correct functionality that the kernel should have originally? (Of > course, this functionality seems to be unimportant from my limited > work experience.) > > Additionally, if it's convenient for you, would you provide an example > scenario for the code comment that mentions "they'll start talking to > each other without our translation, and be confused"? I am unable to > think of any related issues. A -> B, A sends packet to R. R has a DNAT rule to redirect to C (or redirect to R). If we let icmp redirect through, this won't work.
