STP SECURITY FEATURES ON SWITCHES

Enable ENHANCED Spanning Tree Protocol features (for example, BPDU Guard, Loopguard, and Root Guard) are Layer 2 Security Best Practices.

STP attacks Mitigation techniques

Attacking device spoofs the root bridge in the STP topology. If successful, the network attacker can see a variety of frames.

The Spanning Tree Protocol (STP) Man in The Middle (MiTM) attack compromises the STP "Root Bridge" election process and allows a hacker to use their PC to masquerade as a "Root Bridge," thus controlling the flow of L2 traffic.

STP MiTM attack, and other attacks, can be thwarted on a Cisco Catalyst device by using either the "BPDU Guard" Feature or the "Root Guard" Feature. These enhanced features of STP are the two best methods for thwarting STP MiTM attack, in which a rogue workstation starts generating superior Configuration BPDUs in order to elect itself as the Root Bridge.

Recommended:

  - Proactively configure the primary and backup root (or secondary root). 

  - Enable Root Guard and BPDU Guard to defeat MiTM attacks.

BPDU Guard and Root Guard are enhancements to Spanning Tree Protocol (STP) enhancements that improve the reliability of the protocol to unexpected events.

Remember that the purpose of the the Spanning Tree algorithm is to create a single path through the network to prevent loops. because the Ethernet frame has no loop prevention mechanism. 

Both BPDU Guard and Root Guard are used to enforce design enforcement (integrity / security) and ensure that the STP protocol operates as designed. In brief:

Root Guard is mainly implemented on Switch to Switch connections (except ports of the root switch and root ports) and access ports at the network edge, for example: servers, laptop and desktop ports.

BPDU Guard is implemented at the Network Edge.

You can use together BPDU Guard and Root Guard on access ports to protect them against unexpected BPDUs.

BPDU Guard

Prevents problems related to switches accidentally being connected to PortFast-enabled ports. Bridging loops would normally instantly occur. It places inmediately the port in err-disable state if it receives a BPDU (whether superior to the current root or not) - disabling the interface. The port is shut down in an error condition and must be either manually re-enabled or automatically recovered through the errdisable timeout function.

The BPDU Guard feature was developed to further protect the integrity of switch ports that have PortFast enabled.

Normally, PortFast provides quick network access to end-user devices, where bridging loops never are expected to form. Even while PortFast is enabled on a port, STP still is running and can detect a bridging loop. However, a loop can be detected only in a finite amount of time —the length of time required to move the port through the normal STP states.

Suppose that a switch is connected by mistake to a port where PortFast is enabled and BPDU Guard is not in use. Now, there is a potential for a bridging loop to form. An even greater consequence is that the potential now exists for the newly connected device to advertise itself and become the new root bridge.

By combining PortFast & BPDU guard we have a port that can quickly enter the Forwarding state from Blocking state and automatically shut down when receiving BPDUs.

By default, BPDU Guard is disabled on all switch ports. You can configure BPDU Guard as a global default, affecting all switch ports with a single command or on per-port basis. Let’s see:

To enable or disable BPDU Guard globally on the switch:

Switch(config)# [no] spanning-tree portfast edge bpduguard default

To enable or disable BPDU Guard at the interface level (on per-port basis):   

Switch(config-if)# spanning-tree bpduguard {enable | disable}

Tip: if you enable BPDU Guard globally on the switch, disable BPDU Guard on trunk links with:

switch(config-if)# spanning-tree bpduguard disable

Note: in Earlier releases, to enable BPDU Guard globally:

Router(config)# spanning-tree portfast bpduguard default

You should use BPDU Guard on all switch ports where STP PortFast is enabled. This prevents any possibility that a switch will be added to the port, either intentionally or by mistake.

BPDU Guard is mainly used on access-layer switch ports where users and end devices connect. BPDUs normally would not be expected there and would be detected if a switch or hub inadvertently were connected.

You don't need bpduguard to block a loop. That's what STP does naturally. Bpduguard is just a way of enforcing a security policy that states that a given port should never receive a bpdu. This could be helpful in the case where a hub is connected to an access port. The hub does not generate bpdus, so it is legitimate to configure bpduguard on the access port. If some users create a loop on the hub, it will send back to the access port its own bpdus. The access port will then go errdisable, at least isolating the loop if it cannot prevent it.

