I'm trying to configure ASA for the specific scenario.
ASA5545X, IOS 8.6(1)2, single contest, routed mode.
description Outside interface
ip address 207.X.X.X 255.255.255.0
ip address 192.168.8.81 255.255.255.224
object network remote.172.21.198.0
subnet 172.21.198.0 255.255.255.0
object network Destination.test
subnet Y.Y.Y.0 255.255.255.0
route Outside 0.0.0.0 0.0.0.0 207.X.X.1 1
route WAN-DMZ 0.0.0.0 0.0.0.0 192.168.8.65 3 (I realize this route is not in the routing table and can be omited)
nat (Outside,WAN-DMZ) source static remote.172.21.198.0 remote.172.21.198.0 destination static Destination.test Destination.test no-proxy-arp
There is a configuration for Lan-to-Lan ikev1 VPN. No NAT, vpn filter applied.
Connection comes in on Outside interface, from the dynamic peer. Tunnels are formed. Traffic from remote site, 172.21.198.0 can reach any explicitly defined and routed network inside.
The goal is to route all traffic from remote site (172.21.198.0 decrypted) out of WAN-DMZ interface.
As there is no PBR on ASA platform, identity NAT has the loophole, accordning to Cisco documnetation.
"•(Routed mode) The default real and mapped interface is Any, which applies the rule to all interfaces.
•(8.3(1), 8.3(2), and 8.4(1)) The default behavior for identity NAT has proxy ARP disabled. You cannot configure this setting. (8.4(2) and later) The default behavior for identity NAT has proxy ARP enabled, matching other static NAT rules. You can disable proxy ARP if desired. See the "Routing NAT Packets" section for more information.
•If you specify an optional interface, then the ASA uses the NAT configuration to determine the egress interface. (8.3(1) through 8.4(1)) The only exception is for identity NAT, which always uses a route lookup, regardless of the NAT configuration. (8.4(2) and later) For identity NAT, the default behavior is to use the NAT configuration, but you have the option to always use a route lookup instead. See the "Routing NAT Packets" section for more information."
Please also refer to "Cisco ASA 5500 Series Configuration Guide using the CLI 8.4"
Egress Interface Selection Process
The selection process follows these steps:
1. If a destination IP translating XLATE already exists, the egress interface for the packet is determined
from the XLATE table, but not from the routing table.
2. If a destination IP translating XLATE does not exist, but a matching static translation exists, then
the egress interface is determined from the static route and an XLATE is created, and the routing
table is not used.
3. If a destination IP translating XLATE does not exist and no matching static translation exists, the
packet is not destination IP translated. The ASA processes this packet by looking up the route to
select the egress interface, then source IP translation is performed (if necessary).
For regular dynamic outbound NAT, initial outgoing packets are routed using the route table and
then creating the XLATE. Incoming return packets are forwarded using existing XLATE only. For
static NAT, destination translated incoming packets are always forwarded using existing XLATE or
static translation rules.
So the XLATE is in place:
ASA# sh xlate
1 in use, 4 most used
Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice
NAT from Outside:172.21.198.0/24 to WAN-DMZ:172.21.198.0/24
flags sI idle 1:24:49 timeout 0:00:00
But the XLATE never gets hit (see error message in the log below)
ASA# sh nat int Outside detail
Manual NAT Policies (Section 1)
1 (Outside) to (WAN-DMZ) source static remote.172.21.198.0 remote.172.21.198.0 destination static Lenta Lenta no-proxy-arp
translate_hits = 0, untranslate_hits = 0
Source - Origin: 172.21.198.0/24, Translated: 172.21.198.0/24
Destination - Origin: 220.127.116.11/24, Translated: 18.104.22.168/24
The Egress interface does not change to WAN-DMZ. The following error message can be seen in LOGs:
6 Nov 19 2013 14:42:14 302014 172.21.198.22 2934 22.214.171.124 80 Teardown TCP connection 15403 for Outside:172.21.198.22/2934 to Outside:126.96.36.199/80 duration 0:00:00 bytes 0 Flow is a loopback
Intra-interface communication should not be on, as far as I understand.
What am I missing in this scenario?
Is there any other workaround?
The egress interface selection has been a bit of an headache for me at some points and a source of confusion. I have read the exact same things you have mentioned in your post about the software level after which the behaviour of the ASA should change.
However, we for example have a couple of ASAs running 8.4(2) that still dont act as the Cisco documentation states which I find very dissapointing.
If there is no problems with the configurations (as it seems the NAT configuration is at the very top) you probably need to move to 9.0(x) or 9.1(x) software where I have found that the NAT works as is described in the documentation. Most of my tests are done on original ASA series so they dont support the software you are using. (Its the starting software for ASA5500-X Series) I use 8.4(5) and upwards for my tests
If there would be no errors in the configuration then I would say the problem might be on the software level even though the documentation indicates that it should work in your software. Then again as I said already, the documentation has been proven wrong by myself once already.
I was wondering if we could get any output with "packet-tracer" but the problem might be that the traffic is supposed to be entering from a L2L VPN connection.