Cisco ASA: Received a DELETE PFKey message from IKE

KB ID 0001720

Problem

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;

[box]

Forti-FW # diagnose vpn tunnel list
list all ipsec tunnel in vd 0
------------------------------------------------------
name=Tunnel-To-SiteB ver=2 serial=1 192.168.100.100:0->192.168.100.111:0 dst_mtu=1500
bound_if=4 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/512 options[0200]=frag-rfc  run_state=0 accept_traffic=0 overlay_id=0

proxyid_num=1 child_num=0 refcnt=14 ilast=1 olast=782 ad=/0
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=Tunnel-To-SiteB proto=0 sa=0 ref=1 serial=2
  src: 0:192.168.1.0/255.255.255.0:0
  dst: 0:172.16.1.0/255.255.255.0:0
run_tally=1

[/box]

There’s not much I can discern from that either; 

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!

[/box]

Or if you prefer the ASDM;

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 AES256GCM configured on the Fortigate! The ASA should be set to AES-GCM-256! (So the Phase 2 proposals didn’t match).

[box]

Cisco-ASA(config)# crypto ipsec ikev2 ipsec-proposal FORTIGATE
Cisco-ASA(config-ipsec-proposal)# protocol esp encryption aes-gcm-256
WARNING: GCM\GMAC are authenticated encryption algorithms.esp integrity config is ignored

[/box]

Or, via ASDM (from the same location as above);

Problem solved!

Related Articles, References, Credits, or External Links

NA

Fortigate to Cisco ASA Site to Site VPN

KB ID 0001717

Problem

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 IKEv1 NOT IKEv2 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.

Convert to Custom Tunnel.

Phase 1 Proposal > Edit.

Add in Diffie Hellman Group 2

Phase 2 Selectors > Edit > Advanced > Untick Enable Perfect Forward Secrecy > OK.

Create IKE/IPSec VPN Tunnel On Cisco ASA (ASDM)

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 DISABLE NAT > 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

Troubleshooting Phase 1 Cisco Site to Site (L2L) VPN Tunnels

Troubleshooting Phase 2 Cisco Site to Site (L2L) VPN Tunnels

Cisco ASA – L2TP over IPSEC VPN

KB ID 0000571

Problem

Note: This is for Cisco ASA 5500, 5500-x, and Cisco Firepower devices running ASA Code.

When Cisco released version 7 of the operating system for PIX/ASA they dropped support for the firewall acting as a PPTP VPN device.

Note: If you want to use PPTP you can still terminate PPTP VPNs on a Windows server, if you enable PPTP and GRE Passthrough on the ASA.

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).

4. Split tunnelling enabled.

5. Local (On the ASA) user authentication.

6. Authentication via Pre Shared Key 1234567890.

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.

[box]

PetesASA(config)# object network Internal-Subnet
PetesASA(config-network-object)#  subnet 192.168.110.0 255.255.255.0
PetesASA(config-network-object)# object network L2TP-Subnet
PetesASA(config-network-object)#  subnet 192.168.198.0 255.255.255.248
PetesASA(config-network-object)# nat (inside,outside) source static Internal-Subnet Internal-Subnet destination static L2TP-Subnet L2TP-Subnet no-proxy-arp route-lookup  

[/box]

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”.

[box]

PetesASA(config)# crypto ipsec ikev1 transform-set L2TP-IKE1-Transform-Set esp-aes esp-sha-hmac
PetesASA(config)# crypto ipsec ikev1 transform-set L2TP-IKE1-Transform-Set mode transport

[/box]

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.

[box]

PetesASA(config)# crypto dynamic-map L2TP-MAP 10 set ikev1 transform-set L2TP-IKE1-Transform-Set
PetesASA(config)# crypto map L2TP-VPN-MAP 20 ipsec-isakmp dynamic L2TP-MAP
PetesASA(config)# crypto map L2TP-VPN-MAP interface outside

[/box]

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.

[box]

PetesASA(config)# crypto ikev1 enable outside
PetesASA(config)# crypto ikev1 policy 5
PetesASA(config-ikev1-policy)#  authentication pre-share
PetesASA(config-ikev1-policy)#  encryption 3des
PetesASA(config-ikev1-policy)#  hash sha
PetesASA(config-ikev1-policy)#  group 2
PetesASA(config-ikev1-policy)#  lifetime 86400
PetesASA(config-ikev1-policy)#

[/box]

8. Create a group policy, that hold the following, DNS server IP(s) that will be leased to the remote clients. Tunnel type (L2TP IPSEC), 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.

[box]

PetesASA(config)# group-policy L2TP-Policy internal
PetesASA(config)# group-policy L2TP-Policy attributes
PetesASA(config-group-policy)#  dns-server value 192.168.110.10
PetesASA(config-group-policy)#  vpn-tunnel-protocol l2tp-ipsec
PetesASA(config-group-policy)#  split-tunnel-policy tunnelspecified
PetesASA(config-group-policy)#  split-tunnel-network-list value Split-Tunnel-ACL
PetesASA(config-group-policy)#  default-domain value test.net
PetesASA(config-group-policy)#  intercept-dhcp enable
PetesASA(config-group-policy)# username testuser password password123 mschap

[/box] 

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.

[box]

PetesASA(config)# tunnel-group DefaultRAGroup general-attributes
PetesASA(config-tunnel-general)#  address-pool L2TP-Pool
PetesASA(config-tunnel-general)#  default-group-policy L2TP-Policy

[/box]

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

Cisco ASA Site to Site VPN’s Site to Site ISAKMP VPN

Set up Remote Access PPTP VPN’s in server 2008

Using the Microsoft VPN client through Cisco ASA/PIX

Enable Split Tunnel for IPSEC / SSLVPN / WEBVPN Clients

Bring up a VPN Tunnel From the ASA

KB ID 0001604

Problem

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 inside 192.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;

[box]

packet-tracer input inside tcp 172.16.1.1 80 192.168.1.10 80

[/box]

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

NA

Cisco ASA: ‘Received an un-encrypted INVALID_COOKIE notify message, dropping’

KB ID 0001421

Problem

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.

[box]

Petes-ASA# configure terminal
Petes-ASA(config)# crypto isakmp identity address

[/box]

Then try again!

Related Articles, References, Credits, or External Links

NA

Cisco ASA to Juniper SRX Site to Site VPN

KB ID 0000710

Problem

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.

Step 1 – Configure the ASA

Model used Cisco ASA 5505 v8.4 (ASDM 6.4)

1. Connect to the ASDM > Wizards > VPN Wizards > Site-to-site VPN Wizard.

2. Next.

3. Enter the public IP address of the Juniper Firewall > Next, (Note: I’m assuming the VPN is terminated on the outside interface, if not change it).

4. IKE version 1 > Next.

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).

7. Accept the default of 3DES and SHA1 > Next.

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

  1. 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.
  2. Policy based VPN – VPN is selected based on the policy.

12. Log onto the Juniper Web Device Manager.

13. Tasks > Configure VPN > Launch VPN Wizard.

14. Accept the default of Site-to-site > Start.

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.

18. Accept the defaults > Next.

19. Review the settings > Commit.

Step 3 – Additional Steps required (for Cisco ASA)

20. Navigate to IPsec VPN > Auto Tunnel > Phase II > Select your tunnel > Edit > IPsec VPN 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.

Juniper KB Articles

 

SRX Getting Started – Configure VPN tunnel for site-to-site connectivity

How to configure IPSec VPN on a J Series or SRX Series device