A hub doesn’t transmit BPDUs itself; it merely repeats Ethernet frames from its other ports. A loop could form if the hub became connected to two locations in the network, providing a path for frames to be looped without any STP activity.

Note If BPDU Guard is enabled on an uplink port, BPDUs will be detected and the uplink will be put into the Errdisable state. This will preclude that uplink port from being used as an uplink into the network.

Note You can enable the BPDU guard feature if your switch is running PVST+, rapid PVST+, or MSTP [PVST+ uses STP, the other two use RSTP].

Root Guard

Root guard is best deployed toward ports that connect to switches which should not be the root bridge.

The Root Guard feature can be enabled on all switch ports where the root bridge should never be seen (that is, every port that is not a root port , the port on each switch that is considered to be closest to the root bridge). So you can use this feature on access ports enabled with portfast and bpdu guard.

We can configure the root guard feature to prevent unauthorized switches from becoming the root bridge. Root guard was developed to control where root bridges can be located within the network.

The root bridge always is expected to be seen on the root port and the alternative ports because these are “closest” (have the best-cost path) to it.

Switches learn about and elect root bridges based on BPDUs they receive, so if a new switch is added to the environment with a lower bridge priority than the current root bridge (or the same bridge priority but a lower MAC address), the new switch will become root – and in turn disrupt your carefully planned traffic patterns. The STP topology might reconverge to a new shape. This is entirely permissible by the STP because the switch with the lowest bridge ID always wins the root election. In addition, while the topology is reconverging, your production network might become unavailable.

To prevent this from occurring, root guard can be applied to interfaces where a root bridge should never been seen. Root Guard does not allow the port to become a STP root port.

When root guard is applied to an interface, it forces the port to essentially always remain as a designated interface, never allowing it to transition to a root port.

If a root guard-enabled port receives a superior BPDU (or one with a better bridge ID), it inmediately moves the port to a root-inconsistent STP state (essentially the same as the listening state) and does not forward any traffic out that port. The local switch will not allow the new switch to become the root. No data can be sent or received in that state, but the switch can listen to BPDUs received on the port to detect a new root advertising itself.

Root guard cannot be used on root switch, because this command is based on blocking the port when a superior BPDU is received – while a root switch can’t have a blocked port, only designated ports.

Because it’s impossible to have two designated ports in a same segment, when two ports of one segment are configured with Root Guard, one of them is moved to root-inconsistent state. Thus this link won’t be used.

When the root guard protected port stops receiving superior BPDUs, it automatically unblocks the port and proceeds through its normal listening, learning, and eventually forwarding states. No intervention is required.

To enable root guard on an interface:

Switch(config-if)# spanning-tree guard root

You can enable Root Guard only on a per-port basis. By default, it is disabled on all switch ports.

Use Root Guard on switch ports where you never expect to find the root bridge for a VLAN. In fact, Root Guard affects the entire port so that a root bridge never can be allowed on any VLAN on the port.

Tip: To display switch ports that Root Guard has put into the root-inconsistent state

Switch# show spanning-tree inconsistentports

Other STP security features on Switches

Loop Guard

The Loop Guard is another enhanced feature that provides an additional layer of protection against the Layer 2 forwarding loops (STP loops) by preventing alternate or root ports from becoming designated ports because of a failure resulting in a unidirectional link. This feature is most effective when it is enabled on the entire switched network.

Loop guard operates only on interfaces that the spanning tree identifies as point-to-point.

By default, the spanning tree does not send BPDUs on root or alternate ports.

Most bridging loops that occur when STP is active happen when a port in blocking state stops receiving BPDUs on the interface and therefore transitions to forwarding state – creating an all-ports-forwarding loop.

If BPDUs are being sent over a link but the flow of received BPDUs stops for some reason, the last known BPDU is kept until the Max Age timer expires. Then that BPDU is flushed, and the switch thinks there is no longer a need to block the port. After all, if no BPDUs are received, there must not be another STP device connected there.

The switch then moves the port through the STP states until it begins to forward traffic—and forms a bridging loop. In its final state, the port becomes a designated port where it begins to relay or send BPDUs downstream, when it actually should be receiving BPDUs from upstream.

