11-24-2010 10:49 PM - edited 03-11-2019 12:14 PM
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
Solved! Go to Solution.
11-25-2010 07:58 AM
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.
11-25-2010 06:34 AM
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.
11-25-2010 07:32 AM
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
11-25-2010 07:58 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide