From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Wed Oct 01 2003 - 07:12:32 GMT-3
At 11:22 AM +0300 10/1/03, emad wrote:
>Folks,
>I have access server (3640) with NM-8AM configured for dialup , I tried
>to put access-list to block the ICMP echo and echo-reply on the ingress
>and egress of its Ethernet interface.
>When I put the access-list as following:
>
>Access-list 120 deny icmp any any echo
>Access-list 120 deny icmp any any echo-reply
>Access-list 120 permit ip any any
>
>Interface Ethernet e0/0
>Ip access-group 120 in
>Ip access-group 120 out
>
>
>I found that the dialup users lost the browsing and DNS is not working
>but when I removed the access-list from the input and keep it only on
>the output , everything went good and browsing back again!!!
>Do u know any relation between DNS and ICMP!?
By browsing, I'm assuming you refer to Web, not NetBIOS or other
Windows browsing.
Interesting. Not specifically in the protocols, but I wonder about
the host implementation, which might require Sniffer-type
information, or debugs, to explain.
Is the browsing going through an ISP, or are the DNS and other
servers being browsed inside your lab? Unusual behavior may be
happening at ISPs that are trying to patch around Verisign's wildcard
A records of .com and .net, and their Sitefinder application. It
might be interesting to be sure you are browsing remote domains in
OTHER than the .com and .net top-level domains. Verisign's hack only
affects .com and .net, although ISP resolvers might be using
counter-Verisign hacks on other TLDs.
Different pieces of software use different sanity checks for DNS.
One, for example, is double DNS lookup. The host, on retrieving an A
record, does a reverse lookup of the address returned, and does
another lookup of that domain. It might ping to find if the second
lookup result (or even the first) exists.
There's also the possibility that your ISP, or a DNS server below the
TLD root that it consults, is caching some address resolution results
but pings to verify the information isn't stale. In the scenario that
I think you have, however, that would be less likely to be affected
by end user software.
In other words, I'd want to see all the protocol exchanges from
initial DNS request to resolution failure. I'd also want to see the
problem replicated with no ISP in the loop, requiring a local DNS
server. Also experiment with more specific access lists, blocking
only Echo Request or Echo Reply, in one direction at a time.
***Get your CCIE and a FREE vacation: Shop.GroupStudy.com***
This archive was generated by hypermail 2.1.4 : Mon Nov 24 2003 - 07:52:54 GMT-3