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.