12-27-2011 08:31 AM
Our internet connection changed and so did our public IP addresses, I'm trying to re-establish our VPN tunnel with our client, but we haven't be able to get the connection back up even though only 2 IP addresses have changed. Below is my ASA's config file
Our WAN from the ISP is: 65.xx.xxx.104/30 and our LAN is: 67.xxx.xxx.128/27, I'm trying to use: 65.xx.xxx.106 as the endpoint and 67.xxx.xxx.130 as the host via the tunnel.
So what am I doing wrong? Thanks.
12-27-2011 09:18 AM
Per your posted configuration, your VPN client should be attempting to establish the tunnel to the address of the ASA's outside interface = 67.152.128.130. It is set to use local authentication (e.g. pre-defined users). If it succeeds it should be given an address from "ip local pool gspvpnpool 172.16.65.1-172.16.65.254"
12-27-2011 09:26 AM
Thanks for replying.
Isn't that different then the tunnel connection? We did have VPN clients connecting with RADIUS authentication, which we don't need at the moment. This tunnel was working fine before we changed IP addresses on our external LAN/WAN.
Isn't 67.152.128.130 just the address the other side of the tunnel should be expecting, not the endpoint?
12-27-2011 09:38 AM
Sorry, terminology misunderstanding. When you said 'client' I assumed client PC, e.g. someone running Cisco VPN Client software. Are you meaning 'client' as in business client (or 'peer' in VPN terminology).?
In VPN terminology, 'endpoint' usually refers to the endpoint of a tunnel - either site to site or remote pc to site / VPN concentrator. So your endpoint is your public IP.
You also currently have the cryptomap 'gspvpnmap' for site-site VPN applied on your outside interface. The remote peer for that site-site VPN is 198.179.147.37. Have they updated their configuration to reflect your new IP address (67.152.128.130)?
12-27-2011 10:05 AM
Yes it is a business client. The tunnel is site to site. The network is like this:
Our ASA <---->ISP's router<------>Client's VPN concentrator
The client says they have changed the IPs and made the appropriate changes to their firewall. When I try to debug the connection on our end this is what is looks like:
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: | Dec 13 09:53:28 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0 Dec 13 09:53:28 [IKEv1]: IP = 198.179.147.37, IKE Initiator: New Phase 1, Intf inside, IKE Peer 198.179.149.37 local Proxy Address 67.152.128.130, remote Proxy Address 151.149.117.15, Crypto map (gspvpnmap) Dec 13 09:53:28 [IKEv1 DEBUG]: IP = 198.179.147.37, constructing ISAKMP SA payload Dec 13 09:53:28 [IKEv1 DEBUG]: IP = 198.179.147.37, constructing NAT-Traversal VID ver 02 payload Dec 13 09:53:28 [IKEv1 DEBUG]: IP = 198.179.147.37, constructing NAT-Traversal VID ver 03 payload Dec 13 09:53:28 [IKEv1 DEBUG]: IP = 198.179.147.37, constructing Fragmentation VID + extended capabilities payload Dec 13 09:53:28 [IKEv1]: IP = 198.179.147.37, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 184 Dec 13 09:53:29 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0 Dec 13 09:53:29 [IKEv1]: IP = 198.179.147.37, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete. Dec 13 09:53:30 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0 Dec 13 09:53:30 [IKEv1]: IP = 198.179.147.37, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete. Dec 13 09:53:31 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0 Dec 13 09:53:31 [IKEv1]: IP = 198.179.147.37, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete. Dec 13 09:53:32 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0 Dec 13 09:53:32 [IKEv1]: IP = 198.179.147.37, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete. Dec 13 09:53:33 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0 Dec 13 09:53:33 [IKEv1]: IP = 198.179.147.37, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete. Dec 13 09:53:34 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0 Dec 13 09:53:34 [IKEv1]: IP = 198.179.147.37, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete. Dec 13 09:53:35 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0 Dec 13 09:53:35 [IKEv1]: IP = 198.179.147.37, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete. Dec 13 09:53:36 [IKEv1]: IP = 198.179.147.37, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 184 Dec 13 09:53:36 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0 Dec 13 09:53:36 [IKEv1]: IP = 198.179.147.37, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete. Dec 13 09:53:37 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0 Dec 13 09:53:37 [IKEv1]: IP = 198.179.147.37, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete. Dec 13 09:53:44 [IKEv1]: IP = 198.179.147.37, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 184 Dec 13 09:53:52 [IKEv1]: IP = 198.179.147.37, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 184 Dec 13 09:54:00 [IKEv1 DEBUG]: IP = 198.179.147.37, IKE MM Initiator FSM error history (struct &0x464e5b8) |
When they try the connection I see nothing and they see nothing on their end.
12-27-2011 10:40 AM
Yes, IKE Phase 1 is not completing successfully when you initiate.
The troubleshoting guide (here) recommends checking the ISAKMP policies but given that you had this previously established successfully, they should be OK.
Given that you see NOTHING when they try to initiate I would strongly suspect they have not changed your peer ID (i.e., your new public IP address) properly at their end.
Hope this helps.
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