When enabled, Loop Guard keeps track of the BPDU activity on nondesignated ports. While BPDUs are received, the port is allowed to behave normally. When BPDUs go missing, Loop Guard moves the port into the loop-inconsistent state. The port is effectively blocking at this point to prevent a loop from forming and to keep it in the nondesignated role.

When BPDUs are received on the port again, Loop Guard allows the port to move through the normal STP states and become active. In this fashion, Loop Guard automatically governs ports without the need for manual intervention.

By default, Loop Guard is disabled on all switch ports.

To enable loop guard globally on the switch:

Switch(config)# spanning-tree loopguard default

You can override this setting of the spanning-tree loopguard default global configuration command.

To enable or disable loop guard on an interface:

Switch(config-if)# [no] spanning-tree guard loop

To verify Loop Guard:

Switch# show spanning-tree interface interface-id detail

Although Loop Guard is configured on a switch port, its corrective blocking action is taken on a per-VLAN basis. In other words, Loop Guard doesn’t block the entire port; only the offending VLANs are blocked.

For the same reason, if enabled on an EtherChannel interface, the entire channel is blocked for a particular VLAN, not just one link (because EtherChannel is regarded as one logical port from the STP point of view).

Loop guard should be applied to all non-designated ports (more precisely, on root and alternate ports) for all possible combinations of active topologies. As long as the loop guard is not a per-VLAN feature, the same trunk port might be designated for one VLAN and non-designated for the other.

Note: to avoid bridging loops, you can enable Loop Guard on all switch ports, regardless of their functions. The switch figures out which ports are nondesignated and monitors the BPDU activity to keep them nondesignated.

Interoperability of Loop Guard with Other STP Features

·    The root guard is mutually exclusive with the loop guard feature. The root guard is used on designated ports, and it does not allow the port to become non-designated. The loop guard works on non-designated ports and does not allow the port to become designated through the expiration of max_age. The root guard cannot be enabled on the same port as the loop guard. When the loop guard is configured on the port, it disables the root guard configured on the same port.

·    Both uplink fast and backbone fast are transparent to the loop guard feature.

·    Loop guard cannot be enabled for ports on which portfast is enabled. Since BPDU Guard works on portfast-enabled ports, some restrictions apply to BPDU Guard.

·    Loop guard should not be enabled on shared links. If you enable loop guard on shared links, traffic from hosts connected to shared segments might be blocked.

·    Loop guard functions correctly in the MST environment. When the switch is operating in MST mode, BPDUs are not sent on nonboundary ports only if the interface is blocked by loop guard in all MST instances. On a boundary port, loop guard blocks the interface in all MST instances.

EtherChannel Guard

The EtherChannel Guard feature is used to detect EtherChannel misconfigurations between the switch and a connected device. An example of a misconfiguration is when the channel parameters are not identical and do not match on both sides of the EtherChannel. Another example could be when only one side is configured with channel parameters. EtherChannel parameters must be the same on both sides for the guard to work.

When the switch detects an EtherChannel misconfiguration, the EtherChannel Guard places the switch interface in the error-disabled state and displays an error message.

The EtherChannel Guard feature can be enabled by using the global configuration command:

Switch(config)# spanning-tree etherchannel guard misconfig

STP Terminology

BID (Bridge ID) = bridge priority + MAC address; if bridge priority is the same in all the switches, the switch with the lower MAC address wins the choice for Root bridge.

Root port: port with the lowest-cost path from non-root bridge to root bridge. Each non-root bridge is assigned a single root port that sends and receives traffic.

· On non-root bridges only.

· Best path cost to the root bridge.

· Only one per switch and active at any time.

· Is always in forwarding state in an active/stable topology.

Designated port: non-root port with the lowest path cost to the root bridge. Each segment has a single destinated port. All ports on the root bridge act as designated ports (send and receive traffic as well as BPDUs). In the event of a tie, the lowest sender bridge ID serves as a tie breaker for the choice of designated ports.

   - On root and non-root bridges.

   - All ports on root bridge are designated ports.

   - Receives and forwards frames towards the root bridge as needed.

   - Only one per segment.

Non-designated or non-root port: switch ports that are neither root ports nor designated ports. These ports break any bridging loop that would form otherwise. They are placed in the blocking state.

