Ciscoman's notes (Записки цыщика c дипломом)

I'm Cisco Champion Community member for 2017!

I'm Cisco Champion Community member for 2017!
"Cisco Champions are passionate about Cisco and happy to share our knowledge, experience, and feedback."

вторник, 15 февраля 2011 г.

Cisco IOS Petition

Hi, Fiends! Hope you already know that etherealmind.com in be half of Cisco Networking Community is collecting signatures to make internal Cisco emulators like IOU and L2IOU avaible for education purpose. If not so - don't loose opportunity to sign up for this petition here: http://etherealmind.com/cisco-ios-petition-reloaded/

пятница, 11 февраля 2011 г.

How to conditionally replace two trings with sed

Yesterday I spotted trouble while editing my cisco text configs with large bash script.
 Let's assume we have part of configuration like this:
!
interface FastEthernet0/11
description BB1 E0/0
switchport access vlan 100
switchport mode dynamic desirable
!
interface FastEthernet0/12
switchport mode dynamic desirable
!
If you need to replace "switchport mode dynamic desirable" with "switchport mode trunk", you need first delete string  "switchport mode dynamic desirable" if preceding string is "switchport access vlan 100". In other case your configuration will not work appropriately. You can use vim text editor's command:

:%s/\( switchport access vlan 100\)\n switchport mode dynamic desirable/\1/
But I was unable to do something like this via sed or perl.
It was necessary to ask the opennet.ru community. Thanks to user with nickname temny. He provided this solution:


sed '/switchport access vlan/{N;s!\nswitchport mode dynamic desirable!!;}' file

среда, 9 февраля 2011 г.

eachping.tcl

#-----------------------------------------------------------------------------------------------
#    Simple TCL script for Cisco IOS to ping each device in a column of some command output
#    Author: Eugene K.
#
#    invoke with tclsh eachping.tcl "IOS exec command" "column index"
#    please remeber to quote command argument
#-----------------------------------------------------------------------------------------------

set command [lindex $argv 0]
set index [lindex $argv 1]

if { [ catch {
  foreach line_a [split [exec $command] "\n"] {
      if {[ regexp -inline {[0-9/.]+} [lindex $line_a $index] ] != "" } { ping [lindex $line_a $index] }
  } } e]}  {
  puts "Not enougth arguments or command error. $e"
}

вторник, 1 февраля 2011 г.

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

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.

Постоянные читатели

Поиск по этому блогу