I was debugging a VPN tunnel today. (From a Fortigate to a Cisco ASAv). I was messing around with the encryption and hashing, when the tunnel fell over. Phase 1 was establishing fine but not Phase 2 (IPSEC).
I’ve got better skills on the ASA, so that’s where I was debugging;
[box]
IPSEC: Received a PFKey message from IKE
IPSEC: Parsing PFKey GETSPI message
IPSEC: Creating IPsec SA
IPSEC: Getting the inbound SPI
IPSEC DEBUG: Inbound SA (SPI 0x00000000) state change from inactive to embryonic
IPSEC: New embryonic SA created @ 0x00007fc98613ea60,
SCB: 0x85567700,
Direction: inbound
SPI : 0x3B5A332E
Session ID: 0x00004000
VPIF num : 0x00000002
Tunnel type: l2l
Protocol : esp
Lifetime : 240 seconds
IPSEC: Received a PFKey message from IKE
IPSEC DEBUG: Received a DELETE PFKey message from IKE for an inbound SA (SPI 0x3B5A332E)
IPSEC DEBUG: Inbound SA (SPI 0x3B5A332E) destroy started, state embryonic
IPSEC: Destroy current inbound SPI: 0x3B5A332E
IPSEC DEBUG: Inbound SA (SPI 0x3B5A332E) free started, state embryonic
IPSEC DEBUG: Inbound SA (SPI 0x3B5A332E) state change from embryonic to dead
IPSEC DEBUG: Inbound SA (SPI 0x3B5A332E) free completed
IPSEC DEBUG: Inbound SA (SPI 0x3B5A332E) destroy completed
[/box]
Solution
Google that error and you get some posts about NAT, that we’re not applicable to me. I took a look on the Fortigate and the only clue there was;
sa=0 There is a mismatch between selectors (or no traffic is being initiated). sa=1 IPsec SA is matching and there is traffic between the selectors. sa=2 Only seen during IPsec SA rekey
So I went back to basics and checked the Phase 2 on BOTH, firstly the Fortigate;
For the uninitiated: GCM Protocols DON’T require a hashing algorithm, (that’s why you can’t see SHA or MD5 on there), they disappear when a GCM protocol is selected.
Then on the Cisco ASA;
[box]
Cisco-ASA(config-ipsec-proposal)# show run crypto ipsec
crypto ipsec ikev2 ipsec-proposal FORTIGATE
protocol esp encryption aes-gmac-256
protocol esp integrity null <--Note: This can say anything it gets ignored!
THE ANSWER IS STARING YOU/ME IN THE FACE. I just didn’t realise yet, I changed the phase 2 protocols to DES/MD5 and the tunnel came up, I walked up through the protocols and options and discovered what I’d done wrong.
Root Cause: The ASA is set to use AES-GMAC-256 that’s a DIFFERENT PROTOCOL to the AES256GCMconfigured on the Fortigate! The ASA should be set to AES-GCM-256! (So the Phase 2 proposals didn’t match).
Continuing with my ‘Learn some Fortigate‘ theme’. One of the basic requirements of any edge firewall is site to site VPN. As the bulk of my knowledge is Cisco ASA it seems sensible for me to work out how to VPN both those firewalls together, like so;
Well that’s the pretty picture, I’m building this EVE-NG so here’s what my workbench topology looks like;
Disclaimer (Read First! Especially before posting any comments!)
Fortinet prides itself on you not needing to use the CLI, (until you actually need to use the CLI of course!) But both ends are configured using the GUI and ASDM. This is designed for the ‘Let’s just make it work, who cares what’s going on under the hood‘ generation. Which means it enables IKEv1NOTIKEv2 on the Fortigate, and BOTH IKEv1 and IKEv2 gets enabled on the Cisco ASA. Couple that with all the weak Crypto sets that get enabled, because someone might have a hardware firewall from 1981 or something! So in production I’d consider doing things a little more manually. I will post another article on the same subject, but then I’ll make the tunnel as secure as I can, (watch this space). This is an exercise in getting the tunnel up and making it work.
Tech Note: If you just use both wizards it wont work, thankfully I could debug the tunnel on the Cisco ASA to work out why. Fortinet sets all the DH groups to 5, and Cisco sets them all to 2. And Fortinet enables PFS and Cisco don’t. (They do on older versions of the OS, but not on the newer ones).
Create IKE/IPSec VPN Tunnel On Fortigate
From the web management portal > VPN > IPSec Wizard > Give the tunnel a name > Change the remote device type to Cisco > Next.
Give it the ‘public’ IP of the Cisco ASA > Set the port to the ‘outside’ port on the Fortigate > Enter a pre-shared key, (text string, you will need to enter this on the Cisco ASA as well, so paste it into Notepad or something for later) > Next.
Local interface will be in the ‘inside’ interface on the Fortigate > Enter the local subnet(s) > Enter the remote (behind the ASA) subnet(s) > Next.
Review the settings > Create.
Select IPSec Tunnels > Select the new tunnel > Edit.
Connect to the ASDM > Wizards > VPN Wizards > Site-to-Site VPN Wizard > Next.
You should already have an object for your Local Network add that in > Then add in a new Network Object for the remote (behind the Fortigate) subnet. MAKE SURE that the new object is selected as the Remote Network > Next.
Enter the Pre-Shared key you used (above) > Next > Tick to DISABLENAT > Next > Finish.
Tech Note: Look at all those Ciphers/Hashing/Additional Protocols that are about to be turned on! 🙁 That’s why I work at command line.
Finally you will need to send some traffic over the tunnel to ‘bring it up’.
If you have a problem, see the debugging/troubleshooting links below.
Related Articles, References, Credits, or External Links
But if you want to use the native Windows VPN client you can still use L2TP over IPSEC. I had a look around the net to work out how to do this and most decent articles are written using the older versions of the ASDM, and the CLI information I found on Cisco’s site didn’t help either.
What I’m using
1. Cisco ASA5525 version 9.2(4) and ASDM version 7.6(1).
2. Network behind the ASA 192.168.110.0/24.
3. IP addresses of the remote clients 192.168.198.1 to 254 (DNS 192.168.110.10).
Configure the ASA 5500 for L2TP IPSEC VPNs from ASDM
1. From within the ASDM > Wizards > VPN Wizards > IPSec (IKEv1) Remote Access VPN Wizard)
2. Next.
3. Tick Microsoft Windows Client using L2TP over IPSEC > Tick MS-CHAP-V2 ONLY > Next.
4. Type in a pre-shared key > Next.
5. Select LOCAL authentication > Next.
6. Enter a username/password to use for connection to the VPN > Next.
7. Create a ‘VPN Pool‘ for the remote clients to use as a DHCP pool > OK > Next.
8. Enter your internal DNS server(s) and domain name > Next.
9. Set your internal network(s) > Tick “Enable Split tunnelling…” > Untick PFS > Next.
10. Finish.
11. Save the changes.
Configure the ASA 5500 for L2TP IPSEC VPNs from CLI
1. Connect to the ASA, go to “enable mode”, then to “Configure terminal mode”
[box]
User Access Verification
Password:
Type help or '?' for a list of available commands.
PetesASA> enable
Password: ********
PetesASA# configure Terminal
PetesASA(config)#
[/box]
2. First we need to create a “Pool” of IP addresses for the remote client to use.
[box]
PetesASA(config)# ip local pool L2TP-Pool 192.168.198.1-192.168.198.10
[/box]
3. Now to make sure the traffic that’s going to travel over our VPN is not NATTED.
Note: This is assuming that 192.168.100.0/24 is the remote VPN clients subnet, and 10.254.254.0/24 is the subnet BEHIND the ASA.
4. Normally when a remote client is connected they will lose all other connections (including their other internet connections) while connected, to stop this you need to enable “Split Tunnelling“. You will refer to this later but for now we just need to create an ACL.
[box]
PetesASA(config)# access-list Split-Tunnel-ACL standard permit 192.168.110.0 255.255.255.0
[/box]
5. We need a “Transform Set” that will be used for “Phase 2” of the tunnel, I’m going to use AES encryption and SHA hashing, then set the transform type to “Transport”.
6. Remote VPNs usually use a “Dynamic Cryptomap”, the following will create one that uses our transform set, then applies that to the firewalls outside interface.
7. Then enable IKE (version 1) on the outside interface. And create a policy that will handle “Phase 1” of the tunnel, in this case 3DES for encryption, and SHA for hashing, and Diffie Hellman group 2 for the secure key exchange.
8. Create a group policy, that hold the following, DNS server IP(s) that will be leased to the remote clients. Tunnel type (L2TPIPSEC), enable spit tunnelling using the ACL we created in step 4. The domain name that will be given to the remote clients. The “intercept-dhcp enable” looks after a Windows client problem. And finally create a user and password.
Note: In this example I’m using the ASA’s local database of users for authentication.
9. Every tunnel needs a “Tunnel Group”, You HAVE TO use the DefaultRAGroup (Unless you are securing things with certificates which we are not). This pulls in the IP Pool we created in step 2 and the policy we created in step 8.
10. For the tunnel group, setup a shared key, and the authentication method for our clients.
Note: We are disabling CHAP and enabling MSCHAP v2.
[box]
PetesASA(config-tunnel-general)# tunnel-group DefaultRAGroup ipsec-attributes
PetesASA(config-tunnel-ipsec)# ikev1 pre-shared-key 1234567890
PetesASA(config-tunnel-ipsec)# tunnel-group DefaultRAGroup ppp-attributes
PetesASA(config-ppp)# no authentication chap
PetesASA(config-ppp)# authentication ms-chap-v2
[/box]
11. Finally save the new config.
[box]
PetesASA# write mem
Building configuration...
Cryptochecksum: 79745c0a 509726e5 b2c66028 021fdc7d
7424 bytes copied in 1.710 secs (7424 bytes/sec)
[OK]
PetesASA#
[/box]
Configure Windows VPN client for L2TP IPSEC connection to Cisco ASA 5500
Note: Windows 10 Enterprise used.
1. Start > Settings > Network and Internet.
2. VPN > Add a VPN Connection.
3. VPN Provider = Windows (Built-in) > Connection Name = (A Sensible name) > Server name or Address = Public IP/Hostname of the ASA > Scroll Down.
4. VPN Type = L2TP/IPSEC with pre-shared key > Pre Shared Key = {the one you set on the firewall in our example 1234567890} > Type of sign-in information = Username and Password.
Note: You may want to untick “Remember my sign-in information” To supply a username and password each time.
5. Start > ncpa.cpl {Enter} > Right click your VPN connection profile > Properties..
6. Security Tab > Allow These Protocols > Tick “Microsoft CHAP version 2 (MS-CHAP v2)” > OK.
7. You can now connect your VPN.
Related Articles, References, Credits, or External Links
A colleague was doing a firewall migration yesterday and I offered to sit in, in case he had any problems, one of the tasks was a VPN tunnel getting migrated, this is usually painless, (if you have control of both ends!) But in this case we didn’t, and it’s usually the case, when there’s VPN problems, the people at the {ahem} ‘less experienced,’ end of the tunnel tend to blame the other end.
I asked if we could get on the client’s servers to set up a constant ping, (to force the tunnel up as soon as the far side had changed peer ip addresses). But we couldn’t, I was asked ‘Can we not bring the tunnel up from the ASA?’
Solution
Note: To save people emailing me to ask, the above is virtualised using EVE-NG in VMware ESX.
Well, yes you can do this, BUT there are some caveats,
The inside IP of the ASA needs to be part of the ACL that declares ‘interesting traffic’ i.e. the one matched in the crypto map.
The inside IP o the ASA needs to also be in the nat exemption for the VPN traffic.
‘Management-access inside‘ needs to be enabled in the config, (so traffic can be sourced from it).
Then, (assuming 192.168.1.10 is an IP address at the far-end of the VPN tunnel), use the following syntax;
[box]
ping inside192.168.1.10
[/box]
Note: This assumes your inside interface is called ‘inside‘, yours may be called LAN, or Inside, or something else.
Well my IP is on a different range to the inside interface, or I can’t enable management-access inside, and/or my IPs are not in the nat exemption! Jeez there’s always one! Well in your case you can simulate VPN traffic to bring the tunnel up, with packet-tracer, like so;
Note: This assumes 172.16.1.1 is at YOUR site and 192.168.1.10 is at the OTHER site, and you interesting traffic ACL permits TCP port 80, (most of them permit all ports but you may be in a more secure environment so check).
Related Articles, References, Credits, or External Links
Saw this in a forum today, and knew what it was straight away! While attempting to get a VPN tunnel up from a Cisco ASA (5508-x) to a Sonicwall firewall this was there debug output;
[box]
Apr 06 00:45:21 [IKEv1]IP = x.x.x.x, IKE Initiator: New Phase 1, Intf Lan, IKE Peer x.x.x.x local Proxy Address 192.168.90.150, remote Proxy Address 10.252.1.1, Crypto map (Internet_map)
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, constructing ISAKMP SA payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, constructing Fragmentation VID + extended capabilities payload
Apr 06 00:45:21 [IKEv1]IP = x.x.x.x, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + NONE (0) total length : 340
Apr 06 00:45:21 [IKEv1]IP = x.x.x.x, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + NONE (0) total length : 96
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, processing SA payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, Oakley proposal is acceptable
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, processing VID payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, constructing ke payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, constructing nonce payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, constructing Cisco Unity VID payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, constructing xauth V6 VID payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, Send IOS VID
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, Constructing ASA spoofing IOS Vendor ID payload (version: 1.0.0, capabilities: 20000001)
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, constructing VID payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, Send Altiga/Cisco VPN3000/Cisco ASA GW VID
Apr 06 00:45:21 [IKEv1]IP = x.x.x.x, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 320
Apr 06 00:45:21 [IKEv1]IP = x.x.x.x, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 272
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, processing ke payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, processing ISA_KE payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, processing nonce payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, processing VID payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, processing VID payload
Apr 06 00:45:21 [IKEv1 DEBUG]IP = x.x.x.x, Received xauth V6 VID
Apr 06 00:45:21 [IKEv1]IP = x.x.x.x, Connection landed on tunnel_group x.x.x.x
Apr 06 00:45:21 [IKEv1 DEBUG]Group = x.x.x.x, IP = x.x.x.x, Generating keys for Initiator...
Apr 06 00:45:21 [IKEv1 DEBUG]Group = x.x.x.x, IP = x.x.x.x, constructing ID payload
Apr 06 00:45:21 [IKEv1 DEBUG]Group = x.x.x.x, IP = x.x.x.x, constructing hash payload
Apr 06 00:45:21 [IKEv1 DEBUG]Group = x.x.x.x, IP = x.x.x.x, Computing hash for ISAKMP
Apr 06 00:45:21 [IKEv1 DEBUG]Group = x.x.x.x, IP = x.x.x.x, constructing dpd vid payload
Apr 06 00:45:21 [IKEv1]IP = x.x.x.x, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + ID (5) + HASH (8) + VENDOR (13) + NONE (0) total length : 110
Apr 06 00:45:29 [IKEv1]IP = x.x.x.x, IKE_DECODE RECEIVED Message (msgid=c0ea3190) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 220
Apr 06 00:45:29 [IKEv1]IP = x.x.x.x, IKE_DECODE RECEIVED Message (msgid=c0ea3190) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 220
Apr 06 00:45:29 [IKEv1]Group = x.x.x.x, IP = x.x.x.x, Received an un-encrypted INVALID_COOKIE notify message, dropping
[/box]
Solution
So we can see phase 1 (ISAKMP v1) isn’t establishing, I’ve seen this happen before, you need to get the ASA to specify its IP address as its identification.
You want to establish a site to site VPN from a site with a Cisco ASA firewall, to another site running a Juniper SRX firewall. I had to do this this week, and struggled to find any good information to help.
In the example below I’m configuring the whole thing from a laptop (172.16.254.206) that’s on the Juniper’s site. Use the diagram below, and substitute your own IP addresses and subnet addresses, to get a workable solution for your site.
When the process is complete, I will test it by pinging the host behind the Cisco ASA on the remote site (10.254.254.5).
Solution
Before you begin, I will assume both firewalls are functioning properly and the clients behind them can access internet services (where allowed) through them already.
5. Enter the Local (behind the ASA) network > Then the Remote (behind the Juniper) network > Next.
Note: You can type them in, but if you use the pick-list button you can select ‘inside-network’ for the local, and define a network object for the remote network.
6. Enter a pre shared key, (remember this, you need to enter it on the Juniper).
8. Enable PFS > Tick the box to exempt traffic from NAT > Next.
9. Review the settings > Finish
11. Save the changes > File > Save running Configuration to Flash.
Step 2 – Configure the Juniper SRX (Route Based VPN)
Model used SRX100B version 11.2R4.3
The SRX support two types of VPN
Route based VPN – VPN selection is done based on the route. In this you define a route pointing to the tunnel interface (st0 interface) bound to the VPN.
Policy based VPN – VPN is selected based on the policy.
15. Give the tunnel a name > Set the local zone to trust > Add in the local subnet (behind the Juniper) > Name the Secure Tunnel Interface (just put in a zero) > Set the secure tunnel zone to Untrust > Enter the physical address the VPN will be terminating on, (usually the fe0/0/0.0 interface, but it does not have to be) > Next.
Note: On the Juniper, when specifying a subnet use the short subnet notation, i.e. 192.168.1.0 255.255.255.0 would be 192.168.1.0/24 (if you get stuck use my subnet calculator).
16. Supply the public IP address of the ASA > and add in the subnet at the far end of the tunnel (behind the ASA) > Next.
17. Set the IKE (phase 1) settings to Compatible, Main Mode, enter the same pre shared key you setup in Step 1 (number 6) > Set the IPSEC (phase 2) settings to Compatible, IPsec Perfect Forward Secrecy (PFS) to group 2 > Next.
20. Navigate to IPsecVPN > Auto Tunnel > Phase II > Select your tunnel > Edit > IPsecVPN Options > Tick ‘use proxy identity’ > Enter the local and remote subnets > OK.
21. Navigate to Security > Zones/Screen > Select the untrust zone > Edit > Host Inbound traffic – Interface > Select the physical address that the VPN is terminating on (usually fe-0/0/0.0) > Add IKE as an Interface service > OK.
22. To save the changes > Action > Commit.
23. Test the VPN by attempting to ping a host on the other end.
Juniper SRX Command Line
On the Cisco firewalls I prefer to work at command line. The Juniper Firewall also supports CLI, you can check the VPN config with the following commands;
If you want you can execute the below commands on CLI to get the “set” commands
show security ike | display set
show security ipsec | display set
show | display set | match <external interface configured in ike>
show | display set | match <st.x>
Above commands will give you the “set” commands for cli.
Related Articles, References, Credits, or External Links
Special thanks to Kalanidhi Tripathi at JTAC for his assistance.