Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

regular translation creation failed

I have an ASA5505 that terminates both an IPSec and SSL VPN (pool 172.16.254.0 /24). It's 'inside' interface is in another ASA's DMZ (172.16.100.0/24). When I VPN in I can access all resources inside, however I can not reach any services on the 172.16.100.0 network. The error in the log is

Mar 13 2009 09:38:26: %ASA-3-305006: regular translation creation failed for icmp src dmz:172.16.100.49 dst dmz:172.16.254.22 (type 0, code 0)

I have the two subnets NAT exempted and I have same-security-traffic permit intra-interface on. Any ideas on where to go?

6 REPLIES

Re: regular translation creation failed

This DMZ is a different interface right? does this nat exemption applied to that particular interface?

Re: regular translation creation failed

Yes, it's on a 2nd ASA. How do you apply nat-exempt to an interface? After some more research here's what it looks like is happening. My VPN connection directly contacts the resource (172.16.100.49). The resource contacts it's DG (the 2nd ASA with DMZ interface, 172.16.100.1). The ASA complains that the SYN ACK connection is invalid and drops it. It makes sense why it does it, just wondering if there is a fix. I have verified this by adding a static route in 172.16.100.49 for my VPN subnet (172.16.254.0). I can always create a new DMZ just for VPN as well. I've also attached a diagram.

Re: regular translation creation failed

Oh ok, now it is clear! so pretty much "asymmetric routing" do you have the same security-traffic permit inter-interface? on the ASA that complains about the syn packet? Also go ahead and force a route from the ASA where the VPN clients connect that in order to reach this particular server the traffic goes to 171.16.100.1 this to force the 3 way handshake to go over that asa and respect that when the server (172.16.100.49) sends traffic to its DG it follows the path.

Or create a static route on the server that to reach the pool it will go to the 172.16.100.48.

Re: regular translation creation failed

I like the idea of placing the route in the VPN ASA. It looks better but in the 172.16.100.1 ASA I now get no translation group found. I have it NAT exempted. You mentioned we can do that by interface? Or how would a static look?

New Member

Re: regular translation creation failed

Well not to offend anyone but I would go with the idea of configuring static routes on Server itself rather than VPN ASA. Configuring a static route on VPN ASA moves packet on the same broadcast domain more than required and this might create a problem in future. It is better to go with the idea of placing static routes on server itself for your pool of IPs.

Re: regular translation creation failed

My only "problem" with going that direction is that I have zero control over any of the resources in the DMZ. If a server gets replaced, communications via VPN is broke and I can't fix it (I'm a remote consultant). Documentation on the servers would be ideal, but that is handled by someone else (another consultant). Static routes on servers are a very easy thing to forget when migrating to new hardware.

1398
Views
0
Helpful
6
Replies