On 07/28/2005 04:37:38 AM, Daniel Hartmeier wrote:
Assuming Windows ping is not doing that, you'll have to provide an
alternative way to decide which client to send replies to. There's
ICMP
sequence numbers, but they can and will overlap for concurrent ping
invokations. The ICMP echo reply quotes the ICMP payload of the query.
But most ping tools will use a constant payload, so that's no
distinguishing criterion. The NAT device could tamper with the payload
and insert its own ID there, but that's modifying the packet in an
intrusive and unexpected way.
I'm curious how any NAT device would do that correctly without relying
on unique/random ICMP ids.
I cannot speak to how anything is implemented anywhere, but it seems to
me that the NAT device could substitute it's own ICMP ID,
which it saves in a state table associated with the sending
IP. When the ICMP reply returns it would then put the original
ICMP id back. This scheme swaps ICMP IDs in a fashion analogous
to the swapping of ports in TCP/UDP NAT port mapping.
I imagine this would require another kind of pf translation
declaration.
Regards,
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
P.S. I remain anxious to hear whether I'd be wasting
my time pursuing inbound traffic bandwidth management.
The thread is:
http://marc.theaimsgroup.com/?t=112139406900001&r=1&w=2
