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

Windows Server 2012 ‘Direct Access with Windows 8’

KB ID 0000842

Problem

In the following procedure I’m using Window Server 2012, and Windows 8 Enterprise, I am NOT configuring for Windows 7 so I don’t need to worry about PKI and certificates. (Other than the one the direct access server uses for https identification).

I’m not adding in any Application or Infrastructure servers, this is just a basic run through on setting up Direct Access to get you up and running.

Solution

Step 1 Create Direct Access Group

You can of course accept the default of allowing access to the domain computers group, but I would like to tie things down a little further.

1. Server Manager> Tools > Active Directory Administrative Center > Select the OU (or create one) where you want to create the group.

2.Give the group a sensible name like DirectAccessComputers.

3. Remember when you try and ‘add’ members it will by default NOT have computers listed you will need to add them in.

4. Add in your computer objects as required.

Step 2 Install Direct Access

5. You can simply execute the following command;

[box]
Install-WindowsFeature RemoteAccess -IncludeManagementTools[/box]

6. Or from Server Manager > Tools > Add Roles and Features.

7. Simply add in ‘Remote Access’ and accept all the defaults.

Step 3 Configure Remote Access

8. Once installed launch Remote Access Management.

9. Run the getting stated wizard.

10. Deploy Remote Access Only (I’m not deploying VPNs).

11. Select how the server will be deployed, mine has a single NIC and I’m going to port forward TCP Port 443 (https) to it from the firewall. Enter its Publicly addressable name > Next > Finish.

Note: If you get an error see here.

12. Configure Remote Clients > Edit.

13. I want both options > Next

14. Remove the domain computers and add in the group we created above. Untick the ‘mobile only’ option.

Note: Force Tunnelling means that the remote clients will access the internet though YOUR corporate network. This is only a good idea if you have internet filtering, AV or NAP that you want to take advantage of. (It’s literally the exact opposite of split tunnelling).

15. Remote Access Server > Edit.

16. Select an existing Cert or create a new one > Next.

17. Remember I’m just using Windows 8, if you see the Windows 7 box and think “ooh I’ll tick that!” Then you need to start using certificates > Finish.

18. Finish.

19. Review the settings > Apply.

20. Operation Status.

21. Press Refresh until all the services are green.

Step 4 Configure Clients

The title is a misnomer and to be honest there is no configuration to be done, but they have to get the settings through group policy, so log then onto the domain.

22. A quick simple check is to run the following command;

[box]
Get-DaConnectionStatus[/box]

Note: If you get an error message make sure you are not using Windows 8 Pro see here.

23. The client knows it’s ‘inside’ the LAN, because it has a Name Resolution Policy Table and it can see your internal DNS, you can prove this with the following command;

[box] Get-DNSClientNrptPolicy[/box]

Step 5 Test Clients Externally

Note: Before you proceed your Direct access server needs to be publicly available via the name you specified on the certificate in step 11, and needs to have https open to it.

25. Whilst out on the internet you can test your remote client by first making sure it’s pointing to the correct place;

[box]netsh interface httpstunnel show interface[/box]

This should give the the URL that is on the certificate you specified in step 11, when you ping it by name you should expect a reply (unless ICMP has been blocked by your edge device).

26. And to prove that the client knows it’s NOT on the corporate LAN execute the following;

[box]netsh dnsclient show state[/box]

27. So If i try to ping the internal FQDN of my Direct Access server it should respond (Note its IPv6 address will respond this is normal).

Note: Here I’ve only setup the one server, you can add more Infrastructure and Application servers in the Remote Access Management Console.

28. Because I can resolve that, I can access resources on that server like UNC paths.

29. To access shared resources.

Step 6 Monitoring Remote Access Clients

30. Back on the Direct Access server, you can see the remote clients under ‘Remote Client Status’.

31. Right click each one for a more detailed view.

Related Articles, References, Credits, or External Links

NA

Cisco Router – Configure Site to Site IPSEC VPN

KB ID 0000933

Problem

I’ve done thousands of firewall VPN’s but not many that terminate on Cisco Routers. It’s been a few years since I did one, and then I think I was a wuss and used the SDM. So when I was asked to do one last week thankfully I had the configs ready to go.

I’m going to use the IP addresses above, and my tunnel will use the following settings;

  • Encryption: AES.
  • Hashing: SHA.
  • Diffie Hellman: Group 2.
  • PFS: Enabled.
  • Authentication method: Pre-Shared Key.

Solution

1. Setup a policy for phase 1 of the tunnel (ISAKMP).

[box]

