How to Clear IPSec VPN Remote Peer on Cisco IOS

by Nish Vamadevan on 17/08/2013 @nish

The following command clears the crypto sessions for a remote IKE peer. You can use context sensitive help ? to find other options.

Syntax

clear crypto session remote IP_ADDRESS

Example:

clear crypto session remote 1.1.1.1

Details of Account Lockout Settings and Processes

With the account lockout feature enabled, access to the account is denied when the number of logon attempts that did not work exceeds the LockoutThreshold registry value (the account lockout threshold) in a specified amount of time. A locked-out account cannot be used until it is reset by an administrator or until the lockout duration for that account expires.
Account Lockout is disabled on default installations of Windows NT Server 4.0, Windows 2000, and Windows Server 2003 domains. Account lockout operation is enabled after the domain administrator enables settings in the default domain policy. The policy settings remain enabled when you upgrade domain controllers to a later version of an operating system.
Although the Group Policy Object Editor appears to support account lockout and password policy in each organizational unit, these settings actually occur across the domain; you must define the settings on the root organizational unit for the domain. Microsoft recommends that you define account lockout and password policies in only one Group Policy object (GPO) for every domain (in the Default Domain policy settings).

Password Policy Settings

The first step that you should use to secure your network is to enforce password policy settings. When you implement a secure password policy, you may not need to implement the account lockout feature.

Password Complexity

Passwords, by default, can include any combination of characters; passwords can also be blank. Microsoft recommends that you require the use of complex passwords to help ensure that passwords provide the best security possible. These complex passwords are much more resistant to attack than blank or simple passwords.
To enforce password complexity in your organization, you can enable the Password must meet complexity requirements security setting. The complexity requirements enforced by this setting are stored in Passfilt.dll. In Windows 2000 operating systems and later, Passfilt.dll is built into the operating system. In Windows NT Server 4.0, you must add the Passfilt.dll file to the operating system to achieve the same results. Passfilt.dll is included in Windows NT Server 4.0 Service Pack 2 and in later service packs.
By default, complex passwords enforced by Passfilt.dll have the following properties:

• Do not contain all or part of the user's account name.
  
