IPSEC VPN between Cisco IOS & Netscreen –

This isn’t necessarily Mozilla related but after spending a month on and off trying to get an IPSEC VPN up between a Cisco IOS router and a Juniper Netscreen SSG5 and finding very little help online, I figured I might as well document it here for others to find (myself, for instance, or, hey Google – index this).

For those interested, read on.

First, as a reference, here’s what my network looks like:

I aggregated Mountain View’s internal networks into 10.250.0.0/16. Specific policy controls are done through firewall ACLs and where appropriate I’ve had to tweak NAT statements (ask me if you need more on that).

Second, these configs work for me and work on the following:

·         Cisco 3845 router: Cisco IOS Software, 3800 Software (C3845-ADVIPSERVICESK9-M), Version 12.4(9)T1, RELEASE SOFTWARE (fc2)

·         Juniper Netscreen SSG5: Software Version: 5.4.0r3a.0, Type: Firewall+VPN

Cisco IOS Configuration

crypto isakmp policy 15

 encr 3des

 authentication pre-share

 group 2

 lifetime 28800

crypto isakmp key MY-SECRET-PASSCODE address 223.225.122.226

crypto ipsec transform-set aes-sha esp-aes esp-md5-hmac

crypto map ipsec-remoteoffice 11 ipsec-isakmp

 set peer 223.225.122.226

 set transform-set aes-sha

 set pfs group2

 match address 101

access-list 101 permit ip 10.250.0.0 0.0.255.255 10.240.2.0 0.0.0.255

interface GigabitEthernet0/1

 description outside_interface

 ip address 123.245.208.46 255.255.255.252

 ip nat outside

 crypto map ipsec-remoteoffice

Juniper Netscreen Configuration
Much of this configuration was gleamed from here, using the WebUI (mostly the policies). If you follow that guide, you’ll only need to set the Proxy ID and change the p2-proposal (well, add the cisco one and change the Gateway proposal to it).

set interface ethernet0/0 ip 223.225.122.226/29

set address "Trust" "ca-net" 10.240.2.0 255.255.255.0

set address "Untrust" "mv-net" 10.250.0.0 255.255.0.0

set ike p2-proposal "cisco" group2 esp aes128 md5 second 3600

set ike gateway "Mountain View" address 123.245.208.46 Main outgoing-interface "ethernet0/0" preshare "MY-SECRET-PASSCODE" proposal "pre-g2-3des-sha"

set vpn "Moco-MV" gateway "Mountain View" replay tunnel idletime 0 proposal "cisco"

set vpn "Moco-MV" proxy-id local-ip 10.240.2.0/24 remote-ip 10.250.0.0/16 "ANY"

These two policies were done through the WebUI and made positioned at the top. Like I said, see this site.

set policy id 9 from "Untrust" to "Trust"  "mv-net" "ca-net" "ANY" tunnel vpn "Moco-MV" id 1 pair-policy 8 log

set policy id 8 from "Trust" to "Untrust"  "ca-net" "mv-net" "ANY" tunnel vpn "Moco-MV" id 1 pair-policy 9 log

Important Notes & Thanks

1.      Netscreen requires setting Proxy-Id

2.      Need to match lifetime settings – Netscreen defaulted to 28800 seconds and I made IOS match that.

3.      debug crypto ipsec & debug crypto isakmp are your friends.

I want to acknowledge a couple folks & resources who responded to my plea of help on NANOG:

1.      Michael K. Smith – after a couple emails he called me and we worked through the configs on both sides until it was up and working.

2.      Guy Snyder from ICSA Labs who send me a couple URLs that were helpful.

1.      Cisco IOS

2.      Juniper Netscreen

Route-based and policy-based IPSec vpns between Cisco IOS and Juniper ScreenOS

I had to train some NOC’ers a couple of days ago and I came up with a few scenarios we come across often, and how we would ensure the VPNs work.

We currently predominantly use Juniper’s ScreenOS range for IPSec VPNs. 3rd parties use anything from Juniper, Cisco, Checkpoint, etc. The most common is Cisco, and it’s also the one that causes the most issues from my experience.