R1>enable
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#crypto isakmp policy 1
R1(config-isakmp)#encr aes
R1(config-isakmp)#hash sha
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#group 2
R1(config-isakmp)#lifetime 86400
R1(config-isakmp)#crypto isakmp key SecretK3y address 1.1.1.2

[/box]

2. Setup an ACL to define what traffic will be encrypted, and a ‘Transform set’ that will dictate the encryption and hashing for phase 2 (IPSEC).

[box]

R1(config)#ip access-list extended VPN-ACL
R1(config-ext-nacl)#permit ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255
R1(config-ext-nacl)#crypto ipsec transform-set VPN-TS esp-aes esp-sha-hmac

[/box]

3. Create a ‘Crypto map’ that is used to apply the phase 2 settings to an interface.

[box]

R1(config)#crypto map VPN-C-MAP 10 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
R1(config-crypto-map)#set peer 1.1.1.2
R1(config-crypto-map)#set transform-set VPN-TS
R1(config-crypto-map)#match address VPN-ACL

[/box]

4. Apply that crypto map to an interface, (usually the Internet facing one).

[box]

R1(config-crypto-map)#interface Serial0/1/0
R1(config-if)#crypto map VPN-C-MAP
*Jan 3 07:16:26.785: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R1(config-if)#exit
R1(config)#

[/box]

5. In most cases your router will be doing NAT, if so you will need to change the ACL that is looking after the NAT for you, look in your running config for something that looks like the following;

[box]

R1#show run
Building configuration...

Current configuration : 1249 bytes
------------output removed for the sake of space------------
!

ip nat inside source list 100 interface Serial0/1/0 overload
!
access-list 100 permit ip 10.10.10.0 0.0.0.255 any
!

------------output removed for the sake of space------------
!
line aux 0
!

[/box]

6. To stop our VPN traffic getting NATTED, we need to put a deny in that ACL, and put it before that permit statement. Remember:

  • Permit=Perform NAT
  • Deny=Don’t perform NAT

On this router (unlike the ASA‘s that I’m more used to), there is no option to define an ACL line number. So its easier to remove the existing one, add the new line then put the original one back. Finally save the changes.

[box]

R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#no access-list 100 permit ip 10.10.10.0 0.0.0.255 any
R1(config)#access-list 100 deny ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255
R1(config)#access-list 100 permit ip 10.10.10.0 0.0.0.255 any
R1(config)#exit
R1#
%SYS-5-CONFIG_I: Configured from console by console

R1#write mem
Building configuration...
[OK]

[/box]

7. Now at the other site, the config should be a mirror image. I will post it in its entirety, so you can copy and paste it into the router, I will highlight the bits you need to check and change in red.

[box]

crypto isakmp policy 1
encr aes
hash sha
authentication pre-share
group 2
lifetime 86400
crypto isakmp key SecretK3y address 1.1.1.1
ip access-list extended VPN-ACL
permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255
crypto ipsec transform-set VPN-TS esp-aes esp-sha-hmac

crypto map VPN-C-MAP 10 ipsec-isakmp
set peer 1.1.1.1
set transform-set VPN-TS
match address VPN-ACL
interface Serial0/1/0
crypto map VPN-C-MAP

no access-list 100 permit ip 20.20.20.0 0.0.0.255 any
access-list 100 deny ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255
access-list 100 permit ip 10.10.10.0 0.0.0.255 any

[/box]

8. Test your VPN with the following commands. Note: you need to send some traffic over the VPN before it will establish!

[box]

show crypto isakmp sa
show crypto ipsec sa

[/box]

WARNING: If you have an ACL applied to the routers outside interface, you will need to allow in the Peer IP, like so;

[box]

ip access-list extended outside-in
 permit esp host 1.1.1.1 any
 permit udp host 1.1.1.1 any eq isakmp
 permit udp host 1.1.1.1 any eq non500-isakmp

[/box]

If you do not, the other end will fail Phase 1 with a WAIT_MSG_3 Error!

Related Articles, References, Credits, or External Links

NA

Cisco Simple GRE Tunnels (With IPSEC)

KB ID 0000951

Problem

I’ve spent years setting up VPN tunnels between firewalls. The only time I’ve ever dealt with GRE is for letting VPN client software though firewalls. GRE’s job is to ‘encapsulate’ other protocols and transport those protocols inside a virtual point to point link. Below is the topology, I’m going to use.

The tunnel will run form Router R1 to Router R3, once complete I should be able to ping Host2 from Host1.

Solution

Configure Router R1 for GRE

1. Create and configure a tunnel interface on the R1 Router. It will need an IP address, (here I’m using 10.0.0.1/30). Then you need to specify the source and destination of the GRE tunnel. Finally I’ve changed some MTU settings because typically MTU’s are set to 1500 and GRE adds an overhead, I’m dropping the MTU to 1400 and setting the maximum segment size to 1360.

