VPN Tunnel not connecting

mikhailtangier · ‎12-27-2011

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.

Marvin Rhoads · ‎12-27-2011

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"

mikhailtangier · ‎12-27-2011

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?

Marvin Rhoads · ‎12-27-2011

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)?

mikhailtangier · ‎12-27-2011

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)  , :  MM_DONE, EV_ERROR-->MM_WAIT_MSG2, EV_RETRY-->MM_WAIT_MSG2, EV_TIMEOUT-->MM_WAIT_MSG2, NullEvent-->MM_SND_MSG1, EV_SND_MSG-->MM_SND_MSG1, EV_START_TMR-->MM_SND_MSG1, EV_RESEND_MSG-->MM_WAIT_MSG2, EV_RETRY
Dec 13 09:54:00 [IKEv1 DEBUG]: IP = 198.179.147.37, IKE SA MM:e33bf376 terminating:  flags 0x01000022, refcnt 0, tuncnt 0
Dec 13 09:54:00 [IKEv1 DEBUG]: IP = 198.179.147.37, sending delete/delete with reason message
Dec 13 09:54:00 [IKEv1]: IP = 198.179.147.37, Removing peer from peer table failed, no match!
Dec 13 09:54:00 [IKEv1]: IP = 198.179.147.37, Error: Unable to remove PeerTblEntry

When they try the connection I see nothing and they see nothing on their end.

Marvin Rhoads · ‎12-27-2011

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.