Let’s use the following topology. 10.0.0.0/24 represents the public internet. Each site needs to have connectivity to the other through an IPSec VPN tunnel.

Both IOS and ScreenOS allow you to create both policy-based and route-based VPNs. From my experience, most people seem to do policy-based VPNs. I much prefer route-based VPNs. In fact I have not created a policy-based VPN in a number of years as I always find route-based to be far superior.

There are a number of differences, but in essence in goes like this. With policy-based, interesting traffic going over the regular interface will be encrypted and sent to the other side of the tunnel. Interesting traffic is defined in an ACL. With route-based, you actually create a layer 3 interface and any traffic going through that tunnel is subject to encryption.

The great thing about route-based tunnels is that you can run routing protocols over them. You can also send any traffic you like over it and you know it’ll be encrypted. You can also easily attach service policies to a tunnel interface. In essence, you get a fully routable layer3 interface. A policy-based VPN simply doesn’t give you this capability.

Note that I’m going to use some generic phase 1 and phase 2 settings. You can of course add loads of different options, but that’s up to you.

Let’s start with the Juniper ScreenOS device. eth0/5 is my untrust interface.

set interface tunnel.1 zone untrust

set interface tunnel.1 ip unnumbered interface ethernet0/5

set ike gateway "VPN_P1" address 10.0.0.2 Main outgoing-interface "ethernet0/5"

(continued form line above) preshare vpnblog proposal "pre-g2-3des-sha"

set vpn "VPN_P2" gateway "VPN_P1" no-replay tunnel idletime 0 proposal "g2-esp-3des-sha"

set vpn "VPN_P2" bind interface tunnel.1

set route 192.168.0.0/24 interface tunnel.1

In the above I’ve created Tunnel 1. I then created my phase 1 and phase 2 settings and binded the tunnel interface to the phase 2 set up. I then create a static route to send traffic going to 192.168.0.0/24 over the tunnel.

Let’s now move over to the Cisco. Pretty much the same thing I’m doing, but the config looks a little different:

crypto isakmp policy 1

 encr 3des

 authentication pre-share

 group 2

crypto isakmp key vpnblog address 10.0.0.1

!

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

!

crypto ipsec profile VPN_P2

 set transform-set ESP-3DES-SHA

!

interface Tunnel0

 ip unnumbered FastEthernet0/0

 tunnel source 10.0.0.2

 tunnel destination 10.0.0.1

 tunnel mode ipsec ipv4

 tunnel protection ipsec profile VPN_P2

!

ip route 172.16.0.0 255.255.255.0 Tunnel0

Both my hosts can now ping each other. You can verify the VPN is up as follows:

ScreenOS

SSG5-> get ike cookies

IKEv1 SA -- Active: 1, Dead: 0, Total 1

80182f/0003, 10.0.0.1:500->10.0.0.2:500, PRESHR/grp2/3DES/SHA, xchg(5) (VPN_P1/grp-1/usr-1)

resent-tmr 26233316 lifetime 28800 lt-recv 28800 nxt_rekey 28373 cert-expire 0

initiator, err cnt 0, send dir 0, cond 0x0

nat-traversal map not available

ike heartbeat              : disabled

ike heartbeat last rcv time: 0

ike heartbeat last snd time: 0

XAUTH status: 0

DPD seq local 0, peer 0

IOS

Cisco#sh crypto ipsec sa

interface: Tunnel0

    Crypto map tag: Tunnel0-head-0, local addr 10.0.0.2

   (removed for brevity)

     inbound esp sas:

      spi: 0x1DCD78DB(500005083)

        transform: esp-3des esp-sha-hmac ,

        in use settings ={Tunnel, }

        conn id: 3001, flow_id: FPGA:1, crypto map: Tunnel0-head-0

        sa timing: remaining key lifetime (k/sec): (4469954/3330)

        IV size: 8 bytes

        replay detection support: Y

        Status: ACTIVE

     outbound esp sas:

      spi: 0x3593AF04(898871044)

        transform: esp-3des esp-sha-hmac ,

        in use settings ={Tunnel, }

        conn id: 3002, flow_id: FPGA:2, crypto map: Tunnel0-head-0

        sa timing: remaining key lifetime (k/sec): (4469953/3329)

        IV size: 8 bytes

        replay detection support: Y

        Status: ACTIVE