[box]

R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interface Tunnel0
*Mar 1 00:01:27.747: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R1(config-if)#ip address 10.0.0.1 255.255.255.252
R1(config-if)#ip mtu 1400
R1(config-if)#ip tcp adjust-mss 1360
R1(config-if)#tunnel source 1.1.1.1
R1(config-if)#tunnel destination 2.2.2.1
R1(config-if)#exit

[/box]

2. Then we need to add a static route to the router’s routing table so it knows to use that tunnel for traffic destined for the 192.168.2.0/24 network.

[box]

R1(config)#ip route 192.168.2.0 255.255.255.0 Tunnel0

[/box]

Configure Router R3 for GRE

3. This is simply a mirror image, of the configuration you carried our on router R1.

[box]

R3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#interface Tunnel0
*Mar 1 00:01:30.747: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#ip address 10.0.0.1 255.255.255.252
R3(config-if)#ip mtu 1400
R3(config-if)#ip tcp adjust-mss 1360
R3(config-if)#tunnel source 2.2.2.1
R3(config-if)#tunnel destination 1.1.1.1
R3(config-if)#exit
R3(config)#ip route 192.168.1.0 255.255.255.0 Tunnel0
[/box]

Verify GRE Tunnel

 

4. Use the following command to check the status of the GRE tunnel.

[box]

R1# show interface tunnel 0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 10.0.0.1/30
  MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 1.1.1.1, destination 2.2.2.1
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255
  Fast tunneling enabled
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Last input never, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

[/box]

5. Then make sure that traffic passes over the tunnel.

[box]

R1#ping 192.168.2.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/64/88 ms
R1#

[/box]

Securing the Tunnel with IPsec

6. Our traffic is now going where we want it to, and it’s encapsulated, but it’s still being ‘sent in clear’ if traffic is intercepted ‘in flight’ it can be read. So we need to secure that traffic by encrypting it. First Job is to create an ISAKMP policy that will establish ‘phase-1’ of our secure tunnel. I’m using AES, with Diffie Hellman group 2, and SHA hashing. Ive specified that I will be using a pre-shared-key so that’s been created with the last command, and is assigned to the IP of the ‘other end’ of the VPN tunnel.

[box]

R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#crypto isakmp policy 10
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#encryption aes
R1(config-isakmp)#group 2
R1(config-isakmp)#hash sha
R1(config-isakmp)#exit
R1(config)#crypto isakmp key 0 Sh@reds3cret address 2.2.2.1

[/box]

7. Phase 2 of our tunnel (IPsec) is encrypted and hashed with a ‘transform set’ again I’m using AES and SHA, then I create a profile that uses my transform set.

[box]

R3(config)#crypto ipsec transform-set TFS-PNL esp-aes esp-sha-hmac
R3(cfg-crypto-trans)#exit
R1(config)#crypto ipsec profile PF-PNL
R1(ipsec-profile)#set transform-set TFS-PNL
R1(ipsec-profile)#exit

[/box]

8. The last job is to apply the profile I created above, to our GRE tunnel interface.

[box]

R3(config)#interface tun0
R3(config-if)#tunnel mode ipsec ipv4
R3(config-if)#tunnel protection ipsec profile PF-PNL
*Mar 1 00:20:32.271: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#
*Mar 1 00:20:33.175: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R3(config-if)#
*Mar 1 00:20:33.699: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#exit
R3(config)#
[/box]

9. Again configure router 3 as a mirror image.

[box]

R3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#crypto isakmp policy 10
R3(config-isakmp)#authentication pre-share
R3(config-isakmp)#encryption aes
R3(config-isakmp)#group 2
R3(config-isakmp)#hash sha
R3(config-isakmp)#exit
R3(config)#crypto isakmp key 0 Sh@reds3cret address 1.1.1.1
R3(config)#crypto ipsec transform-set TFS-PNL esp-aes esp-sha-hmac
R3(cfg-crypto-trans)#exit
R3(config)#crypto ipsec profile PF-PNL
R3(ipsec-profile)#set transform-set TFS-PNL
R3(ipsec-profile)#exit
R3(config)#interface tun0
R3(config-if)#tunnel mode ipsec ipv4
R3(config-if)#tunnel protection ipsec profile PF-PNL
R3(config-if)#
*Mar 1 00:25:32.271: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#
*Mar 1 00:25:33.175: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R3(config-if)#
*Mar 1 00:25:33.699: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#exit
R3(config)#
[/box]

