Well, I'm a bit confused with the command "same-securty-level permit intra-interface"
I configured an asa, with this command, and and just try to use the inside interface as a "gateway".
I mean : my packet is sent from my station 192.168.1.2 to the ASA inside interface 192.168.1.100 and then the ASA should send it to the router 192.168.1.1, (so back to the same interface), and then the router send the packet to Internet.
It works fine for ICMP... but nothing else ^^
Where am I wrong ??
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 126.96.36.199 (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 188.8.131.52, 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
I hope I didnt bore you with the long story