I we currently have a Remote tunnel VPN connection from the ASA at our Leicester site to an ASA in our Cardiff site.
I have a spare ASA router in Leicester which is already upgraded to version 9.1(3) which I have configured with the same settings from the original ASA's config, however when it's up the remote tunnel VPN won't connect.
Is this because it uses IKE v1 in v9.1(3) and not in the version at our Cardiff end, which is running 7.2(2)?
Do we need the ASA's at both ends to be running the same version for the remote tunnel VPN to work properly?
Not that I am aware of but it can cause issue when a version supports for example encryption algorithm that is not supported on an older version and you configure your tunnel using that encryption algorithm.
Having that said, do you know whether it's failing on phase 1 or 2? Try enabling debug crypto commands to see what's it missing. Here I am assuming that you are configuring s2s vpn tunnel between those two ASAs.
Yes that's correct it is a site-to-site vpn tunnel between the two ASA's.
I have no idea which phase it's failing on. Is it possible to setup an additional s2s vpn tunnel with a different PSK to test it?
At the moment I am having to turn on the upgraded ASA and disconnect the existing one and the vpn tunnel in order to test it, surely there's a better way?
I have now got the upgraded ASA up and I've ran through the S2S vpn wizard on both the local ASA (version 9.1) and the remote ASA (running 7.2), but the tunnel won't connect.
I have ensured that the NAT exemption was ticked and that they both have the same PSK.
Do you have any ideas??
A couple of troubleshooting steps are commonly used.
First review the configuration to confirm the setup is fine (tunnel-groups defined on both ends, cryptomaps associated and access-lists mirroring each other, NAT exemption setup properly etc.).
Then you should introduce interesting traffic from one end and see what the ASA does. i.e ping from a host (not from the ASA itself) on the allowed network at one end to a host at the other end. When you do this, check the ASA ISAKMP phase 1 Security Associations (SAs) with "show crypto isakmp sa". Proper operation will result in the tunnel coming up in Main Mode ("MM" in the status). If that doesn't happen then turn on debug (debug cry isa 7) and repeat, examine the syslog for the failure message which should have details on what failed.
If Phase 1 established but traffic doesn't pass, move to Phase 2 - "show crypto ipsec sa". You should see "encaps" and "decaps" increment when you send the test traffic (packets being encapsulated and return traffic begin decapsulated from IPsec). You might check this at both ends. Sometimes the VPN is fine but internal routing at one end doesn't send the traffic back to the ASA.
Check that out and we can go from there.
I have tried what you've suggested and i'm receiving the following:
"There are no IKEv1 SAs"
"There are no IKEv2 SAs"
OK - so following through with what I suggested, debug and examine the log output for the message indicating the failure.
If phase 1 isn't establishing (and assuming the interesting traffic packets are being presented to the ASA) then the most likely issues are either pre-shared key mismatch or no common algorithms configured on each peer. Either will show up in a debug log output.
There is a good more comprehensive troubleshooting guide here that you may want to refer to.
The current setup is likely to make this more difficult I think, so let me explain how i'm testing at present to see if you can help me to figure a better way.
Currently we have our original ASA's both running version 7.2 both locally and at the remote site and the S2S tunnel is connected so that the remote site are able to connect to the internet and our LAN.
Then I have a separate upgraded ASA on the local site, which i've been trying to setup an S2S tunnel to the same remote ASA as the other local router.
Is it possible to have 2 S2S tunnels running to the same ASA?
I have tried different methods of configuring the tunnel, using both the CLI and the ASDM wizard, but neither seem to have any success. I am finding it tough due to the different versions as one ASA has different options (in the ASDM) and different commands (in the CLI).
What do you think would be the best way to test out getting a S2S tunnel working between the upgraded local ASA and the remote ASA?
Ah, trying to get that to work simultaneously will be a bit tricky.
It's not an issue to have two site-site VPNs in a given ASA - I've run ASAs with a dozen active. HOWEVER, they all go to unique remote nettworks.
In you case you want your local site to have two ASAs (old and new) going to the same remote ASA. That's going to be an issue with both the routing and the remote ASA's cryptomaps. You'd have to separate out a subset of traffic (a subnet or even single host) at each end to test with. It would need to have routing setup at your local site to force it into the new ASA.
Then the remote site ASA would need to have the VPN setup to protect only that subnet or host. Otherwise, the "return" traffic would not know to use the new site-site VPN because the existing VPN already has IPsec SAs covering the network you are wanting to move to the new VPN.
Hope that makes sense - it's a bit complicated.
Usually we handle this sort of transition with a hot cutover - move all the traffic to the new ASA that has the same addressing as the old one.
I had initially tried turning off the old local ASA and switching to the new one, after copying the configuration of the old one to it, which I thought would automatically configure the Site-Site tunnel, however when I found that the tunnel wasn't working, I simply switched the new one off and the old ASA back on again so our remote site could get back online.
So If I could ensure that the tunnel was working, a hot cutover would be ideal.