Cisco IOS Verify IPsec VPN Tunnel Is Up

 

Note: To bring up the tunnel simply send some traffic over it by pinging something on the other side of the tunnel. If you get a reply then the tunnel is up! But to check it status firstly make sure phase 1 has established.

[box]

R3#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
1.1.1.1         2.2.2.1         QM_IDLE           1001    0 ACTIVE

IPv6 Crypto ISAKMP SA

R3#

[/box]

QM_IDLE means that phase 1 has established (in Quick Mode), and is in an idle state (this is what you want to see, if you see any other state message you may need to start debugging things).

Once you know phase 1 is established you need to check phase 2.

[box]

R3#show crypto ipsec sa
interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 2.2.2.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 1.1.1.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 2.2.2.1, remote crypto endpt.: 1.1.1.1
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/1
     current outbound spi: 0x3AA3F6B0(983824048)

     inbound esp sas:
      spi: 0x5C5C5EF1(1549557489)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 1, flow_id: SW:1, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4559832/3506)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x3AA3F6B0(983824048)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2, flow_id: SW:2, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4559832/3506)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:

[/box]

 

Related Articles, References, Credits, or External Links

NA

Cisco PIX 500 – IPSEC Site to Site VPNs (v6)

KB ID 0000611 

Problem

Note: This is for firewalls running an operating system BEFORE version 7, if you have an PIX running version 7 or above go here instead. I’ll run though he commands first and then the configuration from PDM at the end.

Solution

PIX 500: Configure a site to site VPN from command line

1. Connect to the PIX, go to “enable mode”, then to “Configure terminal mode”

[box]

User Access Verification

Password:
Type help or '?' for a list of available commands.
PetesPIX> enable
Password: ********
PetesPIX# configure Terminal
PetesPIX(config)# 

[/box]

2. I’m assuming the network BEHIND the PIX 500 is 192.168.124.0/24 and the network at the far end of the tunnel is 192.168.123.0/24. So I’m going to create two ACL’s one to tell the PIX that this traffic should be encrypted, and the second to tell the PIX NOT to perform NAT on the VPN traffic.

Note: Yes I can use one ACL, but having two makes it easier to troubleshoot any VPN problems.

[box]

PetesPIX(config)# access-list VPN_CRYPTO_ACL permit ip 192.168.124.0 255.255.255.0 192.168.123.0 255.255.255.0
PetesPIX(config)# access-list VPN_NO_NAT line 1 permit ip 192.168.124.0 255.255.255.0 192.168.123.0 255.255.255.0

[/box]

3. Now I’ve got an ACL that will stop performing NAT I need to add it as a “Nat 0” (this means don’t perform NAT).

Note: Check to make sure you do not already have a nat(inside) 0 xxx command, if you do, use the SAME ACL that is already in use.

[box]

PetesPIX(config)# nat (inside) 0 access-list VPN_NO_NAT

[/box]

4. To set up all the VPN parameters you need to create a crypto map. In the example below I set the peer IP (the firewall at the other end of the tunnel), to 81.81.81.81. Then I tie it to the ACL I created earlier (VPN_CRYPTO_ACL). I’ve set the encryption and hashing used for the tunnel to 3DES and SHA (These will be used for IPSec (Phase 2)). Set the timeouts for the tunnel, and finally apply the cryptomap I’ve just created, to the outside interface.

[box]

PetesPIX(config)# crypto map VPN_CRYPTO_MAP 20 set peer 81.81.81.81
PetesPIX(config)# crypto map VPN_CRYPTO_MAP 20 match address VPN_CRYPTO_ACL
PetesPIX(config)# crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
PetesPIX(config)# crypto map VPN_CRYPTO_MAP 20 set transform-set ESP-3DES-SHA
PetesPIX(config)# crypto map VPN_CRYPTO_MAP 20 set security-association lifetime seconds 28800 kilobytes 4608000
PetesPIX(config)# crypto map VPN_CRYPTO_MAP interface outside

[/box]

5. The next command lets VPN traffic bypass any other ACLs configured on the firewall.

[box]

PetesPIX(config)# sysopt connection permit-ipsec

[/box]

6. I’m using a “shared secret” that also needs to be setup on the other end of the tunnel. As I said earlier the peer IP is 81.81.81.81.

[box]

PetesPIX(config)# isakmp key 123456 address 81.81.81.81 netmask 255.255.255.255 no-xauth no-config-mode

[/box]

7. To establish the VPN phase 1 (ISAKMP) the devices at both ends of the tunnel need a matching ISAKMP policy. I’ve already set up my shared secret, the first line lets the other end know that’s how we will be communicating. Then once again I’m using 3DES and SHA. I’m telling the system to use Diffie Hellman group 2 for the secure key exchange, and then binding this policy to the outside interface.