Of course the best thing about using a tunnel interface is that you can use it like a regular layer 3 interface. If both sides are under the same administrative control why not just run OSPF instead of the static routes?

ScreenOS

set protocol ospf

set enable

set interface trust protocol ospf area 0.0.0.0

set interface trust protocol ospf passive

set interface trust protocol ospf enable

set interface tunnel.1 protocol ospf area 0.0.0.0

set interface tunnel.1 protocol ospf enable

set interface tunnel.1 mtu 1443

unset route 192.168.0.0/24 interface tunnel.1

IOS

interface FastEthernet0/1

 ip ospf 1 area 0

!

interface Tunnel0

 ip ospf 1 area 0

!

no ip route 172.16.0.0 255.255.255.0 Tunnel0

Cisco#sh ip route 172.16.0.0

O       172.16.0.0 [110/11112] via 10.0.0.1, 00:01:19, Tunnel0

SSG5-> get route ip 192.168.0.0

 Dest for 192.168.0.0

--------------------------------------------------------------------------------------

trust-vr       : => 192.168.0.0/24 (id=9) via 0.0.0.0 (vr: trust-vr)

                    Interface tunnel.1 , metric 2

I had to change the MTU of the ScreenOS tunnel as they report their sizes a bit differently.

So the above is all very simple, as long as both sides are using route-based VPN tunnels. Unfortunately 90% of the time I see the 3rd party creating a policy-based tunnel. While you can match it to be a policy-based tunnel on the ScreenOS side, you can actually still run a route-based VPN. No you won’t be able to run a routing protocol over it, but it will keep your configuration clean.

Cisco

crypto isakmp policy 1

 encr 3des

 authentication pre-share

 group 2

crypto isakmp key vpnblog address 10.0.0.1

!

!

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

!

crypto map VPN_P2 10 ipsec-isakmp

 set peer 10.0.0.1

 set transform-set ESP-3DES-SHA

 set pfs group2

 match address 100

!

interface FastEthernet0/0

 crypto map VPN_P2

!

access-list 100 permit ip 192.168.0.0 0.0.0.255 172.16.0.0 0.0.0.255

The ScreenOS config is the same, except for the fact that I’ve re-added that static route over the tunnel.

Unfortunately the VPN does not come up, but if you check the ScreenOS event log it’s quite clear what’s happening:

Rejected an IKE packet on untrust from 10.0.0.2:500 to 10.0.0.1:500 with cookies 39baf5f7

and 9e7b3f4ab8141de4 because The peer sent a proxy ID that did not match the one in the 

SA config. IKE 10.0.0.2 Phase 2: No policy exists for the proxy ID received: local ID 

(172.16.0.0/255.255.255.0, 0, 0) remote ID (192.168.0.0/255.255.255.0, 0, 0).

The ScreenOS box is complaining that the proxy-id received does not match it’s own. The Cisco proxy-id is made up from the ACL we defined above. As the ScreenOS box is running a route-based VPN, it’s proxy-id is essentially 0.0.0.0/0 0.0.0.0/0

To fix it, we can very easily ‘fake’ our proxy-id on the ScreenOS box:

set vpn "VPN_P2" proxy-id  local-ip 172.16.0.0/24 remote-ip 192.168.0.0/24 "ANY"

As soon as this command is entered, both VPN tunnels come straight up.

What is quite common is for multiple subnets from one side needing access to multiple subnets to the other and vice-versa. Now a route-based VPN on both sides would run this extremely easily with a single IPSec tunnel. If the remote party is determined to use policy-based VPNs on their Cisco device, you can still run multiple tunnels to them.

A great feature as of ScreenOS 6.3 onwards is that you can create multiple proxy-ids per phase 2 tunnel. With each proxy-id it’ll spawn a new phase 2 tunnel, but the only configuration you need to do is to add another proxy-id to the existing tunnel. Nice and Easy!