Cisco to Juniper point-to-multipoint IPsec solution - spoke devices migration.

Transcription

1 Cisco to Juniper point-to-multipoint IPsec solution - spoke devices migration. Eugene Khabarov <enkhabarov@gmail.com> JNCIS-ENT, JNCIS-SEC, CCIP, CCNP, CCNA Voice Concept Example of multivendor point-to-multipoint VPN solution with Junipers SRX as a spoke. 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-andspoke) 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.

2 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 bit AES encryption with SHA hash in tunnel mode. Our spokes will have /24 subnets ( /24 in my example) each from /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 is the public IP-address of our hub device, is the public address of out spoke 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:

3 crypto isakmp key secretkey address 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 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) is the ip-address of our gateway: ip route 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

4 Juniper spoke configuration steps: 1. Define IKE proposals: set security ike proposal IKE_PROPOSAL authentication-method preshared-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 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 set security ike gateway IKE_GATEWAY external-interface fe-0/0/ 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 Define IPSEC policy: set security ipsec policy IPSEC_POLICY perfect-forward-secrecy keys group2 set security ipsec policy IPSEC_POLICY proposals IPSEC_PROPOSAL

5 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 /24 set security zones security-zone trust host-inbound-traffic systemservices 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 systemservices ike set security zones security-zone untrust host-inbound-traffic systemservices ping set security zones security-zone untrust interfaces fe-0/0/ Define security policies: set security policies from-zone trust to-zone untrust policy trust-tountrust_lan_encrypt match source-address LAN_SUB set security policies from-zone trust to-zone untrust policy trust-tountrust_lan_encrypt match destination-address any set security policies from-zone trust to-zone untrust policy trust-tountrust_lan_encrypt match application any set security policies from-zone trust to-zone untrust policy trust-tountrust_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

6 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 { ipsec { ike-policy IKE_POLICY; address ; external-interface fe-0/0/0.0; 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;

7 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 /24; host-inbound-traffic {

8 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 {

9 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 UP 40572f77e286c8d3 7be75aaee7105bfc Aggressive Here we will check IPSec SAs:

10 > show security ipsec security-associations Total active tunnels: 1 ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys < ESP:aes-128/sha1 c8b96ce9 3555/ root > ESP:aes-128/sha1 9cf1a4ee 3555/ root Let s check IKE SA on the hub: C7206#show crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status QM_IDLE ACTIVE Now let s check IPsec SAs on the hub: c7206#show crypto ipsec sa peer interface: GigabitEthernet0/0 Crypto map tag: ipsecvpn, local addr protected vrf: (none) local ident (addr/mask/prot/port): ( / /0/0) remote ident (addr/mask/prot/port): ( / /0/0) current_peer port 500 PERMIT, flags={ #pkts encaps: , #pkts encrypt: , #pkts digest: #pkts decaps: , #pkts decrypt: , #pkts verify: #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

11 local crypto endpt.: , remote crypto endpt.: path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0 current outbound spi: 0x228C99F4( ) PFS (Y/N): Y, DH group: group2 inbound esp sas: spi: 0x4A51CAC9( ) transform: esp-aes esp-sha-hmac, in use settings ={Tunnel, conn id: 6607, flow_id: VAM2+:4607, sibling_flags , crypto map: ipsecvpn sa timing: remaining key lifetime (k/sec): ( /2947) IV size: 16 bytes replay detection support: Y Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0x228C99F4( ) transform: esp-aes esp-sha-hmac, in use settings ={Tunnel, conn id: 6608, flow_id: VAM2+:4608, sibling_flags , crypto map: ipsecvpn sa timing: remaining key lifetime (k/sec): ( /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:

12 ping source loopback0 repeat 100 Type escape sequence to abort. Sending 100, 100-byte ICMP Echos to , timeout is 2 seconds: Packet sent with a source address of !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 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.