Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
Community Member

incomplete translation

i have following configs on an Asa:

interface local - 100 , ip address on 172.16.1.0 /24

interface svr  -  75 ,  ip address on 192.168.1.0 /24

interface internet - 0

i have these messages: No translation group found for udp src svr:192.168.1.251/58765 dst local:172.16.1.12/53

192.168.1.251 is a client from svr interface. name resolution is done by 172.16.1.12 on local.

nat (svr) 0 access-list no_nat

access-list  no_nat line 1 extended permit ip host 192.168.1.251 host 172.16.1.12

what do those message indicate and how to correct it.

TIA

1 ACCEPTED SOLUTION

Accepted Solutions
Purple

Re: incomplete translation

Hi,

If you want your server in your dmz to be able to do dns requests on the inside dns server then you can modify your ACl like this:

no access-list no_nat extended permit ip host 192.168.1.251 host 172.16.1.12

access-list  no_nat  extended deny tcp host 192.168.1.251 host 172.16.1.12  53

access-list  no_nat  extended permit ip host 192.168.1.251 host 172.16.1.12

But then if you want this traffic to be natted to inside subnet you must create dynamic NAT mapping on inside interface.

Then you must permit dns replies back with an ACl as they are going from a lower security interface to a higher security interface and so by default denied.

you can do so:

access-list INBOUND_DNS_REPLIES extended permit udp host 172.16.1.12 host 192.168.1.251 if you didn't nat which is not mandatory as no nat-control is the default.

otherwise you must replace 192.168.1.251 by the inside interface ip address.

Hope I have been clear enough.

Regards.

Don't forget to rate helpful posts.
3 REPLIES

Re: incomplete translation

Hi,

The error means you do not have a NAT rule defined for traffic from a DMZ host 192.168.1.251/58765 dst local:172.16.1.12/53.

Since the communication uses NAT0, it's not going to NAT the traffic.

Are you able to communicate between DMZ and inside and you're concerned about the error only, or there's no connectivity?

Federico.

Community Member

Re: incomplete translation

Thanks,

Currently there is only a staging server that is used for testing purpose by systems.

Inside and dmz are not communicating for any production traffic at present , as this will be moved to production in another months time.

I was trying to see if things work well. I am concerned on the error, if this shows up during production later.

how do we overcome this by defining nat rule

TIA

Purple

Re: incomplete translation

Hi,

If you want your server in your dmz to be able to do dns requests on the inside dns server then you can modify your ACl like this:

no access-list no_nat extended permit ip host 192.168.1.251 host 172.16.1.12

access-list  no_nat  extended deny tcp host 192.168.1.251 host 172.16.1.12  53

access-list  no_nat  extended permit ip host 192.168.1.251 host 172.16.1.12

But then if you want this traffic to be natted to inside subnet you must create dynamic NAT mapping on inside interface.

Then you must permit dns replies back with an ACl as they are going from a lower security interface to a higher security interface and so by default denied.

you can do so:

access-list INBOUND_DNS_REPLIES extended permit udp host 172.16.1.12 host 192.168.1.251 if you didn't nat which is not mandatory as no nat-control is the default.

otherwise you must replace 192.168.1.251 by the inside interface ip address.

Hope I have been clear enough.

Regards.

Don't forget to rate helpful posts.
162
Views
7
Helpful
3
Replies
CreatePlease to create content