Alternate port: is a port role of RSTP.

* Offers an alternative path towards the root bridge, but is in discarding state in an active topology.

* Present on nondesignated switches.

* Provides a backup of your own Root port. If your Root port fails, the Alternate port is allowed to immediately transition into the Forwarding state and become the new Root port (in essence, the Alternate port is the one that receives the second best BPDU).

PORT SECURITY - Mitigating MAC Spoofing and MAC Table Overflow Attacks

By limiting the number of permitted MAC addresses on a port to one, port security can be used to control unauthorized expansion of the network.

Once MAC addresses are assigned to a secure port, the port does not forward frames with source MAC addresses outside the group of defined addresses.

To prevent MAC Address flooding, port security can be used. Enabling port security limits MAC flooding attacks and locks down the port.

§  Configure port security to define the number of MAC addresses allowed on a given port.

§  It’s a Cisco-proprietary feature on Catalyst switches (disabled by default).

§  You can use port security with dynamically learned and static MAC addresses.

§  Port security is configured on untrusted user ports.

§  “Sticky learning” combines dynamically learned and statically configured addresses.

§  Port Security restricts a port’s ingress traffic by limiting the MAC addresses that are allowed to send traffic into the port.

§  When you assign secure MAC addresses to a secure port, the port does not forward ingress traffic that has source addresses outside the group of defined addresses.

§  If you limit the number of secure MAC addresses to one and assign a single secure MAC address, the device attached to that port has the full bandwidth of the port.

Port security can also mitigate spoofing attacks by limiting access through each switch port to a single MAC address. This prevents intruders from using multiple MAC addresses over a short time period but does not limit port access to a specific MAC address. The most restrictive port security implementation would specify the exact MAC address of the single device that is to gain access through each port. Implementing this level of security, however, requires considerable administrative overhead.

Port security has a sticky MAC addresses feature that can limit switch port access to a single, specific MAC address without the network administrator having to gather the MAC address of every legitimate device and manually associate it with a particular switch port.

When sticky MAC addresses are used, the switch port converts dynamically learned MAC addresses to sticky MAC addresses and subsequently adds them to the running configuration as if they were static entries for a single MAC address to be allowed by port security. Sticky secure MAC addresses will be added to the running configuration but will not become part of the startup configuration file unless the running configuration is copied to the startup configuration after addresses have been learned. If they are saved in the startup configuration, they will not have to be relearned upon switch reboot, and this provides a higher level of network security.

Port security also sets an SNMP trap alerting of any violation. Port security allows the frames from already secured MAC address below the maximum number of MAC addresses enabled on that port, and any frame with a new MAC address over the limit is dropped.

The switch supports these types of secure source MAC addresses:

• Static secure MAC addresses—These are manually configured by using the switchport port-security mac-address mac-address interface configuration command, stored in the address table, and added to the switch running configuration.

• Dynamic secure MAC addresses—These are dynamically configured (by using the switchport port-security interface configuration command), stored only in the address table, and removed when the switch restarts.

• Sticky secure MAC addresses—These can be dynamically learned or manually configured, stored in the address table, and added to the running configuration. If these addresses are saved in the configuration file, when the switch restarts, the interface does not need to dynamically reconfigure them and they are treated as static secure MAC address.

Configuring Port Security

To enable port security on the interface (learning dynamic secure MAC addresses, disabled by default):

Switch(config-int)# switchport port-security

Specify the maximum number of  MACs allowed (default is 1):

Switch(config-int)# switchport port-security maximum number              (range: 1 to 132)

For example, if the maximum number of hosts allowed is 5, an attacker can not flood the switch with many source MAC addresses and so we are preventing MAC flooding attacks.

Note If you try to set the maximum value to a number less than the number of secure addresses already configured on an interface, the command is rejected.

Specify the violation action when requirements defined are not met or exceeded:

 Switch(config-int)# switchport port-security violation {shutdown | restrict | protect}

·  Shutdown (default action) puts int interface in err-disable state and sends an SNMP trap, and manual intervention (shutdown and no shutdown) or errdisable recovery must be used to make the interface usable.

·  Restrict will drop violator’s frames, a syslog message is created and an SNMP trap is sent and the violation counter increments.

