IKEy no Likey NAT-T

I was recently drafted into help fix a VPN between a Fortigate in Azure and a good old fashioned on-prem ASA. The former had been deployed by some ARM templates and the latter had some config in place but ,it transpired, not enough.

Fixing it brought to light two issues. The first is my offering to the Googlesphere:

Issue One

Do you know that happy feeling when you paste an error into Google and get an exact hit? You click in high hopes of a quick solution and get to a forum where someone has posted the same issue you’re seeing and… had absolutely no responses. That initial elation gives way to realisation you’re going to have to actually do some troubleshooting yourself. Well, if you’ve seen the error below and got here, maybe not:

So back to the scenario described in the first paragraph, I had an IKEv2 issue which was was giving me an authentication error when running a debug on the ASA: (debug crypto ikev2 platform 255)

ike 0:xxx.vpn.yyy:31371: initiator received AUTH msg
ike 0:xxx.vpn.yyy:31371: received notify type AUTHENTICATION_FAILED

Non-matching PSKs? Don’t you get a specific error for that? Let’s check it anyway… still not workng… let’s change it on both firewalls… still not working…let’s take out those weird characters that we’ve used perfectly well before… OK, still doesn’t work… maybe it’s not the PSK.

When you run a debug you get a lot of information but the required clue was in there:

IKEv2-PLAT-2: tg_name set to: DefaultL2LGroupIKEv2-PLAT-2: tunn grp type set to: L2LIKEv2-PLAT-1: Failed to set P1 auth to build policy

The VPN did not have a tunnel group associated with it so was using the default one: DefaultL2LGroup. So why the authentication error?

When I checked on the CLI I got diddly….

But on the ASDM that group was set up as follows…

(There’s another column, not-shown, with IKEv2 similarily unticked) so essentially neither version of IKE was enabled hence the error). We fixed it by creating a tunnel-group for the VPN with IKE enabled.

Issue Two

Spoiler alert: this one doesn’t get fixed – it got worked round. We deployed with Ikev2 and then switched to ikev1 for reasons that will become clear

Let’s treat ourselves to a topology:

(I have recently bought an Ipad and Apple pencil and I can now wholly justify this purchase by being able to draw that VPN line on the diagram.)

So in the above set-up we’re running the VPN between the ASA and the Fortigate and the router R1 is doing NAT so our VPN will automatically detect this and use NAT-T so we’re all good, aren’t we? Yes and no. Using IKEv2 we get the VPN up but can only ping from one local subnet to one remote subnet so in effect the top virtual machine can only ping one loopback address. Whereas using IKEv1 which we can ping both loopbacks from either VM

Now, I didn’t really get a satisfactory answer why this was happening so determined to ouline what is seen and then maybe come back and update this if/when I do. I’ll also post the configs if anyone fancies trying this themselves. (The cipher suites are weak because the eval licences don’t allow strong ones)

So with IKEv1 – I can successfully ping both loopbacks:

and see the SAs on the ASA’s ASDM.

By comparion, using IKEv2, we can ping the first loopback…

But not the second and just see the one SA.

If we clear the tunnel and ping the second loopback first…we can now ping it but we can no longer ping the first one.

..and we now see an SA with the 20.20.20.0/24 subnet…

Debugging this from the Forti (diag debug app ike -1) this is an excerpt of what you see for the first child SA being formed: a proposal is chosen:

ike 0:To-ASA:23:sub2:26: matched proposal id 1
ike 0:To-ASA:23:sub2:26: proposal id = 1:
ike 0:To-ASA:23:sub2:26: protocol = ESP:
ike 0:To-ASA:23:sub2:26: encapsulation = TUNNEL
ike 0:To-ASA:23:sub2:26: type=ENCR, val=DES_CBC
ike 0:To-ASA:23:sub2:26: type=INTEGR, val=MD5
ike 0:To-ASA:23:sub2:26: type=ESN, val=NO
ike 0:To-ASA:23:sub2:26: PFS is disabled
ike 0:To-ASA:23:sub2:26: lifetime=43200
ike 0:To-ASA:23: responder preparing AUTH msg
ike 0:To-ASA:23: remote port change 500 -> 4500

In the second instance, it isn’t:

ike 0:To-ASA:23:sub4:27: proposal id = 2:
ike 0:To-ASA:23:sub4:27:   protocol = ESP:
ike 0:To-ASA:23:sub4:27:      encapsulation = TUNNEL
ike 0:To-ASA:23:sub4:27:         type=ENCR, val=DES_CBC
ike 0:To-ASA:23:sub4:27:         type=INTEGR, val=SHA
ike 0:To-ASA:23:sub4:27:         type=DH_GROUP, val=MODP1536
ike 0:To-ASA:23:sub4:27:         type=DH_GROUP, val=MODP2048
ike 0:To-ASA:23:sub4:27:         type=ESN, val=NO
ike 0:To-ASA:23:sub4:27: lifetime=43200
ike 0:To-ASA:23:sub4:27: no proposal chosen

And yet we know a proposal will be chosen there is no other Child SA in place.

I haven’t had time to see if this issue is just between the Forti and the ASA. I might try this Forti to Forti or try and understand the child SA creation process in greater detail than I currently do. If anybody reading this has encountered this issue and knows the explanation if they email be I’ll update the post but until then I guess it’s come back IKEv1, all is forgiven!