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