topic Re: incomplete translation in Network Security

incomplete translation

suthomas1 — Mon, 11 Mar 2019 19:14:23 GMT

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

Re: incomplete translation

Federico Coto Fajardo — Thu, 25 Nov 2010 14:34:49 GMT

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.

Re: incomplete translation

suthomas1 — Thu, 25 Nov 2010 15:32:15 GMT

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

Re: incomplete translation

cadet alain — Thu, 25 Nov 2010 15:58:02 GMT

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.