Hi,
I never got around to opening a TAC case about this. I have also forgotten a lot of things related to these problems but for me atleast they were "well known" problems with the different software levels (8.3+)
If I don't remember wrong the original new software 8.3 did not yet let you use NAT configuration to decide the egress interface for traffic but always used a route lookup to determine that interface.
If you take a look at the release notes for the ASA softwares then to me it seems 8.4(2) was the first software to let you manipulate the egress interface if you were using an Identity NAT which to my understanding means basically NATing the subnet/address to itself.
Here is where it start getting strange for me atleast.
It seems to me that after the release notes of 8.4(2) there has been no mention of about the NAT could affect the egress interface. I might be terribly wrong as I have not really had any time to go through any official documents or just might not remember something that I have read previously.
I might be wrong but to me it seems since 8.4(2) it has been totally random which software level lets you use the NAT to manipulate the egress interface and which doesnt. To my understanding for example in 8.4(5) and 9.1(1) this should work just fine but go another maintanance update forward or backward and the NAT behaves differently. I have not tested a lot of the latest maintanance updates at all since my actual work takes most of my time.
Also it seems strange to me that the above example you mention is an Identity NAT of sorts since neither the source or destination address is modified. So according to the notes it should work (unless there has been some change). Then again it could be called NAT0 and Policy NAT also I guess so how are we supposed to interpret the NAT behaviour based on those early release notes.
If I wanted to be thorough (for which I don't really have the time at the moment) I would boot my ASA with every single software level since the above mentioned and test some NAT configuration and then on the basis of that open a TAC case as every now and then this type of NAT configuration is simply required in a customer environment.
I would suggest opening a TAC case about this and if you could share information of it here in this discussion. I do remember hearing some TAC cases related to this were just closed with some random explanation that did not make sense to me atleast. I guess it depends who handles the TAC Case.
I would also like to mention that in your case you mention the problem is with a L2L VPN setup so I think you should be able to correct this problem by simply adding routes for the remote subnets towards the other gateway or you can rather add the line "crypto map <name> <number> set reverse-route" to the L2L VPN connections configuration so the ASA automatically adds the routes to the routing table based on the configured Crypto ACL.
Or are we perhaps talking about an overlapping destination subnet which you want to force to work for your source subnet through the L2L VPN? I mean a situation where you have the same subnet as the remote end behind your firewall but still want to forward traffic from a specific LAN subnet to that overlapping subnet through the L2L VPN rather than that traffic getting forward to your LANs same subnet?
- Jouni
