Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Every few minutes our Cisco ASA 5505 firewall is logging errors that I can't figure out with my limited Cisco experience.

Severity Date        Time        Syslog ID Source IP  Destination IP  Description
3     Mar 25 2010 17:21:14 305006   8.8.8.8                    regular translation creation failed for icmp src inside:10.10.0.206 dst outside:8.8.8.8 (type 3, code 3)
3     Mar 25 2010 17:18:37 305006   8.8.4.4                    regular translation creation failed for icmp src inside:10.10.0.206 dst outside:8.8.4.4 (type 3, code 3)

The logged inside-IP is our internal DNS server, and the outside IP's are Google's public DNS servers, which we're using as forwarders in our local BIND config. ICMP Type 3 Code 3 means "Port Unreachable".

The 'Inspect DNS', 'Inspect ICMP' and 'Inspect ICMP Errors' global Service Policies are enabled, with the default inspection maps.

Our "outside" interface has a fixed IP and our "inside" interface is in the 10.10.0.0/16 subnet. The 10.10.0.206 IP is our internal BIND DNS server, and DNS is resolving fine. Using different DNS forwarders, such as OpenDNS, generates the same errors.

I've spent days trying to figure this one out, so any and all advice is appreciated!

share|improve this question
    
Weird, I've tried using other DNS servers, but they still generate the same errors occasionally. ICMP "Port Unreachable". It's a simple BIND server that forwards local queries to these servers, and performance does not seem to be affected. –  Martijn Heemels Aug 9 '10 at 12:30

3 Answers 3

up vote 1 down vote accepted
+50

This looks like a mismatch in the firewall's NAT state-table timeouts and the DNS server's own timeouts.

ICMP Port Unreachable is being returned by your DNS server, probably in response to a late received packet. BIND picks a random(ish) port for each outbound query, and it's possible for a long-delayed response to arrive long after BIND stopped listening for the response on that port.

That does beg the question of why the firewall happily allows the (late) returned packet in, without subsequently letting the ICMP error back out.

share|improve this answer
    
Thanks for the helpful answer. Any idea how I could make the error disappear? Changing the timeout in Bind seems to require a compile so I'd prefer to avoid that. Perhaps some change in the ASA? –  Martijn Heemels Oct 1 '10 at 10:41
    
What O/S is the BIND server on? Simply disabling the generation of the ICMP Port Unreachable packets in the first place might be sufficient. –  Alnitak Oct 1 '10 at 12:42
    
It's an Ubuntu 10.04 Linux machine. –  Martijn Heemels Oct 1 '10 at 12:57
    
You could use iptables, e.g. iptables -A OUTPUT -p icmp --icmp-type 3/3 -j DROP - this is untested, and may need changing for your environment, but it should drop any ICMP Port Unreachable messages. –  Alnitak Oct 1 '10 at 13:06

You could try the following, from most likely to least likely:

  • You may need to enable "Inspect ICMP" in order to make ICMP replies work correctly - this is the case with the newer ASA software (as of 8.2, I believe)
  • Check that you have the appropriate NAT statement(s) on the inside interface and GLOBAL statement on the outside interface
  • Check that your access-list on the inside interface allows outbound ICMP that matches this traffic

If none of these things fix the issue, try setting up captures as follows:

asa(config)# access-list test permit icmp host 10.10.0.200 8.8.0.0 255.255.0.0
asa(config)# access-list test permit icmp host <outside interface IP> 8.8.0.0 255.255.0.0
asa(config)# access-list test permit icmp 8.8.0.0 255.255.0.0 host 10.10.0.200
asa(config)# access-list test permit icmp 8.8.0.0 255.255.0.0 host <outside interface IP>
asa# capture test1 access-list test interface outside trace
asa# capture test2 access-list test interface inside trace

Then, after a couple of these errors are logged (if I recall correctly, this is the syntax):

asa# show capture test1 trace
asa# show capture test2 trace
share|improve this answer
    
Thanks for your suggestions. I've checked them but I still can't tell what is wrong. Even the packet capture didn't point me to the solution. –  Martijn Heemels Sep 1 '10 at 11:52

Here is one reason why we do see this message in our ASA:

regular translation creation failed for icmp src inside:10.x.x.3 dst outside:19.13.123.16

When a PC/Server is running torrent, it sets up a lot of NAT sessions. When the user then close/terminate the torrent client we do get lots of this error for a long time.

What to do with it:not sure. Why you get this message for 8.8.8.8 Googles public DNS, not shure. It may be a program that has been terminated while having open session to the DNS server.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.