·  Protect will drop frames quietly from MACs not specified or non allowed, but there is no log of violation (not recommended).

Note: in rectric and protect modes the port is allowed to stay up, but all packets from violating MAC addresses are dropped.

Switch(config-int)# switchport port-security violation shutdown vlan   In this mode, only the VLAN on which the violation occurred is error-disabled.

Tip: If an interface is undergoing^sufriendo the restrict or protect condition, you might need to clear the learned MAC addresses so that a specific host can use the switch port.

To dynamically bring all secure ports out of the error-disabled state:

switch(config)# errdisable recovery cause psecure-violation

To clear a clear all dynamically learned secure addresses:

Switch(config)# clear port-security dynamic [address mac-addr | interface type mod/num]

Static Secure Mac Addresses

Statically assign MAC addresses (optional, by entering a 48-bit MAC address):

Switch(config-if)# switchport port-security mac-address MAC-address

Additional secure MAC addresses can be added up to the maximum value.

 The MAC address is given in dotted-triplet format. If the number of static addresses configured is less than the maximum number of addresses secured on a port, the remaining addresses are learned dynamically.

Example: Switch(config-if)# switchport port-security mac-address 0000.0000.0003

0000.0000.0003 is an static secure MAC address

Port Aging

•        Port security aging can be used to set the aging time for static and dynamic secure addresses on a port.

•        Two types of aging are supported per port:

–       absolute - The secure addresses on the port are deleted after the specified aging time.

–       inactivity - The secure addresses on the port are deleted only if they are inactive for the specified aging time.

Switch(config-if)# switchport port-security aging {static | time minutes | type {absolute | inactivity}}

static: Enable aging for statically configured secure addresses on this port.

time:

•        Specify the aging time for this port.

•        The range is 0 to 1440 minutes.

•        If the time is 0, aging is disabled for this port.

type absolute:

•        Set absolute aging type.

•        All the secure addresses on this port age out exactly after the time (minutes) specified and are removed from the secure address list.

type inactivity:

•        Set the inactivity aging type.

•        The secure addresses on this port age out only if there is no data traffic from the secure source address for the specified time period.

Set the aging time for each assigned MAC:

Switch(config-if)# switchport port-security aging time [0-1440] {restrict | protect}

*  0-1440 in minutes. Use this feature to remove and add PCs on a secure port without manually deleting the existing secure MAC addresses; all the secure addresses on this port age out exactly after the time specified and are removed from the secure address list, while still limiting the number of secure addresses on a port.  If the aging time is set to 0 (default), aging is disabled. By default, no aging occurs.

Enable aging for the statically configured secure address on the port:

Switch(config-if)# switchport port-security aging static

This configuration tells the switch to age out for statically configured secure MAC addresses.

Sticky secure addresses

Allows the switch to dynamically learn up to the maximum number of MAC addresses (optional):

Switch(config-if)# switchport port-security mac-address sticky

After enabling, you will notice the currently connected MAC address(es) will appear in the running config as:

switchport port-security mac-address sticky sticky-mac-address (static sticky MAC configuration)

Note Sticky MAC addresses can be dynamically learned or manually configured, stored in the address table, and added to the running configuration. Although sticky secure addresses can be manually configured, it is not recommended. "This configuration isn’t necessary”.

When enabling port security with sticky MAC addresses, note the following information:

•When you enter the switchport port-security mac-address sticky command:

–All dynamically learned secure MAC addresses on the port are converted to sticky secure MAC addresses.

–Static secure MAC addresses are not converted to sticky MAC addresses.

–Secure MAC addresses dynamically learned in a voice VLAN are converted (or not converted) to sticky MAC addresses, it depends on the IOS platform.

–New dynamically learned secure MAC addresses are sticky.

•When you enter the no switchport port-security mac-address sticky command, all sticky secure MAC addresses on the port are converted to dynamic secure MAC addresses.

Port Security on trunk interfaces

Port security can only be configured on static access ports (switchport mode access) or static trunk ports (DTP  disabled: switchport mode trunk; switchport nonegotiate). A secure port cannot be a dynamic access port.

On a trunk port only, specify the VLAN ID and the MAC address.

Switch(config-if)# switchport port-security mac-address a.b.c vlan vlan-id                              (vlan-id: 1 – 4094)

