08-31-2020 06:17 AM
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!
Solved! Go to Solution.
09-01-2020 11:11 AM
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?
08-31-2020 06:32 AM
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
08-31-2020 07:25 AM
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.
08-31-2020 09:04 AM
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
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.
08-31-2020 09:44 AM
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).
09-01-2020 05:43 AM
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?
09-01-2020 06:12 AM
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.
09-01-2020 11:00 AM
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.
09-01-2020 11:11 AM
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?
09-03-2020 05:28 PM
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.
09-01-2020 11:01 AM
It's just weird that this all happened the same time the CenturyLink outage occurred.
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