On Sun, Dec 15, 2013 at 2:57 PM, Oliver <oliver@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > I don't think that's universally the case; whether or not a port unreachable > happens is going to depend on the configured behaviour; I know the rate of ICMP error packets is limited by default, but in many cases, the rate of ICMP packets isn't very large, so this may not a problem. > it may very well just > silently drop the packet. > Yes. I know it is also a solution, but it requires the explicit configuration. > Perhaps I'm mistaken here so please correct me if so: > > Firstly, I don't see why this is necessary as once the client does hole punch, > the conntrack entry should still be good to go providing the other end is > adhering to the port it's supposed to use. UDP is unreliable so an application > shouldn't be expecting perfect delivery; once Client B finally does their > initial transmit, a retransmit on the part of Client A should succeed without > any special behaviour on the part of Netfilter. > Strictly speaking, Linux's NAT implementation isn't a Port Restricted Cone NAT but based on conntrack, so once the first packets is delivered locally, the following packets will be delivered locally too until the conntrack is timed out due to idle. So UDP hole punching doesn't work. > Secondly; I see this as a great opportunity for a DoS attack if someone can > spam ICMP errors down the pipe at you. I don't think so, because the attacker must get the correct 5 tuples before the reply packets pass through the linux box. Thanks. -- Regards, Changli Gao(xiaosuo@xxxxxxxxx) -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