If no VLAN ID is specified, the native VLAN is used.

For trunk ports, you can set the maximum number of secure MAC addresses on a VLAN:

Switch(config-if)# switchport port-security maximum value vlan {vlan-id | vlan-list}

•        Vlan vlan-id: set a per-VLAN maximum value.

•        vlan vlan-list: set a per-VLAN maximum value on a range of VLANs separated by a hyphen or a series of VLANs separated by commas.

If the vlan keyword is not entered, the default value is used.

Port Security on interfaces that use voice VLANs

Switch(config)# interface fastethernet0/1

Switch(config-if)# switchport mode access

Switch(config-if)# switchport access vlan 2

Switch(config-if)# switchport voice vlan 3

Switch(config-if)# switchport port-security

Switch(config-if)# switchport port-security maximum 3

Switch(config-if)# switchport port-security violation restrict

Switch(config-if)# switchport port-security a.b.c vlan voice

Switch(config-if)# switchport port-security d.e.f vlan access

Switch(config-if)# switchport port-security maximum 2 vlan access

Switch(config-if)# switchport port-security maximum 1 vlan voice

Note: The voice keyword is available only if voice VLAN is configured on a port and if that port is not the access VLAN.

MAC Address Notification

The MAC Address Notification feature sends SNMP traps to the network management station (NMS) whenever a new MAC address is added to or an old address is deleted from the forwarding tables.

switch(config)#mac address-table notification ?

  change  Enable/Disable MAC Notification feature on the switch

switch(config)#mac address-table notification change ?

  history-size  Number of MAC notifications to be stored

  interval      Interval between the MAC notifications

  <cr>

Verifying Port Security

To display a summary of the port-security status:

Switch# show port-security

To verify the port security settings of an specific interface:

Switch# show port-security interface interface-id

To display MAC address table security information:

Switch# show port-security address

The “Remaining age” column is populated only when specifically configured for a given interface.

To see a quick summary of only ports in the Errdisable state, along with the reason for errdisable:

Switch# show interfaces status err-disabled

Configuring Easy VPN Server on Cisco IOS Routers with CCP

The Cisco Easy VPN server allows a remote user to connect to the corporate network using an IPSec tunnel. Easy VPN servers can be deployed in a Cisco IOS router or an ASA appliance. To connect with the VPN server, we can use a Cisco VPN client software that can be installed on an operating system. The Easy VPN feature minimizes the configuration requirement at a remote location where we can put all the configuration on a VPN server and push the access policies to the client upon a VPN tunnel connection from a Cisco VPN server.

Another option to connect with the VPN server is by using Easy VPN Remote, that enables Cisco routers and security appliances to establish a site-to-site VPN connection to a Cisco Easy VPN Server.

GNS3 example

You don’t need a real router to practise most of the CCNAS labs. GNS3 works fine and you can simulate ASA, IPS, ISR routers, etc.

Here, CCP_connection is a cloud simulating a loopback interface with IP address of 192.168.0.3/24 .

CCP and Cisco VPN client are installed on my PC.

Allow CCP connection

First of all, you must configure the router to allow CCP access. The commands are:

hostname R2

!

username juantron privilege 15 password 0 juantron

!

interface FastEthernet0/0

 ip address 192.168.0.1 255.255.255.0

 no shutdown

!

ip http server

ip http secure-server

ip http authentication local

!

line con 0

 exec-timeout 0 0

 privilege level 15

 logging synchronous

 login local

!

line vty 0 4

 privilege level 15

 transport input telnet ssh

 login local

Prerrequisites: AAA must be enabled to configure Easy VPN Server (the wizard ask us to configure it).

The tasks to configure are:

-        Select the interface on which client connections will terminate and selec the method to authenticate VPN clients (PSK, digital certificates (RSA Signatures) or both).

-        Configure IKE policies (IKE Phase 1): select encryption algorithms for confidenciality (DES, 3DES, AES, SEAL, RSA); select hashing algorithms for data integrity (MD5, SHA); select secure key exchange algorithms (DH group).

-        Configure a IPSec transform set (IKE Phase 2).

-        Select the Group Authorization method: Local, RADIUS, RADIUS and Local or AAA. Here you can create users.

