On Tue, Feb 26, 2002 at 07:01:35PM +0100, Guillaume Morin wrote: > > > As you Ramin noticed, icmp not elicited by our packets, will get dropped > > > by the kernel. if we change the source ip, they will get dropped. > > > > They will? Is that specific to 'icmp dst port'? I thought routers > > between the source and the destination could return ICMP errors with > > their IP address if there is not route or such... > > It should be specific for icmp port unreachable since according to > RFC792 only destination host is supposed to send this kind of icmp > packets (type 3, code 2). However, I have looked in the kernel tree, and > I've not found any check that compares the src of the IP packet which > carries this kind of icmp packets and the destination host of the > packet which triggered the error. Any hints ?
Yes. The behavior you described is what I'd have expected as no other machine than the dst machine can claim that the port was unreachable. _BUT_ I also tested this on a SunOS and apparently they also don't check the ip of the originating icmp against the dst ip. > > > > Or not? Please explain anyone, what is the use of this patch to REJECT > > > target. > > > > Well, one interesting idea is a firewall bridge which doesn't actually > > have an IP address of its own being able to send ICMP error back saying > > unreachable as if it was the destiation machine... :) > > Or you could use your ISP core routers ip address, that would look like > your net is unreachable. Of course, it could be work around using a > simple traceroute. I think this new module could make the linux tcp/ip stack compliant with RFC792 _if_ we could dynamically source the icmp with the dst ip... Ramin
