cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1918
Views
20
Helpful
10
Replies

Peers Unable to Connect - No active Site-to-Site VPNs

Huddles18
Level 1
Level 1

I have 2 site-to-site VPNs on our ASA with a couple of vendors. One of them informed me yesterday that they are no longer able to access the resources they need.

 

When I look up the vpn summary, I see this:

Site-to-Site VPN             :      0 :        162 :           2
  IKEv2 IPsec                :      0 :         95 :           1
  IKEv1 IPsec                :      0 :         67 :           1

It's fair to say that both of the tunnels are not being used at the moment.

 

I also ran

show crypto ipsec sa detail

And I did not receive anything. I also did this for ikev1 and ikev2. Did not receive any information.

Even though that was empty, I put in:

clear crypto ipsec sa peer IP_ADDRESS

I am able to ping the remote peer, but this S2S tunnel not designed for me to access anything, but for our vendor to access some of our resources.

 

Here is my crypto map for this connection:

crypto map Outside_map 3 match address Outside_cryptomap_6
crypto map Outside_map 3 set peer REMOTE_PEER
crypto map Outside_map 3 set ikev1 transform-set ESP-AES-256-SHA
crypto map Outside_map 3 set ikev2 ipsec-proposal AES256-SHA1

 

I am also concerned that this may have had something to do with the recent global CenturyLink outage that happened on Aug 30. It seemed to have timed up with this issue.

 

Is there I way I can test this connection since I don't have any access to the remote peer? Or maybe just reset the connection somehow? Not too sure where I can go from here.

 

Thanks for your time!

1 Accepted Solution

Accepted Solutions

Interesting, yes, this does point to either an issue on your end or the ISP.

 

Are all IPSec VPNs down?

 

Perhaps take a packet capture on the outside interface (filter on source IP addresses of the VPNs that are down) and run some tests with the vendors, to determine whether the isakmp/ipsec traffic even gets through to your firewall. If not could the ISP be blocking udp/500 and esp?

View solution in original post

10 Replies 10

Hi,

Do you mean to say that your ASA is configured to respond only and the peer must intiate to establish the VPN? In which case then the peer will need to generate some interesting traffic in order to establish the tunnel, if they aren't generating traffic the tunnel won't be built.

 

If they do generate traffic and the tunnel still doesn't establish, you can run a packet capture on your ASA to confirm inbound iskamp packets (udp/500) and/or run a debug of "debug crypto ikev1" or "debug crypto ikev2".

 

HTH

Hey Rob,

 

Yes, that is exactly what I mean. I figured that was going to be the problem. I just don't have any access to any of their resources to pass traffic to.

 

I will give that a shot with the peer hopefully today, and report back! Thanks for the suggestion.

Alright,

 

So I got in contact with them, and they were sending ICMP packets to one of our internal resources. I ran a packet capture, and I also setup debug for

  • ipsec
  • ikev1
  • ikev2
  • isakmp

All of which didn't give me any messages, which is really strange.

 

We did confirm that we were able to ping both of our public IP addresses though.

The ASA is in our DC where they did some re-configuring to their core routing because of the CenturyLink outage yesterday. I'm going to reach out to them and see if there's something on that end.

 

It's just really weird that I'm not even getting a debug message.

I have them running a consistent ping to an internal resource, so hopefully that will be enough to continue to test.

If the peer is initating traffic and no debug output is generated, then is the vendor sending traffic from the correct source IP address as defined in the crypto ACL? If they are pinging from their router/firewall than that IP address may not necessarily be included in the crypto ACL and thus not even attempt to setup a VPN on their end (which would explain why you'd never see any output in the debugs).

Ah, that makes sense. I have 2 internal vendor subnets on the crypto ACL, and am trying to confirm they are using that, but you're saying to add their public remote peer IP to the ACL as well?

No I wasn't necessarily saying to add their public IP address. If they were testing from their firewall, traffic would be sourced from the public IP address and not match the crypto ACL. Just get them to double check which IP address they are testing from.

Got you. I am waiting on a response from them.

I just got a call from another vendor saying that they are also unable to connect to their S2S VPN as well.

This is telling me it's either an ISP issue, or something broke on our ASAs.

Interesting, yes, this does point to either an issue on your end or the ISP.

 

Are all IPSec VPNs down?

 

Perhaps take a packet capture on the outside interface (filter on source IP addresses of the VPNs that are down) and run some tests with the vendors, to determine whether the isakmp/ipsec traffic even gets through to your firewall. If not could the ISP be blocking udp/500 and esp?

Hey Robert,

 

Looks like it was an ISP issue. I didn't get an explanation, but as soon as I submitted a ticket to them, they noticed a problem and ask me to test, upon which, everything seemed to come back online.

 

Once that was confirmed to be a good tunnel, I made sure to change the group policies of my tunnels, so that the timeouts were set to zero. I believe this will make it easier for me to monitor these in the future.

It's just weird that this all happened the same time the CenturyLink outage occurred.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: