Backup Disasters: How You Can Avoid Them

Posted by Teacher of Cisco .
  • Agregar a Technorati
  • Agregar a Del.icio.us
  • Agregar a DiggIt!
  • Agregar a Yahoo!
  • Agregar a Google
  • Agregar a Meneame
  • Agregar a Furl
  • Agregar a Reddit
  • Agregar a Magnolia
  • Agregar a Blinklist
  • Agregar a Blogmarks

Backup Disasters: How You Can Avoid Them

Backup Disasters: How You Can Avoid Them

Posted: 04 Apr 2011 08:36 AM PDT


Even those of you religious about backing up your PC data may face a few of the same demons that CIO.com's Bill Snyder recently battled. Read on for advice on how to make sure your backups don't behave badly.

EMC/RSA acquires electronic threat detection firm NetWitness

Posted: 04 Apr 2011 08:12 AM PDT


EMC Corp. today announced it has acquired NetWitness Corp., security company that makes the NextGen visibility monitoring system to detect electronic threats and malware-based attacks. EMC said NetWitness will operate as part of RSA.

Bank customers warned after breach at Epsilon marketing firm

Posted: 02 Apr 2011 09:02 AM PDT


JP Morgan Chase and the Kroger supermarket chain are warning customers that their names and e-mail addresses may have fallen into the wrong hands after someone broke into computer systems at e-mail marketing giant Epsilon.

Site to Site VPN with Dynamic Crypto Map

Posted: 04 Apr 2011 10:18 AM PDT


In this post I will talk about Hub-and-Spoke VPN with one dynamic and two static crypto-maps between Cisco routers. The scenario is as following: There is a central HQ site which will be the Hub of our VPN network and also two branch sites which will be the spokes in our VPN network (see diagram below). The central HQ site will have a dynamic crypto-map while the branch sites will have a static crypto map. By configuring the central site with a dynamic crypto-map it means that the remote branch sites can have a dynamic public IP address. The branch sites will have a static crypto-map because for them the remote site (i.e the central HQ site) will have a static public IP address.

First of all let's discuss some key points you must have in mind for this scenario which uses both static crypto-map and Dynamic crypto-map.

●     In the case of static crypto-map all peers on the VPN terminator (HUB) must be configured manually with their specific static public IP address. In the case of a dynamic crypto-map we don't have to configure the peers one-by-one on the VPN terminator (HUB).  There are no changes on the spoke sites, i.e. we leave static crypto-map as it was.

●     In the case of dynamic crypto-map, the initiator of VPN session will be only the spoke site. This means that if traffic doesn't come from the Spoke in the VPN tunnel, then VPN dynamic tunnel will not be established. When, however, traffic is initiated from the spoke site (branch) then the VPN tunnel will be established and the connection will be bidirectional between branch and HQ.

●    There is a simple configuration on the HUB site. If we add more spokes, configuration will be done only on spoke site and there is no need for changing anything on HUB.

Let's set our LAB network diagram below.

Equipment used in This lab:

  • HQ – 3725 IOS c3725-advsecurityk9-mz.124-1c
  • Branches – 2691 IOS c2691-adventerprisek9-mz.123-17a

LAB Scenario:

We've got HQ office and two Branches, which are connected via Internet. The Hosts in Branches must have secure access to the servers located in HQ. That is, network subnets 192.168.4.0/24 and 192.168.5.0/24 must have secure access to subnet 192.168.1.0/24. That's an ordinary scenario, which many organizations implement all over the world. Since this is a Lab scenario, only private IP addresses were used. In a real scenario the WAN IP addresses of HQ and Branches routers will be public IP.

Configuration:

The very first thing you need to do in such a scenario is to verify that all sites have IP connectivity between them. Verify that all WAN interfaces of routers can reach each other over the Internet.

Branches Configuration.

! Create isakmp policy.  If you have multiple policies it is recommended that the most strong policy should be first (i.e have the lowest policy number).
crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 2

! Configure crypto isakmp key. The keys between peers must be the same. In our case the branches should specify the static IP address of HQ and have the same key with HQ

crypto isakmp key somestrongkey address 192.168.2.2

! Configure IPsec transform-set.  This specifies what encryption and Hash algorithm should be used for encryption of VPN traffic.

crypto ipsec transform-set ts esp-aes 256 esp-sha-hmac

! Create access list by which we'll match interesting traffic that will pass through the VPN. In case of Branch 1 will be the following: if source is 192.168.4.0/24 and destination is 192.168.1.0/24 then traffic will be encrypted. Similarly for Branch 2, if source is 192.168.5.0/24 and destination is 192.168.1.0/24 then traffic will be encrypted.
Branch 1 ACL:

ip access-list extended vpn
permit ip 192.168.4.0 0.0.0.255 192.168.1.0 0.0.0.255

Branch 2 ACL:

ip access-list extended vpn
permit ip 192.168.5.0 0.0.0.255 192.168.1.0 0.0.0.255

! Create crypto-map and snap to it the already created transform-set and access list. Also indicate VPN peer and turn on Reverse-route. The purpose of reverse-route is that when VPN tunnel is established, Destination network of access list created for interesting traffic will be added in routing table as static route. In our case this access list is "vpn" and the destination network of this access list is 192.168.1.0/24.

crypto map vpn 10 ipsec-isakmp
set peer 192.168.2.2
set transform-set ts
match address vpn
reverse-route

!Assign crypto-map to external interface. In our case Fa0/0. After this, ISAKMP will turn on.
interface FastEthernet0/0
crypto map vpn