• Contain characters from three of the following four categories:
  
  
  • English uppercase characters (A through Z).
    
  • English lowercase characters (a through z).
    
  • Base-10 digits (0 through 9).
    
  • Non-alphanumeric (for example, !, $, #, %). extended ASCII, symbolic, or linguistic characters.
    

Note
Depending on your environment, using extended ASCII, symbolic, or linguistic characters in passwords can have unexpected results. It is highly recommended that you test these characters before using them in production.

When implementing this policy, it is recommended to inform your users of the change in policy so that a smooth transition can take place from a simple password to a complex password. Otherwise, users may be confused by the new password criteria and circumvent security to avoid the difficulty.
You can create and register your own custom password filter if you want to modify the complexity requirements enforced in the security setting.

Password History

You can use the Password History setting to prevent users from repeatedly using the same password. When you use the password history feature, a user is prevented from using passwords that they used in the past, up to the number of passwords that you specify. You can configure Windows to retain between 0 and 24 passwords by using the Password History feature. Microsoft recommends that you set the password history to the maximum value to help ensure the least amount of password reuse by users.
In the Windows 2000 Server family and later, the location of the password history is in the Default Domain policy settings at Computer Configuration\Windows Settings\Security Settings\Account Policies\Enforce Password History.
Valid non-zero values are between 1 and 24. The default value is 24 for domain controllers running a member of the Windows Server 2003 family, 3 for domain controllers running a member of the Windows 2000 family, and 0 for all other Windows operating systems.

Minimum Password Length

You can use the Minimum Password Length setting to decrease the chances that a password can be discovered by a malicious user. For more information about the Minimum Password Length setting, see "Understanding Password Complexity" in this document.
In versions of Windows 2000 operating systems and later, you can change the Minimum Password Length setting in the Group Policy MMC, in the Default Domain policy settings at Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\Minimum Password Length.
An administrator can set the value between 0 and 14 characters. Each additional character increases the total possible password permutations. However, if you set the value to 0, blank passwords are not permitted.
Valid non-zero values are between 1 and 14, with a default value of zero.

Maximum Password Age

You can use the Maximum Password Age setting to limit the time for which a given password is valid. This decreases the odds of being able to crack a password. For more information, see the example in the Passwords section in this document.
In the Windows 2000 family and later, the Maximum Password Age setting is located in the Group Policy MMC, in the Default Domain policy at Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\Maximum Password Age.
This setting determines the period of time (in days) that a user can use their password before the computer requires the user to change it. You can set passwords to expire in between 1 and 999 days, or you can specify that passwords never expire by setting the number of days to 0.
Valid non-zero values are between 1 and 999, with a default value of 42.

Minimum Password Age

You can use the Minimum Password Age setting to preventing users from repeatedly changing passwords until the user is able to use their original password, if you enforce the Password History setting.
When you use the Minimum Password Age setting, you prevent the circumvention of password expiration and help to assure unique passwords.
The Minimum Password Age setting determines the period of time (in days) that a password must be used before the user can change it. You can set the value to between 1 and 999 days, or allow immediate changes by setting the number of days to 0.
Configure the Minimum Password Age setting to be a number that is larger than 0 if you want the Enforce Password History setting to be effective. If you do not set a minimum password age, users can repeatedly cycle through passwords until they are able to use an old favorite password. This could allow users to circumvent established password policy.
The Minimum Password Age setting is located in the Group Policy MMC, in Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy.
Valid non-zero values are between 1 and 999, with a default value of one for domain controllers and zero for other computers.

Account Lockout Settings

You can set the Account Lockout settings in the Active Directory Users and Computers MMC by using the procedure in this section.

Note
The value that you set for LockoutDuration cannot be a value that is less than OberservationWindow.

1. Click Start, click Settings, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Users and Computers.
   
2. In the console tree, right-click the domain on which you want to set a Group Policy object.
   
3. Click Properties, and then click the Group Policy tab.
   
4. In Group Policy Object Links, click Default Domain Policy or create and name your Group Policy object, and then click Edit.
   
5. In the console tree, double-click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Account Policies, and then click Account Lockout Policy.
   
6. In the details pane, right-click the policy setting that you want, and then click Properties.
   
7. If you are defining this policy setting for the first time, click Define this policy setting.
   
8. Click the options that you want, and then click OK.
   

ObservationWindow

The ObservationWindow setting (also known in Group Policy as the Reset account lockout counter after setting) is the number of minutes after which an accounts badPwdCount registry value is reset. You can use the ObservationWindow setting to help mitigate lockout issues that are initiated by users. When you enable this setting, the bad password attempt is removed from the server after a period of time.
Valid non-zero values are between 1 and 99999, with a default value of 30.

LockoutDuration

The LockoutDuration setting (also known in Group Policy as the Account lockout duration setting) is the amount of time, in minutes, that account lockout is enforced on an account that has exceeded the LockoutDuration registry value, measured from the time of lockout. If you set the LockoutDuration registry value to 0, the account is permanently locked out until either an administrator or a user who has a delegated account resets the account. If the administrator or a delegated user account does not unlock the account, the operating system unlocks the account after the number of minutes that you set in the LockoutDuration registry value. Non-zero values for the LockoutDuration registry value reduce the administrative overhead of unlocking accounts by having them unlocked automatically; however, non-zero values do not provide the added security of user validation before the account is restored.
Valid non-zero values are between 1 and 99999, with a default value of 30.

LockoutThreshold

The LockoutThreshold setting (also known in Group Policy as the Account lockout threshold setting) is the number of times that the user, computer, service, or program can send a bad password during logon authentication before the account is locked out. Account lockout occurs when the badPwdCount registry value is equal to or exceeds the LockoutThreshold value. You can adjust the LockoutThreshold value to prevent both brute force and dictionary attacks, but you can set the value too low to capture user error and other non-attack errors. Administrators often set this value too low (3 through 5), which causes a large number of account lockouts because of user error, program caching by service accounts, or issues with networking clients. If you set the LockoutThreshold value to 0, no account lockouts occur on the domain.
Valid non-zero values are between 1 and 999, with a default value of zero.

Account Lockout Values

Account lockout registry values are described in this section. These values store the information that you need to track account lockout information.

Note
These values are maintained by the operating system, so you should not manually modify them.

badPasswordTime

The badPasswordTime value stores the last time that the user, computer, or service account submitted a password that did not match the password on the authenticating domain controller This property is stored locally on each domain controller that is in the domain. A value of 0 means that the last incorrect password time is unknown. For an accurate value for the user's last incorrect password time in the domain, you must query each domain controller that is in the domain; the largest one is the accurate value. For more information, see the "LockoutStatus.exe" section in this document.

Note
The badPasswordTime registry value is not replicated between domain controllers. This attribute, however, is reported to the PDC operations master.

badPwdCount

The badPwdCount value stores the number of times that the user, computer, or service account tried to log on to the account by using an incorrect password. This value is maintained separately on each domain controller in the domain, except for the PDC operations master of the accounts domain that maintains the total number of incorrect password attempts. A value of 0 indicates that the value is unknown. For an accurate total of the user's incorrect password attempts in the domain, you must query each domain controller and use the sum of the values. For more information, see the "LockoutStatus.exe" section in this document.

Note
The badPwdCount registry value is not replicated between domain controllers. This registry value, however, is reported to the PDC operations master.

ntPwdHistory

The ntPwdHistory registry value contains the password history for the user in Windows NT Server 4.0 one-way function (OWF). Both Windows 2000 and the Windows Server 2003 family use the Windows NT Server 4.0 OWF. This property is used by only the operating system. Note that you cannot obtain the password from the password in OWF form.

Other Settings that Affect Account Lockout

This section describes another setting that affect account lockout behavior. While the setting is focused on authentication, it is closely tied with account lockout policy.
You can set the authentication settings in the Active Directory Users and Computers MMC by using the procedure in this section.

1. Click Start, click Settings, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Users and Computers.
   
2. In the console tree, right-click the domain on which you want to set a Group Policy object.
   
3. Click Properties, and then click the Group Policy tab.
   
4. In Group Policy Object Links, click Default Domain Policy or create and name your Group Policy object, and then click Edit.
   
5. In the console tree, double-click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Local Policies, and then click Security Options.
   
6. In the details pane, right-click the policy setting that you want, and then click Properties.
   
7. If you are defining this policy setting for the first time, click Define this policy setting.
   
8. Click the options that you want, and then click OK.
   

ForceUnlockLogon

The ForceUnlockLogon setting (also known as Interactive logon: Require Domain Controller authentication to unlock workstation controls the behavior of a computer running Windows 2000, Windows XP or the Windows Server 2003 family when the computer is unlocked by a user.

• With a value of 1 (or Enabled, in Group Policy), unlocking the computer also performs a synchronous logon to the domain to verify user authenticity. This option is slower than allowing cached authentication because it requires network-based authentication.
  
• With a value of 0 (or Disabled, in Group Policy), cached information is used to verify the users identity. When the verification is successful, the user is logged on. Windows then performs an asynchronous logon to the domain in the background. This means that the user can still unlock a computer when the account is unlocked.
  
• Valid values are 0 and 1, with a default value of 0.
  

For additional information about unlocking a workstation, see the following articles:

• "Information About Unlocking a Workstation" in the Microsoft Knowledge Base.
  
• "Screensaver Password Works Even If Account Is Locked Out" in the Microsoft Knowledge Base.
  

Replication and Account Lockout

Account lockout relies on the replication of lockout information between domain controllers to ensure that all domain controllers are notified of an accounts status. In addition, password changes must be communicated to all domain controllers to ensure that a user's new password is not considered incorrect. This data replication is accomplished by the various replication features of Active Directory and is also discussed in this section.

Immediate Replication

When you change a password, it is sent over Netlogon's secure channel to the PDC operations master. Specifically, the domain controller makes a remote procedure call (RPC) to the PDC operations master that includes the user name and new password information. The PDC operations master then locally stores this value.
Immediate replication between Windows 2000 domain controllers is caused by the following events:

• Lockout of an account
  
• Modification of a Local Security Authority (LSA) secret
  
• State changes of the Relative ID (RID) Manager
  

Urgent Replication

Active Directory replication occurs between domain controllers when directory data is updated on one domain controller and that update is replicated to all other domain controllers. When a change in directory data occurs, the source domain controller sends out a notice that its directory store now contains updated data. The domain controller's replication partners then send a request to the source domain controller to receive those updates. Typically, the source domain controller sends out a change notification after a delay. This delay is governed by a notification delay. (The Windows 2000 default notification delay is 5 minutes; the Windows Server 2003 default notification delay is 15 minutes.) However, any delay in replication can result in a security risk for certain types of changes. Urgent replication ensures that critical directory changes are immediately replicated, including account lockouts, changes in the account lockout policy, changes in the domain password policy, and changes to the password on a domain controller account. With urgent replication, an update notification is sent out immediately, regardless of the notification delay. This design allows other domain controllers to immediately request and receive the critical updates. Note, however, that the only difference between urgent replication and typical replication is the lack of a delay before the transmission of the change notification. If this does not occur, urgent replication is identical to standard replication. When replication partners request and subsequently receive the urgent changes, they receive, in addition, all pending directory updates from the source domain controller, and not only the urgent updates.
When either an administrator or a delegated user unlocks an account, manually sets password expiration on a user account by clicking User Must Change Password At Next Logon, or resets the password on an account, the modified attributes are immediately replicated to the PDC emulator operations master, and then they are urgently replicated to other domain controllers that are in the same site as the PDC emulator. By default, urgent replication does not occur across site boundaries. Because of this, administrators should make manual password changes and account resets on a domain controller that is in that user's site.
The following events are not urgent replications in Windows 2000 domains:

• Changing the account lockout policy
  
• Changing the domain password policy
  
• Changing the password on a computer account
  
• Domain trust passwords
  

For additional information about urgent and immediate replication, see "Urgent Replication Triggers in Windows 2000" in the Microsoft Knowledge Base.

Single User Object On Demand Replication

In the Windows 2000 family, when an administrator resets and immediately expires a user's password on a domain controller in site A (so that the user is given a new password but forced to change it when the user first logs on), the logon may still succeed when the user logs on with that new password in site B. This occurs because the domain controller chains to the PDC operations master during authentication. However, the users password change may not replicate correctly because domain controllers in site B do not yet have the reset password. This occurs because there is replication latency between sites.
An update is available for Windows 2000 that changes this behavior. For more information to help change this behavior by implementing an "on-demand" replication scheme, see "You Cannot Change Your Password After an Administrator Resets It" on the Microsoft Knowledge Base. The updated replication scheme allows the domain controller to contact the PDC operations master to request an update of the user object that failed authentication because of an incorrect password. This helps to ensure that the authenticating domain controller receives the most current user account information as quickly as possible.

Mixed Environments with Windows NT Server 4.0 and Active Directory Domain Controllers

If servers that are running Windows NT Server 4.0 and earlier are in the domain, account lockout is not a dependable security feature.
For example, a Windows NT Server 4.0, Enterprise Edition, backup domain controller (BDC) may authenticate a user, even though the account is marked as locked out on a domain controller that is running Windows NT Server 4.0 and earlier. Also, Windows NT Server 4.0, Enterprise Edition, BDCs cannot unlock an account. The server that is running Windows NT Server 4.0, Enterprise Edition, can increment the bad password count when the user logs in with an incorrect password. That server can then report the increment to the other domain controller. However, the Windows NT Server 4.0, Enterprise Edition, BDC does not send this information to the domain controller that is running Windows NT Server 4.0 and earlier if the user logs on with the correct password. Because of this, the bad password count is not reset after the successful logon attempt.
The account lockout feature of Microsoft LAN Manager is not compatible with the account lockout feature on computers that are running Windows NT Server 4.0 and earlier. The domain controller that is running Windows NT Server 4.0 and earlier does not replicate any account lockout information to a LAN Manager BDC. If the account is marked as locked out on the Windows NT Server 4.0 and earlier domain controller, the LAN Manager BDC may still validate the user. The LAN Manager BDC displays the account lockout policy as set to "Never," even in a domain running Windows NT Server 4.0 and earlier where account lockout is enabled.
For these reasons, you should consider ensuring that all domain controllers in your network are running Windows 2000 or the Windows Server 2003 family. This is the only way to ensure that account lockout is enforced consistently across your network.

Easy Remote Client VPN Solution with a Cisco ASA

03/08/2015 Author: thejimmahknows

2 Comments

I’ve posted an article on Client VPN setup using OpenVPN and I noticed I didn’t have one regarding Cisco ASA. A Cisco ASA being a very common Security Appliance used by small and large companies. This article will cover how to setup a standard remote client VPN utilizing IPsec as the crypto carrier. Cisco also has their own proprietary remote client VPN solution called AnyConnect. I will be posting an article after this one on how to set an AnyConnect solution up and include what the differences are between it and the standard IPsec remote client VPN contained in this article.
A remote client VPN is something very common in workplace now-a-days. It allows users to appear as if they are on the company’s internal network over an insecure medium(e.g. Internet, untrused Network, etc). It does so by using IPsec. IPsec is a tried and true Layer 3 securing technique that requires both parties involved to mutually authenticate each other before passing traffic.
A few things to keep in mind regarding remote client VPNs.

• First, a subnet is required for client’s to be put on when successfully authenticated and authorized via the remote client VPN. This can be the same subnet as one already existing on your network or a separate one with a firewall in-between The later being best in practice and security.
• Secondly, deciding on split-tunneling vs all-tunneling. The difference being on the client would you like all traffic to be forced across the tunnel or allow clients to communicate with both their local network and the networks on the otherside of the VPN. For best practice and security, all-tunneling is recommended.
• Third, Access Lists and tunneled networks. Here we will decided what Remote VPN users will have access to other networks. We will also, in the case of split-tunneling, create an access-list of what networks to tunnel for the Remote VPN user.
• Fourth, provisioning standard network services for VPN user’s. Remote VPN user’s will need a default gateway, DNS servers, domain suffix, an address pool, proxy settings, etc.

Configuring the Server Side (Cisco ASA):

1. First Step: Create an Address Pool for VPN clients.

   Decided on the subnet you will be assigning to remote VPN clients. For this article I will choose 172.21.1.0/24, staring at .10 and ending at .250.
   
   ciscoasa(config)# ip local pool obj-RemoteVPNPool l 172.21.0.10-172.21.0.250 mask 255.255.255.0</code>/pre> </li> <li> <h6> Second Step: Make ACLs for allowed communication and networks to push accross the tunnel for the client. (assuming networks we want to allow communication with are 192.168.1.0/24 and we will force it to be tunneled as well)</h6> <pre></code>ciscoasa(config)# object-group network obj-VPN-NETWORK ciscoasa(config-network-object-group)# network-object 172.21.0.0 255.255.255.0 ciscoasa(config)# object-group network obj-PROTECTED-NETWORK ciscoasa(config-network-object-group)# network-object 192.168.1.0 255.255.255.0 ciscoasa(config)# access-list vpnACL extened permit ip object-group obj-VPN-NETWORK object-group obj-PROTECTED-NETWORK

   1 2 3 4 5 6 7 8 9 10 11

   ciscoasa(config)# ip local pool obj-RemoteVPNPool l 172.21.0.10-172.21.0.250 mask 255.255.255.0</code>/pre> </li> <li> <h6>Second Step: Make ACLs for allowed communication and networks to push accross the tunnel for the client. (assuming networks we want to allow communication with are 192.168.1.0/24 and we will force it to be tunneled as well)</h6> <pre></code>ciscoasa(config)# object-group network obj-VPN-NETWORK ciscoasa(config-network-object-group)# network-object 172.21.0.0 255.255.255.0   ciscoasa(config)# object-group network obj-PROTECTED-NETWORK ciscoasa(config-network-object-group)# network-object 192.168.1.0 255.255.255.0   ciscoasa(config)# access-list vpnACL extened permit ip object-group obj-VPN-NETWORK object-group obj-PROTECTED-NETWORK

2. Next step: Make an additional ACL to identify the traffic we would like the remote client to know about on the other side of the tunnel (For Split-Tunneled scenarios).

   ciscoasa(config)# access-list tunneledNets standard permit 192.168.1.0 255.255.255.0 ciscoasa(config)# access-list tunneledNets standard permit 192.168.2.0 255.255.255.0 ciscoasa(config)# access-list tunneledNets standard permit 192.168.3.0 255.255.255.0

   1 2 3

   ciscoasa(config)# access-list tunneledNets standard permit 192.168.1.0 255.255.255.0 ciscoasa(config)# access-list tunneledNets standard permit 192.168.2.0 255.255.255.0 ciscoasa(config)# access-list tunneledNets standard permit 192.168.3.0 255.255.255.0

3. Moving on: We have to create an identify NAT because our VPN traffic communicating with our Proected networks will travers two different interfaces on the Cisco ASA. We will not be performing an NAT manipulation, but the statement is required because of Cisco ASA standard security policy when traversing traffic between different interfaces.

   ciscoasa(config)# nat (outside,inside) source static obj-VPN-NETWORK obj-VPN-NETWORK destination obj-PROTECTED-NETWORK obj-PROTECTED-NETWORK

   1	ciscoasa(config)# nat (outside,inside) source static obj-VPN-NETWORK obj-VPN-NETWORK destination obj-PROTECTED-NETWORK obj-PROTECTED-NETWORK

4. VPN Attributes: Let’s set up group-policy to tie together all the attributes we are going to send to the remote client when they connect.

   ciscoasa(config)# group-policy ClientVPN_GroupPolicy internal ciscoasa(config)# group-policy ClientVPN_GroupPolicy attributes ciscoasa(config-group-policy)# banner value Welcome to thejimmahknows VPN ciscoasa(config-group-policy)# vpn-idle-timeout 30 ciscoasa(config-group-policy)# vpn-session-timeout none ciscoasa(config-group-policy)# vpn-filter value vpnACL ciscoasa(config-group-policy)# vpn-tunnel-protocol ikev1 ciscoasa(config-group-policy)# ipsec-udp enable ciscoasa(config-group-policy)# split-tunnel-policy tunnelspecified ciscoasa(config-group-policy)# split-tunnel-network-list value tunneledNets ciscoasa(config-group-policy)# dns-server value 192.168.1.3 192.168.3.4 ciscoasa(config-group-policy)# default-domain value internaldomain.local ciscoasa(config-group-policy)# split-tunnel-all-dns enable ciscoasa(config-group-policy)# address-pools value obj-RemoteVPNPool ciscoasa(config-group-policy)# ipv6-address-pools none

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

   ciscoasa(config)# group-policy ClientVPN_GroupPolicy internal   ciscoasa(config)# group-policy ClientVPN_GroupPolicy attributes ciscoasa(config-group-policy)# banner value Welcome to thejimmahknows VPN ciscoasa(config-group-policy)# vpn-idle-timeout 30 ciscoasa(config-group-policy)# vpn-session-timeout none ciscoasa(config-group-policy)# vpn-filter value vpnACL ciscoasa(config-group-policy)# vpn-tunnel-protocol ikev1 ciscoasa(config-group-policy)# ipsec-udp enable ciscoasa(config-group-policy)# split-tunnel-policy tunnelspecified ciscoasa(config-group-policy)# split-tunnel-network-list value tunneledNets ciscoasa(config-group-policy)# dns-server value 192.168.1.3 192.168.3.4 ciscoasa(config-group-policy)# default-domain value internaldomain.local ciscoasa(config-group-policy)# split-tunnel-all-dns enable ciscoasa(config-group-policy)# address-pools value obj-RemoteVPNPool ciscoasa(config-group-policy)# ipv6-address-pools none

   Let’s step thru this:
   
   • ClientVPN_GroupPolicy {internal/external} — Where to get attributes from? Internal = from this ASA, External = from external server like RADIUS or Cisco ACS
   • ClientVPN_GroupPolicy attributes — First we have to create a new group policy whcih will push down to the cilent all the network services we want to assign them.
   • banner value {your text} — This is not technically needed, however I like it because it gives the user a pop-up from their VPN software that they have successfully connected.
   • vpn-idle-time {min} — Helpful to terminate VPN connections that are idle for too long.
   • vpn-session-timeout {min} —
   • vpn-filter value {your ACL} — This is where you set the ACL with the networks your VPN Network is allowed to communicate with others inside your network.
   • vpn-tunnel protocol {ikev1} — Tells client to use ikev1 to establish a connection.
   • ipsec-udp {enable/disable} — This will enable IP NAT traversal, which is 99% of the time needed. If you don’t enable it, only one client will be able to connect in from the same remote network at a time. See What is IPsec NAT-Traversal
   • split-tunnel-policy {tunnelspecified/tunnelall} — Sets the split-tunneling policy, if any.
   • split-tunnel-network-list {standard ACL} — what networks on far side to tell the client about.
   • dns-server value {dns servers} — Specify the DNS servers to have your remote VPN clients use.
   • default-domain value {windows domain name} — Supplied to client for DNS suffix.
   • split-tunnel-all-dns {enable/disable} — Tells client whethers to ask far end of the tunnel for DNS reslution or use local network DNS. Best practice is to enable this and force remote VPN clients to always ask far end for DNS resolution.
   • address-pools value {IP pool object} — Where to get IPs for remote VPN clients from.
   • ipv6-address-pools {IP pool object/none} — IPv6 pools? Nah.
   • NOTE:For more information and other attributes, see the Cisco documentation here.

5. Proxy settings?: We can also try to push down Web Proxy settings to Internet Explorer using the following

   
   
   ciscoasa(config)# group-policy ClientVPN_GroupPolicy attributes ciscoasa(config-group-policy)# msie-proxy method modify ciscoasa(config-group-policy)# msie-proxy pac-url value http://proxyserver:8080/proxy.pac

   1 2 3

   ciscoasa(config)# group-policy ClientVPN_GroupPolicy attributes ciscoasa(config-group-policy)# msie-proxy method modify ciscoasa(config-group-policy)# msie-proxy pac-url value http://proxyserver:8080/proxy.pac

   
    

6. IPSec Phase1: Here we set up Phase 1 to be used by this IPsec tunnel.

   
   
   ciscoasa(config)# crypto ikev1 policy 1 ciscoasa(config-ikev1-policy)# authentication pre-share ciscoasa(config-ikev1-policy)# encryption 3des ciscoasa(config-ikev1-policy)# hash sha ciscoasa(config-ikev1-policy)# group 2 ciscoasa(config-ikev1-policy)# lifetime 86400 ciscoasa(config)# crypto ikev1 enable outside

   1 2 3 4 5 6 7 8

   ciscoasa(config)# crypto ikev1 policy 1 ciscoasa(config-ikev1-policy)# authentication pre-share ciscoasa(config-ikev1-policy)# encryption 3des ciscoasa(config-ikev1-policy)# hash sha ciscoasa(config-ikev1-policy)# group 2 ciscoasa(config-ikev1-policy)# lifetime 86400   ciscoasa(config)# crypto ikev1 enable outside

   
   NOTE: The Cisco VPN Client v5 will match the first IKEv1 policy you have for Phase 1. Don’t forget to enable it on the outside interface!

7. IPSec Phase 2: Continuing on in building our Transport tunnel, we now have to create a Crypto Map (in this case Dynamic), and a Transform set.

   
   
   ciscoasa(config)# crypto ipsec ikev1 transfrom-set VPN-TRANSFORM-SET esp-3des esp-sha-hmac ciscoasa(config)# crypto dynamic-map VPN-DynamicCryptoMap 11 set ikev1 transform-set vpnTS ciscoasa(config)# crypto map outside-cmap 65535 ipsec-isakmp dynamic VPN-DynamicCryptoMap ciscoasa(config)# crypto map outside-cmap interface outside

   1 2 3 4 5

   ciscoasa(config)# crypto ipsec ikev1 transfrom-set VPN-TRANSFORM-SET esp-3des esp-sha-hmac ciscoasa(config)# crypto dynamic-map VPN-DynamicCryptoMap 11 set ikev1 transform-set vpnTS ciscoasa(config)# crypto map outside-cmap 65535 ipsec-isakmp dynamic VPN-DynamicCryptoMap ciscoasa(config)# crypto map outside-cmap interface outside

   
   NOTE: dynamic-map is used here because the remote endpoint’s address could be anything. Unlike other IPsec tunnels where we know both endpoint address are predetermined and it is part of the Security Association (SA). Specifying the dynamic-map keyword tells the ASA not to perform peer IP validation after initiating the tunnel. For more info on static tunnels read my other post here.

8. Last Step: Putting it all together with a Tunnel Group object.

   
   
   ciscoasa(config)# tunnel-group VPN-TunnelGroup type remote-access ciscoasa(config)# tunnel-group VPN-TunnelGroup general-attributes ciscoasa(config-tunnel-general)# default-group-policy ClientVPN-GroupPolicy ciscoasa(config)# tunnel-group VPN-TunnelGroup ipsec-attributes ciscoasa(config-tunnel-ipsec)# ikev1 pre-shared-key ****

   1 2 3 4 5 6

   ciscoasa(config)# tunnel-group VPN-TunnelGroup type remote-access ciscoasa(config)# tunnel-group VPN-TunnelGroup general-attributes ciscoasa(config-tunnel-general)# default-group-policy ClientVPN-GroupPolicy   ciscoasa(config)# tunnel-group VPN-TunnelGroup ipsec-attributes ciscoasa(config-tunnel-ipsec)# ikev1 pre-shared-key ****

   
   NOTE: Type remote-access = tells ASA this is a remote-access tunnel and not a Site-to-Site tunnel. We also bind what Group Policy to use with this tunnel here. Don’t forget to set the Phase1 pre-shred-key here!!

9. Creating users within the LOCAL user-table on your Cisco ASA

   
   
   ciscoasa(config)# username testuser password ***** ciscoasa(config)# username testuser attributes ciscoasa(config-username)# vpn-framed-ip-address 172.21.0.55

   1 2 3 4 5

   ciscoasa(config)# username testuser password *****   ciscoasa(config)# username testuser attributes ciscoasa(config-username)# vpn-framed-ip-address 172.21.0.55

Configuring the Client Side

Windows — Using Cisco VPN Client

1. Download software here
2. Install (duh!)
3. Configuration:
   
   
   
4. Wahoo!!

Packet Tracer 6.1 - HSRP Configuration

What is HSRP ?

HSRP (Hot Standby Router Protocol) is a redundancy protocol for setting up a fault-tolerant default gateway in a LAN environment. This is a Cisco proprietary protocol. The standard protocol is VRRP (Virtual Router Redundancy Protocol)
The primary router with the highest configured priority operates as a virtual router with a virtual gateway IP address. It responds to the ARP request from PC or servers connected to the LAN with the MAC address 0000.0c07.acXX where XX is the HSRP group ID (converted to an hexadecimal value). If the primary router should fail, the Cisco router with the next-highest priority available in the LAN segment would take over the gateway IP address and answer ARP requests with the same mac address, thus achieving transparent default gateway fail-over.

 

HSRP in Packet Tracer 6.0

HSRP is a new feature of Packet Tracer 6.0 . This protocol can be configured on every Cisco router available in Packet Tracer as well as on Cisco Catalyst 3560 layer 3 switch.
The following IOS commands are available :

• standby  <0-4095> ip        Enable HSRP and set the virtual IP address
• standby  <0-4095> preempt   Overthrow lower priority Active routers
• standby  <0-4095> priority  Priority level
• standby  <0-4095> timers    Hello and hold timers
• standby  <0-4095> track     Priority Tracking

 

HSRP configuration using Cisco 2911 ISR routers

Two network are configured for this tutorial :

• Network 192.168.1.0/24
  • Router0 : 192.168.1.2 (GigabitEthernet 0/0)
  • Router1 : 192.168.1.3 (GigabitEthernet 0/0)
• Network 192.168.2.0/24
  • Router0 : 192.168.2.2 (GigabitEthernet 0/1)
  • Router1 : 192.168.2.3 (GigabitEthernet 0/1)

Two HSRP groups are configured on the ISR routers :

• HSRP Group 1 :
  • IP address : 192.168.1.1
  • Router0 with priority 120 (preemption enabled)
  • Router1 with HSRP default priority (100)
• HSRP Group 2 :
  • IP address : 192.168.2.1
  • Router0 with priority 120 (preemption enabled)
  • Router1 with HSRP default priority (100)

Routers configuration

Router0 configuration	Router1 configuration
interface GigabitEthernet0/0  ip address 192.168.1.2 255.255.255.0  duplex auto  speed auto  standby version 2  standby 1 ip 192.168.1.1  standby 1 priority 120  standby 1 preempt ! interface GigabitEthernet0/1  ip address 192.168.2.2 255.255.255.0  duplex auto  speed auto  standby version 2  standby 2 ip 192.168.2.1  standby 2 priority 120  standby 2 preempt	interface GigabitEthernet0/0  ip address 192.168.1.3 255.255.255.0  duplex auto  speed auto  standby version 2  standby 1 ip 192.168.1.1 ! interface GigabitEthernet0/1  ip address 192.168.2.3 255.255.255.0  duplex auto  speed auto  standby version 2  standby 2 ip 192.168.2.1

Preemption is configured on Router0 using the standby X preempt commands. This router will always assume HSRP active state when it's online and if it has the highest HSRP priority in the network. The same configuration without the standby x priority 120 configuration on Router0 does not work and Router1 assumes the active state because it has a higher IP address configured.

Testing the configuration

Router0 is active for both HSRP groups. Both routers detected each other correctly but the priority seems to be wrong (Standby router is 192.168.1.3, priority 120 should be Standby router is 192.168.1.3, priority 100 on Router0)



Ping, traceroute and arp commands issued on Laptop0 confirms that the configuration is working. The IP packets are transiting through Router0 (192.168.1.2)

Known bug

HSRP can be configured the same way on Cisco 3750 multilayer switch vlan interfaces in Packet Tracer 6.0.1.

interface Vlan100
 ip address 192.168.1.2 255.255.255.0
 standby version 2
 standby 1 ip 192.168.1.1
 standby 1 preempt
!
interface Vlan200
 ip address 192.168.2.2 255.255.255.0
 standby version 2
 standby 2 ip 192.168.2.1
 standby 2 preempt

Point-to-Point GRE VPN Tunnels - Unprotected GRE & Protected GRE over IPSec Tunnels

Configuring Point-to-Point GRE VPN Tunnels - Unprotected GRE & Protected GRE over IPSec Tunnels

Written by Administrator. Posted in Cisco Routers - Configuring Cisco Routers

4.72727272727 1 1 1 1 1 Rating 4.73 (44 Votes)

inShare

Tweet

Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco that allows the encapsulation of a wide variety of network layer protocols inside point-to-point links.

A GRE tunnel is used when packets need to be sent from one network to another over the Internet or an insecure network. With GRE, a virtual tunnel is created between the two endpoints (Cisco routers) and packets are sent through the GRE tunnel.

It is important to note that packets travelling inside a GRE tunnel are not encrypted as GRE does not encrypt the tunnel but encapsulates it with a GRE header. If data protection is required, IPSec must be configured to provide data confidentiality – this is when a GRE tunnel is transformed into a secure VPN GRE tunnel.

The diagram below shows the encapsulation procedure of a simple - unprotected GRE packet as it traversers the router and enters the tunnel interface:

While many might think a GRE IPSec tunnel between two routers is similar to a site to site IPSec VPN (crypto), it is not. A major difference is that GRE tunnels allow multicast packets to traverse the tunnel whereas IPSec VPN does not support multicast packets. In large networks where routing protocols such as OSPF, EIGRP are necessary, GRE tunnels are your best bet. For this reason, plus the fact that GRE tunnels are much easier to configure, engineers prefer to use GRE rather than IPSec VPN.

This article will explain how to create simple (unprotected) and secure (IPSec encrypted) GRE tunnels between endpoints. We explain all the necessary steps to create and verify the GRE tunnel (unprotected and protected) and configure routing between the two networks.

Creating a Cisco GRE Tunnel

GRE tunnel uses a ‘tunnel’ interface – a logical interface configured on the router with an IP address where packets are encapsulated and decapsulated as they enter or exit the GRE tunnel.

First step is to create our tunnel interface on R1:

R1(config)# interface Tunnel0

R1(config-if)# ip address 172.16.0.1 255.255.255.0

R1(config-if)# ip mtu 1400

R1(config-if)# ip tcp adjust-mss 1360

R1(config-if)# tunnel source 1.1.1.10

R1(config-if)# tunnel destination 2.2.2.10

All Tunnel interfaces of participating routers must always be configured with an IP address that is not used anywhere else in the network. Each Tunnel interface is assigned an IP address within the same network as the other Tunnel interfaces.

In our example, both Tunnel interfaces are part of the 172.16.0.0/24 network.

Since GRE is an encapsulating protocol, we adjust the maximum transfer unit (mtu) to 1400 bytes and maximum segment size (mss) to 1360 bytes. Because most transport MTUs are 1500 bytes and we have an added overhead because of GRE, we must reduce the MTU to account for the extra overhead. A setting of 1400 is a common practice and will ensure unnecessary packet fragmentation is kept to a minimum.

Closing, we define the Tunnel source, which is R1’s public IP address, and destination – R2’s public IP address

As soon as we complete R1’s configuration, the router will confirm the creation of the tunnel and inform about its status:

R1#
*May 4 21:30:22.971: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

Since the Tunnel 0 interface is a logical interface it will remain up even if there is no GRE tunnel configured or connected at the other end.

Next, we must create the Tunnel 0 interface on R2:

R2(config)# interface Tunnel0

R2(config-if)# ip address 172.16.0.2 255.255.255.0

R2(config-if)# ip mtu 1400

R2(config-if)# ip tcp adjust-mss 1360

R2(config-if)# tunnel source 2.2.2.10

R2(config-if)# tunnel destination 1.1.1.10

R2’s Tunnel interface is configured with the appropriate tunnel source and destination IP address. As with R1, R2 router will inform us that the Tunnel0 interface is up:

R2#
*May 4 21:32:54.927: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

 

Routing Networks Through the GRE Tunnel

At this point, both tunnel endpoints are ready and can ‘see’ each other. An icmp echo from one end will confirm this:

R1# ping 172.16.0.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R1#

Again, this result means that the two tunnel endpoints can see each other. Workstations on either network will still not be able to reach the other side unless a static route is placed on each endpoint:

R1(config)# ip route 192.168.2.0 255.255.255.0 172.16.0.2

On R1 we add a static route to the remote network 192.168.2.0/24 via 172.16.0.2 which is the other end of our GRE Tunnel. When R1 receives a packet for 192.168.2.0 network, it now knows the next hop is 172.16.0.2 and therefore will send it through the tunnel.

The same configuration must be repeated for R2:

R2(config)# ip route 192.168.1.0 255.255.255.0 172.16.0.1

Now both networks are able to freely communicate with each over the GRE Tunnel.

Securing the GRE Tunnel with IPSec

As mentioned earlier, GRE is an encapsulation protocol and does not perform any encryption. Creating a point-to-point GRE tunnel without any encryption is extremely risky as sensitive data can easily be extracted from the tunnel and viewed by others.

For this purpose, we use IPSec to add an encryption layer and secure the GRE tunnel. This provides us with the necessary military-grade encryption and peace of mind.  Our example below covers GRE IPSec Tunnel mode.

GRE IPSec modes are covered extensively in our GRE and IPSec – GRE Over IPSec - Selecting and Configuring Gre IPSec Tunnel or Transport Mode.

Configuring IPSec Encryption for GRE Tunnel (GRE over IPSec)

IPSec encryption involves two steps for each router. These steps are:

(1) Configure ISAKMP (ISAKMP Phase 1)

(2) Configure IPSec (ISAKMP Phase 2)

Configure ISAKMP (IKE) - (ISAKMP Phase 1)

IKE exists only to establish SAs (Security Association) for IPsec. Before it can do this, IKE must negotiate an SA (an ISAKMP SA) relationship with the peer.

To begin, we’ll start working on R1.

First step is to configure an ISAKMP Phase 1 policy:

R1(config)# crypto isakmp policy 1

R1(config-isakmp)# encr 3des

R1(config-isakmp)# hash md5

R1(config-isakmp)# authentication pre-share

R1(config-isakmp)# group 2

R1(config-isakmp)# lifetime 86400

The above commands define the following (in listed order):

3DES - The encryption method to be used for Phase 1.

MD5 - The hashing algorithm

Pre-share - Use Pre-shared key as the authentication method

Group 2 - Diffie-Hellman group to be used

86400 – Session key lifetime. Expressed in either kilobytes (after x-amount of traffic, change the key) or seconds. Value set is the default value.

Next we are going to define a pre shared key for authentication with R1's peer, 2.2.2.10:

R1(config)# crypto isakmp key firewallcx address 2.2.2.10

The peer’s pre shared key is set to firewallcx. This key will be used for allISAKMP negotiations with peer 2.2.2.10 (R2).

 

Create IPSec Transform (ISAKMP Phase 2 policy)

Now we need to create the transform set used to protect our data. We’ve named this TS:

R1(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac
R1(cfg-crypto-trans)# mode transport

The above commands defines the following:

- ESP-3DES - Encryption method

- MD5 - Hashing algorithm

- Set IPSec to transport mode

Finally, we create an IPSec profile to connect the previously defined ISAKMP and IPSec configuration together. We’ve named our IPSec profile protect-gre:

R1(config)# crypto ipsec profile protect-gre

R1(ipsec-profile)# set security-association lifetime seconds 86400

R1(ipsec-profile)# set transform-set TS

We are ready to apply the IPSec encryption to the Tunnel interface:

R1(config)# interface Tunnel 0
R1(config-if)# tunnel protection ipsec profile protect-gre

Now it's time to apply the same configuration on R2:

R2(config)# crypto isakmp policy 1

R2(config-isakmp)# encr 3des

R2(config-isakmp)# hash md5

R2(config-isakmp)# authentication pre-share

R2(config-isakmp)# group 2

R2(config-isakmp)# lifetime 86400

 

R2(config)# crypto isakmp key firewallcx address 1.1.1.10

R2(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac

R2(cfg-crypto-trans)# mode transport

R2(config)# crypto ipsec profile protect-gre

R2(ipsec-profile)# set security-association lifetime seconds 86400

R2(ipsec-profile)# set transform-set TS

R2(config)# interface Tunnel 0

R2(config-if)# tunnel protection ipsec profile protect-gre

Verifying the GRE over IPSec Tunnel

Finally, our tunnel has been encrypted with IPSec, providing us with the much needed security layer. To test and verify this, all that is required is to ping the other end and force the VPN IPSec tunnel to come up and start encrypting/decrypting our data:

R1# ping 192.168.2.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

Using the show crypto session command, we can quickly verify the encryption is in place and doing its work:

R1# show crypto session

Crypto session current status

Interface: Tunnel0

Session status: UP-ACTIVE

Peer: 2.2.2.10 port 500

IKE SA: local 1.1.1.10/500 remote 2.2.2.10/500 Active

IPSEC FLOW: permit 47 host 1.1.1.10 host 2.2.2.10

Active SAs: 2, origin: crypto map