Note: If you are interested on how all this stuff works see here

[box]

PetesPIX(config)# isakmp policy 20 authen pre-share
PetesPIX(config)# isakmp policy 20 encrypt 3des
PetesPIX(config)# isakmp policy 20 hash sha
PetesPIX(config)# isakmp policy 20 group 2
PetesPIX(config)# isakmp enable outside

[/box]

8. Then save the changes with a write mem command.

[box]

PetesPIX# write mem
Building configuration...
Cryptochecksum: 79745c0a 509726e5 b2c66028 021fdc7d

7424 bytes copied in 1.710 secs (7424 bytes/sec)
[OK]
PetesPIX#

[/box]

PIX 500: Configure a site to site VPN from the PDM

1. To connect to the PDM you are going to need two things, an OLD browser (IE6) and an OLD version of Java. Select Wizards > VPN Wizard.

2. Site to Site > Next.

3. Set the Peer (Device at the other end of the tunnel) and a shared secret that you will also use at the other end > Next.

4. Set the policy that will be used for phase 1 > Next.

5. Now the phase 2 policy > Next

6. Enter the network behind the PIX > Next.

7. Enter the network at the far end of the tunnel > Finish.

8. Finish by saving the changes > File > Save running configuration to flash.

Related Articles, References, Credits, or External Links

Set up a PIX Firewall with the PDM

PIX 506E and 501 Firewall Image and PDM Upgrade

VPN Problem Cisco PIX v6 to Cisco ASA 5500

KB ID 0000761 

Problem

I found this out purely by accident today, while replacing an old PIX 506E that had died with an ASA 5505. The client’s other site still had a PIX 506E (Running 6.3(5)). I was setting up the VPN, and noticed something that WOULD have been a problem if I had not spotted it.

Solution

Essentially the older PIX firewalls are set for 3DES encryption, MD5 Hashing and Diffie Hellman 2. After version 8.4 the ASA does not have a policy set for this, you need to create one. If I had simply gone ahead, phase 1 of the VPN tunnel would not have established and I would have seen;

[box]

Password:
Type help or ‘?’ for a list of available commands.
Petes-ASA> en
Password: ********
Petes-ASA#debug crypto isakmp 200

<<<<<<<LOTS Of DEBUG TEXT REMOVED>>>>>>>

Apr 01 14:48:48 [IKEv1]: IP = 123.123.123.123, IKE_DECODE RECEIVED Message (msgid=ce4a3ffe) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 56
Apr 01 14:48:48 [IKEv1]: IP = 123.123.123.123, Received an un-encrypted NO_PROPOSAL_CHOSEN notify message, dropping
Apr 01 14:48:48 [IKEv1]: IP = 123.123.123.123, Information Exchange processing failed

<<<<<<<LOTS Of DEBUG TEXT REMOVED>>>>>>>

[/box]

And phase 1 would have sat saying, MM_WAIT_MSG2. So you need to create a matching phase 1 (ISAKMP) policy on the ASA.

Create an IKE version 1 Policy via Command Line

1. Connect to the ASA and issue the following commands;

[box]Sent username “pete”
Type help or ‘?’ for a list of available commands.
Petes-ASA>
Petes-ASA> enable
Password: *******
Petes-ASA# configure terminal
Petes-ASA(config)#crypto ikev1 policy 1
Petes-ASA(config-ikev1-policy)# authentication pre-share
Petes-ASA(config-ikev1-policy)# encryption 3des
Petes-ASA(config-ikev1-policy)# hash md5
Petes-ASA(config-ikev1-policy)# group 2
Petes-ASA(config-ikev1-policy)# lifetime 86400
Petes-ASA(config-ikev1-policy)# exit
Petes-ASA(config)# write mem
Building configuration…
Cryptochecksum: b984ffbc dd77cdbf f2cd8d86 0b8f3f96

3965 bytes copied in 1.490 secs (3965 bytes/sec)
[OK]

[/box]

Create an IKE version 1 Policy via ASDM

If you are creating a Site to Site VPN tunnel from the ASDM wizard you can add the policy during step 6, like so;

Or to add it after the tunnel has been created, Configuration > Site-to-Site VPN > Advanced > IKE Policies > Add > The priority may be changed, but set the rest of the settings as shown. > OK > Apply > File > Save Running Configuration to Flash.

Related Articles, References, Credits, or External

Links

Cisco ASA5500 Site to Site VPN from ASDM

Cisco PIX 500 – IPSEC Site to Site VPNs (v6)

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