-        Create a Group Policy: stablish the key for PSK; create a POOL to allocate an internal IP address to a client.

Go to Configure > Security > VPN > Easy VPN Server .

Click Launch Easy VPN Server Wizard .
Note: you can see the following message:

You have to configure AAA before start the Easy VPN Server Configuration. So, click Yes:

Click Deliver to continue:

Configure the Interface for this server (Fa0/0 in my GNS3 example):

Click Next and Configure IKE proposals to delete the Cisco CP Default:

Note Choice group5 for D-H Group in this case, but Maybe VPN Server doesn’t support group5.

Click OK and Next and Configure Transform Set. Click Add (when you add a transform set, Cisco CP Default transform set is deleted):

NOTE Click Show Advanced>> to see that Mode “tunnel” is selected. Remember ESP tunnel mode is used in remote and Site to Site VPN to full encrypt the packets.

Click OK and Next and Configure VPN Authentication Method List:

Click Next after the method has been selected:

If you don’t have a RADIUS Server, select “Select an Existing AAA Method List” instead of “Local Only”.

Make sure the check box next to Enable User Authentication is checked. Here, you can Add User Credentials by clicking in this buttom and then Add to create the users.

Click Next to Configure VPN Authentication Group Policy. Click Add:

Select OK and Next. The window Configuration Summary is showed:

You can check the check box “Test VPN connectivity after configuring”.

Click Finish to deliver the configuration to the router.

If you checked the box “Test VPN connectivity after configuring”, a new window is showed. Click Start:

NOTE This is the first place you should check when a VPN configuration isn't working correctly.

Finally, you can Edit Easy VPN Server:

CLI Commands to deliver to the router

aaa authorization network ciscocp_vpn_group_ml_1 local

ip local pool SDM_POOL_1 10.5.1.1 10.5.1.10

crypto ipsec transform-set ESP_AES-256_SHA esp-sha-hmac esp-aes 256

 mode tunnel

 exit

crypto dynamic-map SDM_DYNMAP_1 1

 set transform-set ESP_AES-256_SHA

 reverse-route

 exit

crypto map SDM_CMAP_1 65535 ipsec-isakmp dynamic SDM_DYNMAP_1

interface FastEthernet0/0

 no crypto map

 crypto map SDM_CMAP_1

 exit

crypto map SDM_CMAP_1 isakmp authorization list ciscocp_vpn_group_ml_1

crypto map SDM_CMAP_1 client authentication list default

crypto map SDM_CMAP_1 client configuration address respond

crypto isakmp client configuration group Marketing

 key 0 ******

 pool SDM_POOL_1

 netmask 255.255.255.0

 exit

crypto isakmp policy 2

 authentication pre-share

 encr aes 256

 hash sha

 group 2

 lifetime 86400

 exit

crypto isakmp policy 1

 authentication pre-share

 encr 3des

 hash sha

 group 2

 lifetime 86400

 exit

crypto isakmp xauth timeout 15

Connecting using the client

After this, you can use Cisco VPN Client to connect to the Server.

Features of Cisco VPN Client:

•        Establishes end-to-end, encrypted VPN tunnels for secure connectivity.

•        Compatible with all Cisco VPN products.

•        Supports the innovative Cisco Easy VPN capabilities.

In my GNS3 example (EASY_VPN_SERVER_ON_R2), I’ve created an authentication group named Marketing and a PSK key “juanma”. The IP addres of the Server’s interface is 192.168.0.1.

Launch VPN client and configure the connection to this Server. Finally click on the Connect buttom. The following window is showed:

In my case: username “juantron” and password “juantron” was configured. Click OK :

That’s all. Now, you can work at home with your laptop and download mail, access to server’s files, etc.

Verifying VPN connection

You have two options after the client has stablished a connection to the server:

-        Check “Test VPN connectivity after configuring”.

-        Usin monitoring feature on CCP. Click: Monitor > Security > VPN Status > Easy VPN Server

You also can disconnect the peer from here by clicking the Disconnect buttom.

Or you can see the IPSec tunnel:

NOTE All you have seen here has been tested on my PC and many of the screen captures have been taken from my PC. All my gratitude to GNS3 team, Cisco books and links, and other blogs that helped me understand VPN connections.