Configuration of Branches is done. Let's start HQ configuration.

HQ Configuration:
! crypto isakmp policy will not be changed.
crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 2

! All peer addresses are assigned with a secret key, i.e. all zeros are assigned, for avoiding writing each branch's IP address separately.
crypto isakmp key somestrongkey address 0.0.0.0 0.0.0.0

! IPSec Transform-set will not change.
crypto ipsec transform-set ts esp-aes 256 esp-sha-hmac

! Access list, by which interesting traffic is matched, will be changed. Source will be 192.168.1.0/24 and destination will be 192.168.4.0/24 and 192.168.5.0/24.
ip access-list extended vpn
permit ip 192.168.1.0 0.0.0.255 192.168.5.0 0.0.0.255
permit ip 192.168.1.0 0.0.0.255 192.168.4.0 0.0.0.255

! Configure Dynamic crypto-map.  Assign the same parameters, except assigning peers.
crypto dynamic-map vpndynamic 10
set transform-set ts
match address vpn
reverse-route

!Create crypto-map and snap to it already created dynamic crypto-map.
crypto map dynmap 10 ipsec-isakmp dynamic vpndynamic

!Assign crypto-map on external interface. In our case Fa0/0. After this ISAKMP will turn on.

interface FastEthernet0/0
crypto map dynmap

Verification:

Now the configuration is done and let's start checking if it works. First of all ping SRV from host1. Check the following:  Is VPN tunnel established or not, decaps/encaps increases or not, RRI (reverse-route injection) is added in Branche1 and HQ Routing Tables and also if hit counts in access lists change or not.

!We see, that first few pings are lost, because VPN tunnel takes some time to get established.
host1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 40/96/164 ms

host1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/62/124 ms

!Now check if ISAKMP peers are in state or not.

hq#show crypto isakmp sa
dst             src             state          conn-id slot status
192.168.2.2     192.168.3.2     QM_IDLE              1    0 ACTIVE

branch1#show crypto isakmp sa
dst             src             state          conn-id slot
192.168.2.2     192.168.3.2     QM_IDLE              1    0

!Let's see again if encaps/decaps increase. If not and they ping each other, this means that traffic is not going through VPN tunnel.

branch1#show crypto ipsec sa
interface: FastEthernet0/0
crypto map tag: vpn, local addr. 192.168.3.2
protected vrf:
local  ident (addr/mask/prot/port): (192.168.4.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
current_peer: 192.168.2.2:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 13, #pkts encrypto: 13, #pkts digest 13
#pkts decaps: 12, #pkts decrypto: 12, #pkts verify 12
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0

hq#show crypto ipsec sa
interface: FastEthernet0/0
crypto map tag: dynmap, local addr 192.168.2.2
protected vrf: (none)
local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.4.0/255.255.255.0/0/0)
current_peer 192.168.3.2 port 500
PERMIT, flags={}
#pkts encaps: 12, #pkts encrypto: 12, #pkts digest: 12
#pkts decaps: 13, #pkts decrypto: 13, #pkts verify: 13
#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

!Let's check that RRI is all right and access lists are matched.

hq#show ip route static
S    192.168.4.0/24 [1/0] via 192.168.3.2

branch1#show ip route static
S    192.168.1.0/24 [1/0] via 192.168.2.2

hq#show access-lists vpn
Extended IP access list vpn
10 permit ip 192.168.1.0 0.0.0.255 192.168.5.0 0.0.0.255
20 permit ip 192.168.1.0 0.0.0.255 192.168.4.0 0.0.0.255 (25 matches)

branch1#show access-lists vpn
Extended IP access list vpn
10 permit ip 192.168.4.0 0.0.0.255 192.168.1.0 0.0.0.255 (26 matches)

All the above indicate that everything is all right and VPN is working properly. Also remember that we've not assigned peers in HQ configuration and that makes configuration simple (when we have 20 branches there is no need for assigning static peers of Branches on the HQ site). Another great advantage of dynamic crypto map on the HQ site is when a branch site receives dynamic public IP address from the ISP.

Meru Networks: Closing in on the all-wireless enterprise network

Posted: 04 Apr 2011 06:51 AM PDT


In this installment of the IDG Enterprise CEO Interview Series, Meru President and Ihab Abu-Hakima speaks with IDGE Chief Content Officer John Gallant about what sets Meru apart from bigger competitors with broader networking product lines such as Cisco and HP as well as what needs to be done by enterprises to manage and secure networks being flooded by iPads, smartphones and other devices.

The network is built in

Posted: 04 Apr 2011 03:00 AM PDT


Cisco last week added more detail to its data center fabric story by rolling out a bevy of new products that provide extra touch points to use when comparing Cisco's strategy to the fabric plans of Juniper and Brocade.

Cisco fleshes out its data center switch fabric story

Posted: 04 Apr 2011 09:00 AM PDT


Last week's data center splash from Cisco means customers can now begin to implement the company's fabric technology just about end-to-end, from the server network interface card to the network core.

When you can't trust your own company

Posted: 04 Apr 2011 09:00 AM PDT


The 'Net is just one hack away for disaster

Pharma firm bans non-SAAS apps

Posted: 04 Apr 2011 09:00 AM PDT


AMAG's IT needs are more efficiently and cost effectively served by public cloud providers, including infrastructure-as-a-service (IaaS) and software-as-a-service (SaaS), than by internal systems and applications.

0 comments:

Subscribe to: Post Comments (Atom)
Post a Comment