regular translation creation failed

Collin Clark · ‎03-13-2009

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?

Ivan Martinon · ‎03-13-2009

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

Collin Clark · ‎03-13-2009

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.

Ivan Martinon · ‎03-13-2009

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.

Collin Clark · ‎03-13-2009

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?

nachiketj · ‎03-16-2009

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.

Collin Clark · ‎03-16-2009

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.