Using site to site VPNs with IPsec, it is not possible to extend a single subnet across two remote locations. Because the tunnel is a layer 3 entity, routing must take place at the ASAs to go from one subnet to the other.
If you want to extend a single subnet/VLAN over a remote tunnel, you will have to create a Layer 2 tunnel using L2TP which allows you to encapsulate layer 2 frames into IP Packets to be tunneled over the WAN/Internet. You can find out more about this at the following lesson.
If i right understand we use static routing in this scheme because we don’t use default route?
If we will have “ISP_Router” as default route for ASA-1 and ASA-2, static routing we don’t need because “secure” traffic will fall under crypto map.
Pinging the remote tunnel peer IP will not bring up the tunnel, as this will simply generate traffic directly between the two firewalls, and not through the tunnel itself. You must generate user traffic, that is, traffic that will actually traverse the tunnel. In the lesson, this was generated by a ping between R1 and R2 (and not between ASA1 and ASA2 which is the equivalent of what you attempted).
Try pinging from/to the tunnelled subnets and see your results. If you still have difficulties, you know where to find us!
Within the command line of the ASA, you can perform what is called an extended ping. This is also available for Cisco IOS routers as well. In the extended ping you can specify various parameters including the source and destination IPs of the ping among others. To use the extended ping, you simply enter the ping command without any additional parameters. You will then be prompted for specific parameters. You can find out more about the extended ping command here:
As for the GUI, you can use the ping function from the Tools menu from which you can indeed choose the source interface for the pinging.
After doing some research, I have found that this is a bug that has to do with version 9.1(5)16 as well as 9.1(7)32. I hope that this isn’t a production device that you are using, because others have experienced this issue which appears with the ASA software upgrade, but does not disappear when they downgrade to a working version. Others have had to open TAC cases to resolve it. Unless I’m mistaken, there doesn’t seem to be any published solution to the issue that I could find, beyond approaching TAC.
It may be that the particular packet tracer command worked correctly on that specific ASA, but that does not ensure that you should have end to end connectivity. There are many other troubleshooting steps that you must take in order to locate the problem causing your lack of connectivity.
Take a look at Rene’s ASA Firewall course found here:
In there you will find Unit 5 which contains many lessons on site to site VPNs. In there you should find all the necessary principles for site to site VPN creation as well as troubleshooting.
Network Lesson: Cisco ASA Site-to-Site IKEv1 IPsec VPN
I have implemented this lab using CML-LAB using the exact configuration found in this lesson.
I see the VPN is UP but I am unable to ping the interesting traffic from Router 1 and Router 2.
I believe there is no NAT involved here since both routers are connected directly to the inside interface of the ASA and there is no internet access here. I am not sure what is else missing.
Can you please advise?
I see the packets are being encapsulated but not decapsulated on ASA 1.
I see the packets are being decapsulated but not encapsulated on ASA 2.
Looking over your config I don’t see anything out of the ordinary. I see four packets encapsulated on ASA1 and four packets decapsulated on ASA2 which seems to indicate that the ping has reached ASA2. The response however is not being sent, since there are zero encaps on ASA1 and zero decaps on ASA2.
The first thing I would consider here is routing, but I see that R2 is configured correctly with the default gateway, so it should be sending traffic correctly. The only other thing I can think of that you may want to check is MTU size on the interfaces, ensuring that frames aren’t being blocked.
You may also want to try to ping from R2 to R1 and see if you get any encaps/decaps incrementing or not. If not, then it is indeed an issue of sending traffic in that particular direction ASA2 --> ASA1.
Hopefully, this has given you some inspiration to continue your troubleshooting!
Recieve errors on an IKEv1 IPSec tunnel usually increase when one of the tests performed during the decapsulation of the ESP fails. These include:
Anti-replay out of window errors
Digest errors (packet corrupted)
Invalid decapsulation length/SA/protocol
Any other decapsulation failure
In order to determine in detail where the problem is, you can use various debug commands for IPSec including:
debug crypto ipsec
debug crypto isakmp
If it is an issue with ESP decapsulation, you should pick it up with the first of these debug commands. In the details of the debug you should see the reason for the recv error, and you can continue troubleshooting from there on.
Some helpful Cisco links that may aid in your troubleshooting include: