ASA 5510 is default gateway for inside clients (its inside address 10.1.1.1/16):
dst 0.0.0.0 mask 0.0.0.0 10.1.1.1
ASA 5510 has 2 routes defined:
route inside 188.8.131.52 255.255.255.255 10.1.8.13 1
route inside 184.108.40.206 255.255.255.255 10.1.8.13 1
So I expect ASA to forward to 10.1.8.13 packets from client destined for 220.127.116.11 (or .3). The Novell BorderManager firewall that this ASA replaced used to do that. But the ASA does not. I have to define the route on the client so the client knows how to get there. Is this ASA behavior expected? Am I missing something in my configuration?
I believe that this is expected behavior and there is something that you can add to your config to modify the behavior.
The issue is that the packet entered on the inside interface and you are attempting to forward back out the same interface. With the concept of security levels on the interfaces of the ASA it means that by default the ASA does not want to forward traffic back out the interface that it arrivd on. Sometimes we refer to that action as haripinning. If you configure this on your ASA it should permit it to forward the traffic as you want it to:
same-security-traffic permit intra-interface
Give it a try and let us know if it fixes your issue.
In ASDM I found already checked "enable traffic between...same interface", then found the same-security-traffic permit intra-interface already in running config. Will this need an ACL? I already have the ACL on incoming at Inside interface permit: IP to any destination. Another ACL to let this traffic back out on the Inside? Thanks.
I did a Packet Trace test and got a denied; then saw on my new Syslog server a "portmap translation creation failed" on that test packet. I supposed I need a translation exemption for inside to inside.I'll try it out.
I added a NAT exemption, and no longer get portmap translation failure. Packet Tracer says packet is allowed both ways. I get a Built Inbound TCP connection from my PC to the remote address that is out through my router (which is also in the inside interface, local IP address). But then right away i get Teardown that TCP Connection duration 0 bytes 0 TCP Reset-O. Then I get denial on a couple packets because there is no connection. So I'm off to find out about TCP Reset-O
What does 10.1.8.13 & 18.104.22.168 represent? what is the client Ip address and its GW?
Why do you have 2 static routes pointing to 10.1.8.13?
Rick: the command (Same-security-traffic permit intra-interface) has to be configured if you have IPsec tunnel and VPN client has to access Internet through the same Interface.
The Security Appliance by default wont permit traffic across the interface unless for IPSec traffic back to the VPN client.
10.1.8.13 is a router's ethernet interface on my inside network. 22.214.171.124 and.3 are the hosts reached by way of that router. I added 2 host-specific routes rather than a network route. My inside network is 10.1/16, so 10.1.8.13 is local. My own client is 10.1.10.165. The ASA's inside interface is 10.1.1.1, and it is the gateway for my clients. If I put those same two routes on my client, I get to those 2 172. hosts by way of 10.1.8.13. But with those two routes only on the ASA I don't get there. Thanks.
I thought that the original post was fairly clear that 126.96.36.199 and 188.8.131.52 are some servers that clients want to access. And that 10.1.8.3 was some device that would route to those destinations. So the ASA has two static routes so that it would forward traffic for those two destinations back out the inside interface on which they arrived. Perhaps Mike can confirm that this understanding is correct - or can clarify if I am mistaken.
Your comments seem to associate the same-security-traffic only with IPSec VPN. While IPSec VPN (for client to Internet connectivity) is one of the more common reasons to use this command it is certainly not the only one. The requirement that Mike has described (for inside clients who have the ASA configured as their default gateway to be able to communicate with other inside subnets) is another instance where the command is required. And Mike has indicated that it is enabled in his configuration.
That understanding is correct. This involves IP traffic, no IPSec. I want the routes on the ASA so I won't have to put them on every client that needs them. I have had the same-security permit intra-interface configured all along. I found portmap translation errors while monitoring, and added NAT exemption to eliminate that error. Now I don't see translation problems. But in the log I see a Build TCP connection client to server, then an immediate Teardown connection, with reason TCP Reset-O.
Thanks for the clarification.
I am not clear in your post whether the TCP reset is generated by the ASA or is reflecting a reset received from some other device. Can you tell us any more about it?
I set ASA monitoring to debugging, filter on my client (10.1.10,xxx) IP. I run wireshark on my client. Wireshark says client sends a SYN packet, receives a TCP ACKed lost segment packet, sends an RST and then another SYN, receives a SYN,ACK, sends an RST, receives a SYN, ACK, sends an RST, receives a SYN,ACK, sends an RST and then a SYN, receives a SYN,ACK, sends an RST.
During that exchange the ASA monitor shows (twice): Deny TCP (no connection) from 'client' to 'server' flags FIN ACK on interface inside.
I run the Packet Tracer tool, in both directions, both times it says the packet is passed.
I repeated the Wireshark on my client PC, added another Wireshark on a PC cabled to a switch port mirroring the port that the ASA is cabled to. While my client PC shows traffic to and from the server, the Wireshark of traffic to the ASA shows traffic only from my client to the server - no trace of traffic from server back to client. Would this server, or the intermediate router (server's gateway) be remembering my client's MAC, and bypassing the ASA? That seems bound to confuse.
Your PC sends to the ASA because the ASA is the gateway for the PC and the PC is attempting to communicate to a "non local" address. As you have explained, the ASA forwards to a router which forwards to the destination. For the response traffic it is sent to the router, and the router is now forwarding directly to a local address, so it would ARP, get your PCs MAC address, and forward directly to the PC and bypass the ASA.