04-10-2008 05:07 AM - edited 03-03-2019 09:29 PM
Hi,
I have a Cisco ASA with a remote VPN to a Cisco router.
It seems the tunnel only comes up if I ping the remote router from the inside LAN of the ASA then both sides can ping each other.
However if for example the VPN tunnel is down and I ping from the remote network to a server on the inside of the ASA it won't come up again, I have to reverse this and get a server to ping this remote router and the IKE tunnel comes up and then the IPSec tunnel for that subnet.
Any idea?
Solved! Go to Solution.
04-10-2008 12:03 PM
First I would like to clarify something. I believe that I understand that when you initiate the VPN session from the ASA you are initiating traffic from a device behind the ASA and going to a device behind the router. Is this correct? I am not clear when you attempt to initiate the VPN session from the router whether you are pinging from a device behind the router or are pinging from the router itself. Can you clarify this?
Also in looking at the configs I do see some questionable things:
- the router has an ISAKMP key statement for 79.171.16.66 but the crypto map peer statement is for 81.171.156.66. what is this inconsistency? can it be cleaned up?
- the access list for crypto on the ASA is fairly specific there are 3 source subnets for destaintion 172.19.15.0. but the access list on the router says source 172.19.15.0 to anything. can you change the access list on the router so that it is 172.19.15.0 to 192.168.20.0, 192.168.21.0, or 192.168.90.0?
HTH
Rick
04-10-2008 05:21 AM
04-10-2008 07:56 AM
The debug output shows that it goes through Main Mode successfully and starts Quick Mode. Something in Quick Mode does not work and the session is not established. I would guess that there was some mismatch in configuration. Can you provide the configuration (at least the IPSeec parts) from both devices?
HTH
Rick
04-10-2008 11:26 AM
Hi Rick,
Here are the ipsec parts etc. Let me know if you need any more.
The remote network needs to communicate with 3 subnets (maybe more later). If I ping any servers on any of the 3 subnets from the remote network the the tunnel stays down. If I ping from any subnet on the inside of the ASA to a PC on the remote network then that PC can then talk to the whole subnet, almost like a one to one session.
The more subnets I can communicate with the more IPsec sessions increase too, is this right or should it be one IKE and one IPsec session per VPN (office)?
04-10-2008 12:03 PM
First I would like to clarify something. I believe that I understand that when you initiate the VPN session from the ASA you are initiating traffic from a device behind the ASA and going to a device behind the router. Is this correct? I am not clear when you attempt to initiate the VPN session from the router whether you are pinging from a device behind the router or are pinging from the router itself. Can you clarify this?
Also in looking at the configs I do see some questionable things:
- the router has an ISAKMP key statement for 79.171.16.66 but the crypto map peer statement is for 81.171.156.66. what is this inconsistency? can it be cleaned up?
- the access list for crypto on the ASA is fairly specific there are 3 source subnets for destaintion 172.19.15.0. but the access list on the router says source 172.19.15.0 to anything. can you change the access list on the router so that it is 172.19.15.0 to 192.168.20.0, 192.168.21.0, or 192.168.90.0?
HTH
Rick
04-11-2008 02:35 AM
Hi Rick, sorry for the delay.
Quote:
"I am not clear when you attempt to initiate the VPN session from the router whether you are pinging from a device behind the router or are pinging from the router itself. Can you clarify this?"
When I attempt to initiate the VPN from a device behind the remote router or on the router the tunnel won't come up, it only works from the inside of the ASA.
It's 79.171.16.66 and not 81.171.156.66.
I have added:
access-list 101 permit ip 172.19.15.0 0.0.0.255 192.168.20.0 0.0.0.255
access-list 101 permit ip 172.19.15.0 0.0.0.255 192.168.21.0 0.0.0.255
access-list 101 permit ip 172.19.15.0 0.0.0.255 192.168.90.0 0.0.0.255
But made no difference.
Thanks in advance Rick for your time spent on this.
04-11-2008 04:08 AM
04-11-2008 07:25 AM
Since the issue does not seem to be the access list I have looked again at the configs that you posted and I may see another issue. I see that the ASA does specify set pfs in its crypto map and that the router does not. I would suggest that you add set pfs to the crypto map on the router. Give it a try and let us know if it helps.
HTH
Rick
04-11-2008 10:01 AM
Hi Rick what is PFS? Sorry how would I add this, I'm not sure where to add it.
Many thanks
04-11-2008 10:37 AM
PFS is Perfect Forward Secrecy. It functions when the IPSec peers are negotiating new Security Associations when the prior SA is ending.
Try this for your config:
crypto map CBSO_Crypto_Map 10
set pfs
HTH
Rick
04-11-2008 11:32 AM
Hi Rick,
I had to add:
crypto map CBSO_Crypto_Map 10 ipsec-isakmp
Set pfs
Is this right?
I can't get back on this till later, will let you know.
It's strange as the config on the remote router works fine when pointing to our Cisco Concentrator, maybe the ASA works a little different?
04-11-2008 11:45 AM
I believe that what you added is right.
Perhaps the ASA does work a bit differently than the concentrator. It is quite possible that neither the router nor the concentrator was configured with set pfs and that the ASA was configured with it. If neither the router nor the concentrator were configured with set pfs then they would both work just fine.
I had not realized that there was also a concentrator. Would I be correct that the concentrator is existing equipment and that the ASA is being implemented to replace the concentrator? If that is the case then perhaps there is reason to question why set pfs was configured on the ASA. I guess that you could solve the issue by putting set pfs on the router (which I suggested) or you could solve the issue by removing set pfs from the ASA.
HTH
Rick
04-12-2008 02:38 AM
Hi Rick, I have tried with the PFS on and then without:
ASA:
no crypto map outside_map 1 set pfs
This tunnel still comes up from one way (the ASA side)
Can I give you anymore debug reports?
I see PFS is to do with DH group 5 that I am using? http://www.cisco.com/en/US/docs/ios/12_1t/12_1t3/feature/guide/dtgroup5.html#wp1022927
My VPN is DH5 also I don't seem to see a tunnel life time set anywhere is this an issue?
04-12-2008 06:57 AM
Hi Rick,
I think I have it working! I need to work out what has changed as I have changed so much, but I just went over what you said once again, so maybe I missed something.
Let me get back to you.
What I did add though was:
to the crypto map CBSO_Crypto_Map 10 ipsec-isakmp
I added:
set security-association lifetime seconds 28800
amended the SA to:
access-list 101 permit ip 172.19.15.0 0.0.0.255 192.168.20.0 0.0.0.255
access-list 101 permit ip 172.19.15.0 0.0.0.255 192.168.21.0 0.0.0.255
access-list 101 permit ip 172.19.15.0 0.0.0.255 192.168.90.0 0.0.0.255
set pfs group5 (which you mentioned)
I did also run a the SDM tool on the router and test the VPN and it recomemcnded I turn on add this command to the VPN interface:
"crypto ipsec df-bit clear"
I assumed it was the dialer 1, so addd it and ran the tool again and it still said I need to added it, so what internface or is it the ASA's side?
07-25-2023 04:42 AM
Hi James,
Could you please confirm if any of the endpoint doesn't happen to be the one having the Public Peer IP on the VPN endpoint? I simply intend to understand if NAT Traversal is happening and Public Peer IP of any of the side lies on any other device or not.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide