Hello,
This is neither a wierdness of same-security-traffic issue nor an xlate lookup or ACL. Adam is right, but the command syntax in his suggestion is the victim of a design which ASA is not developed for. Let me explain.
Connectionless protocols like ICMP and UDP will work right now. But TCP wont. Here is why.
1)192.168.1.2 tries connecting to 198.133.219.25 (cisco.com) via port 80. Host first checks if it has a directly connected route (checks if destination is in the same segment with itself or not). No. Host creates TCP SYN packet sourced 192.168.1.2 from its own L2 MAC address destined to cisco.com IP address, but to ASA's (its default gateway) Layer 2 MAC address, then starts waiting ACK packet that cisco.com will send, from ASA.
2)ASA gets the packet, its destined for 198.133.219.25, places its own L2 MAC to source field, but source IP still remains 192.168.1.2 since it is not performing NAT, and places the L2 MAC of its gateway 192.168.1.1
3)Gateway receives the packet. Source IP of the packet is 192.168.1.2. Gateway has to perform NAT for internet connectivity, so records that into its translation table. Places its Public Ip and mac as source of the packet. The "mac swap" continues throughout its way untill it reaches the destination, while registers into translation tables to not to lose its way back. SYN reaches the destination. ACK is on its way back
4)Finally, our gateway gets the ACK destined for itself, checks its translation table and finds the match. Removes its public IP from destination and places 192.168.1.2.
All was fine untill here, but here is how it ends up
ASA did send the packet with source ip 192.168.1.2, so that means ASA know where that IP is. Under normal circumstances, gateway was going to check its routing table to learn how to get to 192.168.1.2, was going to see ASA as the advertising or statically entered gateway, send that packet, then ASA was going to send it to 192.168.1.2 and finally 192.168.1.2 was going to get the ACK from the L2 address that it destined its SYN to. SYN_ACK was going to be sent and session was going to be established. But here is what happened
Gateway checks its routing table to see how to get to 192.168.1.2, and dang... it has a Connected route to that host, it is within the same segment with that host! Checks its arp table, no MAC entry, broadcasts... 192.168.1.2 responds... Now the packet has the L2 address of the host itself, sends the packet.
Host receives the packet, its the SYN_ACK that it was waiting for, but wait a sec... source L2 MAC address of the SYN_ACK does not match with the L2 MAC address that it destined its SYN for... sorry, TCP is broken... -RST
If ASA have changed the source IP of the packet with its egress int IP (NAT), all was going to work.
Here is the commands with correct syntax that will resolve your isue
access-list NAT permit ip 192.168.1.0 255.255.255.0 any
nat (inside) 1 access-list NAT
global (inside) 1 interface
clear xlate
I hope I didnt bore you with the long story
Regards
