Interesting facts about ASA

In today's lab I found out quite a few interesting facts about ASA security algorithms.
Sample lab topology:

 MyHostComputer:
Adapter1 - XX.XX.XX.XX/24 - Internet
Adapter1 - 192.168.137.1/24 - bridged to ASA and CorporateHost
Adapter2 - 192.168.138.1/24 - bridged to RemoteClient

CorporateHost:
Adapter1 - 192.168.137.195/24 - VMware bridged interface
Loopback1 - 192.168.255.100 - bridged to ASA. Default gateway of host 192.168.255.254

ASA:
Ethernet0/0 - 192.168.137.254/24 - Outside interface
Ethernet0/1 - 192.168.255.254/24 - Inside interface

ASA config:

nat (outside) 0 access-list REMOTE_NAT0_ACL
nat (outside) 1 access-list REMOTE_NAT_ACL
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 access-list NAT1_ACL
global (outside) 1 interface
access-list REMOTE_NAT_ACL extended permit ip 192.168.200.0 255.255.255.0 any
access-list REMOTE_NAT0_ACL extended permit ip 192.168.200.0 255.255.255.0 192.168.255.0 255.255.255.0
access-list inside_nat0_outbound extended permit ip 192.168.255.0 255.255.255.0 remote_protected 255.255.255.0
access-list inside_nat0_outbound extended permit ip any 192.168.200.0 255.255.255.0
access-list outside_1_cryptomap extended permit ip 192.168.255.0 255.255.255.0 remote_protected 255.255.255.0
access-list NAT1_ACL extended permit ip 192.168.255.0 255.255.255.0 any
access-list INBOUND_PERMIT extended permit icmp host boss any
access-group INBOUND_PERMIT in interface outside

That is our initial data.

If you will take a closer look, you will notice that inbound pings are permitted through the appliance to the internal hosts. However, if I try to ping 192.168.255.100 from 192.168.137.1, I'm getting syslog message:
2010-02-20 12:30:47    Local4.Error    192.168.255.254    Feb 20 2010 12:30:50 192.168.255.254 : %ASA-3-305005: No translation group found for icmp src outside:boss dst inside:192.168.255.100 (type 8, code 0)
Well, why? There is no nat-control command in running config, inbound icmp are permitted. And message states, that no translation group for icmp. This is point to a decision that the problem is related to NAT, isn't it?
As I found out, the problem was related to ASA security algorithms. ASA is smart enough to understand, that packet is coming inbound, so the reply will come from inside interface to outside and PAT will be performed (be default, ASA doesn't track icmp connection in it's connections table). It means that the outbound packet (coming from inside to outside) will have it source address translated to IP address of outside interface of ASA (PAT). It means that host 192.168.137.1 will receive icmp reply from different address in contrast to address it was pinging. So it will drop the packet. So this process is totally useless and ASA decides to drop the packet as it first comes as icmp echo request. For pings to be successful, we need to add one more translation rule to NAT. Namely Identity NAT (NAT 0). That way the echo reply source address won't be translated as it goes through the ASA and will not be dropped by receiving host.
Therefore, to make it all works, we should add one more ACL:

access-list inside_nat0_outbound extended permit ip 192.168.255.0 255.255.255.0 host boss