Cisco to Juniper point-to-multipoint IPsec solution - spoke devices migration.
Concept
Example of multivendor point-to-multipoint VPN solution with Junipers SRX as a spokes.
Description
It is common issue in different network environments, for example corporate retailer network where numerous of small remote offices connected using star topology (as known as hub-and-spoke) in the same fashion. Commonly there is Cisco 870, 880, 1800 series routers and ASA 5505 security appliances used in the market. But things changes and sometimes it is required to migrate to other vendors equipment (or add new vendors equipment simultaneously), Juniper’s SRX 100B in our case is a perfect example. Often Cisco’s proprietary technologies like DMVPN or EasyVPN are used for point-to-multipoint topologies implementations. When you move to other vendors it is required to use industry-standard technologies like Site-to-Site IPSEC VPN. But this can lead to huge administrative overheads and nightmare, because you will be required to add a new configuration for every new spoke device added. At this point we can make a Solomonic solution – use Cisco’s proprietary technology on a Hub device that will allow us to configure hub just once (“one-touch” configuration) and standard-based Site-to-Site IPsec VPN on spoke devices which configurations can be cloned and where configuration templates can be used. This Cisco’s proprietary technology is named dynamic crypto map and it will be used in my example. There will be Juniper SRX series device configuration template for policy-based IPsec VPN also shown.
Diagram
Example
Our example consists of two parts – Cisco hub configuration and Juniper spoke configuration steps. Pre-shared keys will be used for simplicity, but certificate-based authentication also can be used without any restrictions. Policy-based VPN will be used for spokes configuration. We selected following IKE policies – 128 bit AES encryption with SHA hash and DH-group 5 protection. “secretkey” will be used as pre-shared key for authentication. IPsec configuration is similar to IKE - 128 bit AES encryption with SHA hash in tunnel mode. Our spokes will have /24 subnets (10.139.100.0/24 in my example) each from 10.139.0.0/16 block, it will be defined in crypto ACL on cisco 7206VXR hub. Dynamic crypto map will place it all together. As you can see below, junipers spokes configuration is more straightforward. Obviously, IKE and IPsec policies are the same on a hub and the spokes. 1.2.3.2 is the public IP-address of our hub device, 4.3.2.1 is the public address of out spoke. 10.0.255.255 – is the loopback IP-address on the hub. fe-0/0/0 is the external interface on the spoke.
Cisco HUB configuration steps:
1. Define IKE policy (isakmp policy) for IPSEC on hub device (phase 1):
crypto isakmp policy 1
encr aes
authentication pre-share
group 5
2. Define IKE pre-shared key:
crypto isakmp key secretkey address 0.0.0.0 0.0.0.0
3. Define IPSEC policy (phase 2) – (ipsec transform-set):
crypto ipsec transform-set transport-aes-ipsec esp-aes esp-sha-hmac
mode tunnel
4. Define crypto ACL - it will be used for interested traffic definition (traffic to our remote locations):
ip access-list extended INTERESTED_NETS_ACL
permit ip any 10.139.0.0 0.0.255.255
5. Optionally define more specific summarized static route via interface where crypto map will be used for remote offices subnets if you are using more specific routes in you network (e.g. you have no default route pointing to outside interface with crypto map configured or you have default route and one or more routes pointing to other locations than interface with crypto map configured). 1.2.3.4 is the ip-address of our gateway:
ip route 10.139.0.0 255.255.0.0 1.2.3.4 name P2MP_PEERS
6. Configure dynamic crypto map:
crypto dynamic-map dynmap 10
description *** DYNAMIC MAP ***
set transform-set tunnel-aes-ipsec
set pfs group2
match address INTERESTED_NETS_ACL
!
crypto map ipsecvpn 990 ipsec-isakmp dynamic dynmap
7. Assign crypto map to interface:
interface G0/0
crypto map ipsecvpn
Juniper spoke configuration steps:
1. Define IKE proposals:
set security ike proposal IKE_PROPOSAL authentication-method pre-shared-keys
set security ike proposal IKE_PROPOSAL dh-group group5
set security ike proposal IKE_PROPOSAL authentication-algorithm sha1
set security ike proposal IKE_PROPOSAL encryption-algorithm aes-128-cbc
set security ike proposal IKE_PROPOSAL lifetime-seconds 86400
2. Define IKE policy:
set security ike policy IKE_POLICY mode aggressive
set security ike policy IKE_POLICY proposals IKE_PROPOSAL
set security ike policy IKE_POLICY pre-shared-key ascii-text secretkey
3. Define IKE gateway:
set security ike gateway IKE_GATEWAY ike-policy IKE_POLICY
set security ike gateway IKE_GATEWAY address 1.2.3.2
set security ike gateway IKE_GATEWAY external-interface fe-0/0/0.0
4. Define IPSEC proposals:
set security ipsec proposal IPSEC_PROPOSAL protocol esp
set security ipsec proposal IPSEC_PROPOSAL authentication-algorithm hmac-sha1-96
set security ipsec proposal IPSEC_PROPOSAL encryption-algorithm aes-128-cbc
set security ipsec proposal IPSEC_PROPOSAL lifetime-seconds 3600
5. Define IPSEC policy:
set security ipsec policy IPSEC_POLICY perfect-forward-secrecy keys group2
set security ipsec policy IPSEC_POLICY proposals IPSEC_PROPOSAL
6. Configure IPsec VPN section, IPSec tunnels will be established immediately either there is no traffic from the spoke:
set security ipsec vpn IPSEC_VPN ike gateway IKE_GATEWAY
set security ipsec vpn IPSEC_VPN ike ipsec-policy IPSEC_POLICY
set security ipsec vpn IPSEC_VPN establish-tunnels immediately
7. Define security zones, add address-book entry for local LAN subnet, configure allowed services (don’t forget to allow IKE on the outside interface or zone), assign interfaces to zones:
set security zones security-zone trust address-book address LAN_SUB 10.139.100.0/24
set security zones security-zone trust host-inbound-traffic system-services all
set security zones security-zone trust host-inbound-traffic protocols all
set security zones security-zone trust interfaces vlan.0
set security zones security-zone untrust host-inbound-traffic system-services ike
set security zones security-zone untrust host-inbound-traffic system-services ping
set security zones security-zone untrust interfaces fe-0/0/0.0
8. Define security policies:
set security policies from-zone trust to-zone untrust policy trust-to-untrust_lan_encrypt match source-address LAN_SUB
set security policies from-zone trust to-zone untrust policy trust-to-untrust_lan_encrypt match destination-address any
set security policies from-zone trust to-zone untrust policy trust-to-untrust_lan_encrypt match application any
set security policies from-zone trust to-zone untrust policy trust-to-untrust_lan_encrypt then permit tunnel ipsec-vpn IPSEC_VPN
Bringing it all together
Here is the security section of our spoke configuration after commit. It was added on top of the default configuration with exception of the nat. It is not required in our case because we don’t use split tunneling (all traffic from the spokes will be directed to the hub). Don’t forget to remove more specific interface-specific host-inbound-services from default configuration for untrust zone member (fe-0/0/0.0). By default it allows only dhcp and tftp services inbound. Also don’t forget to remove default policy for traffic from zone trust to zone untrust. By default it will allow outbound traffic without encryption:
ike {
proposal IKE_PROPOSAL {
authentication-method pre-shared-keys;
dh-group group5;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;
lifetime-seconds 86400;
}
policy IKE_POLICY {
mode aggressive;
proposals IKE_PROPOSAL;
pre-shared-key ascii-text "$9$qfF/u0IcSeuOhrlK7NaZUjHm69p"; ## SECRET-DATA
}
gateway IKE_GATEWAY {
ike-policy IKE_POLICY;
address 1.2.3.2;
external-interface fe-0/0/0.0;
}
}
ipsec {
proposal IPSEC_PROPOSAL {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;
lifetime-seconds 3600;
}
policy IPSEC_POLICY {
perfect-forward-secrecy {
keys group2;
}
proposals IPSEC_PROPOSAL;
}
vpn IPSEC_VPN {
ike {
gateway IKE_GATEWAY;
ipsec-policy IPSEC_POLICY;
}
establish-tunnels immediately;
}
}
screen {
ids-option untrust-screen {
icmp {
ping-death;
}
ip {
source-route-option;
tear-drop;
}
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
timeout 20;
}
land;
}
}
}
zones {
security-zone trust {
address-book {
address LAN_SUB 10.139.100.0/24;
}
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
vlan.0;
}
}
security-zone untrust {
screen untrust-screen;
host-inbound-traffic {
system-services {
ike;
ping;
}
}
interfaces {
fe-0/0/0.0 {
}
}
}
}
policies {
from-zone trust to-zone untrust {
policy trust-to-untrust_lan_encrypt {
match {
source-address LAN_SUB;
destination-address any;
application any;
}
then {
permit {
tunnel {
ipsec-vpn IPSEC_VPN;
}
}
}
}
}
from-zone untrust to-zone trust {
policy untrust-to-trust_lan_encrypt {
match {
source-address any;
destination-address LAN_SUB;
application any;
}
then {
permit {
tunnel {
ipsec-vpn IPSEC_VPN;
}
}
}
}
}
}
}
Verification and troubleshooting
On spoke we will be able to notice established IPsec phases 1 and 2 (bidirectional IKE tunnel for session key exchange and two unidirectional IPsec tunnel s for data transfer).
Let’s check IKE SA:
admin@spoke> show security ike security-associations
Index Remote Address State Initiator cookie Responder cookie Mode
7 1.2.3.2 UP 40572f77e286c8d3 7be75aaee7105bfc Aggressive
Here we will check IPSec SAs:
admin@spoke > show security ipsec security-associations
Total active tunnels: 1
ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys
<2 1.2.3.2 4500 ESP:aes-128/sha1 c8b96ce9 3555/ 838855 - root
>2 1.2.3.2 4500 ESP:aes-128/sha1 9cf1a4ee 3555/ 838855 - root
Let’s check IKE SA on the hub:
C7206#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
1.2.3.2 4.3.2.1 QM_IDLE 13372 ACTIVE
Now let’s check IPsec SAs on the hub:
c7206#show crypto ipsec sa peer 4.3.2.1
interface: GigabitEthernet0/0
Crypto map tag: ipsecvpn, local addr 1.2.3.2
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): (10.139.100.0/255.255.255.0/0/0)
current_peer 4.3.2.1 port 500
PERMIT, flags={}
#pkts encaps: 853682, #pkts encrypt: 853682, #pkts digest: 853682
#pkts decaps: 779630, #pkts decrypt: 779630, #pkts verify: 779630
#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.: 1.2.3.2, remote crypto endpt.: 4.3.2.1
path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0
current outbound spi: 0x228C99F4(579639796)
PFS (Y/N): Y, DH group: group2
inbound esp sas:
spi: 0x4A51CAC9(1246874313)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 6607, flow_id: VAM2+:4607, sibling_flags 80000046, crypto map: ipsecvpn
sa timing: remaining key lifetime (k/sec): (4400144/2947)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x228C99F4(579639796)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 6608, flow_id: VAM2+:4608, sibling_flags 80000046, crypto map: ipsecvpn
sa timing: remaining key lifetime (k/sec): (4399675/2947)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
Ping from the hub’s loopback IP address toward the spoke will be successful now:
ping 10.139.100.1 source loopback0 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.139.100.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.255.255
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 4/7/20 ms
Conclusion
In this document we have covered one of the approaches used during migration to multivendor hub-n-spoke IPsec topology. It was shown that it is possible to implement such configuration in clear fashion and support it easily because of the ability to use standard template for spokes configuration and “one-touch” hub configuration.
