Wednesday, November 12, 2014

Install/setup and configure git server with gitolite and gitweb on centos/rhel 6.4

This article will guide you through the installation and configuration steps of Git/Gitolite/GitWeb server on CentOS/RHEL 6.4.
The procedure mentioned in this tutorial is tested on:

OSCentOS 6.4
Apache2.2.15
Git1.7.1
Gitoliteg3 (v3)
GitWeb1.7.1
About 
Git: It is a very popular and efficient open source Version Control System. It tracks content such as files and directories. It stores the file content in BLOBs (binary large objects). The folders are represented as trees. Each tree contains other trees (subfolders) and BLOBs along with a simple text file which consists of the mode, type, name and SHA (Secure Hash Algorithm) of each blob and subtree entry. During repository transfers, even if there are several files with the same content and different names, the GIT software will transfer the BLOB once and then expand it to the different files.
Git Web: It is used for viewing git repositories detail via Web Browser.
Gitolite: It is an access control layer on top of git.
Summary: In this tutorial we will be creating a private git server that is accessible through ssh and http both. Here Gitweb will be used for viewing git repositories detail and User/Group management is done by Gitolite.
I) Prerequisite 
1) Login to Client machine from where we will remotely manage Git repository.
Create “Git Admin” user RSA key and don’t give passphrase password (just press “Enter”),
It will create two files namely “id_rsa” and id_rsa.pub under *$HOME/.ssh* directory.
   $ ssh-keygen -t rsa -C "Git-Admin"
2) Copy the pub key (id_rsa.pub) to the */tmp* directory on our Git Server.
   $ scp ~/.ssh/id_rsa.pub root@ip-address-of-git-server:/tmp/
3) On the Git Server machine, Install the following dependency packages:
   # yum -y install git httpd perl-Time-HiRes
4) Create the “git” user/group.
   # useradd git
   # usermod -u 600 git
   # groupmod -g 600 git
5) Move the pub key of “Git-Admin” user that we have created above from */tmp* and set the appropriate permission.
   # mv /tmp/id_rsa.pub /home/git/Git-Admin.pub
   # chown git:git /home/git/Git-Admin.pub
Note: In gitolite configuration, the name to user “.pub” key (in gitolite.conf) is same as the name of user himself.
II) Gitolite Installation 
1) Login as “git” user and verify it using *whoami* and *$HOME* env. variable.
   # su -l git
   $ whoami
      git
   $ echo $HOME
      /home/git

2) Now clone the gitolite repository from github.
   $ git clone git://github.com/sitaramc/gitolite
   OR
   $ git clone https://github.com/sitaramc/gitolite
3) Create *bin* directory in “/home/git”.
   $ mkdir -p /home/git/bin
4) Installing and Setting up of Gitolite environment.
   $ gitolite/install -ln
   $ gitolite setup -pk Git-Admin.pub
5) Logout from user “git”.
   $ exit
6) Now from the “root” user check the default values for *suexec*.
   # suexec -V
7) Create a directory “bin” under “/var/www” (Web Server Root) as per *suexec* output and set the appropriate permission.
   # install -d -m 0755 -o git -g git /var/www/bin
8) Now create gitolite-suexec-wrapper.sh (bash script) with following content under “/var/www/bin”.
   # vi /var/www/bin/gitolite-suexec-wrapper.sh
 
 #!/bin/bash
 #
 # Suexec wrapper for gitolite-shell
 #
 
 export GIT_PROJECT_ROOT="/home/git/repositories"
 export GITOLITE_HTTP_HOME="/home/git"
 
 exec ${GITOLITE_HTTP_HOME}/gitolite/src/gitolite-shell
9) Set the appropriate permission.
   # chown -R git:git /var/www/bin
   # chmod 750 /var/www/bin/gitolite-suexec-wrapper.sh
   # chmod 755 /var/www/bin
9) Now modify the UMASK value in “/home/git/.gitolite.rc.
   # vi /home/git/.gitolite.rc

     From:
     UMASK => 0077
     To:
     UMASK => 0027
III) Installing GitWeb.
1) Install gitweb package using yum.
   # yum install gitweb -y
Note: By default gitweb is installed at “/var/www/git”.
2) Rename the “git” directory (under /var/www/git) to *gitweb* and change the ownership to “git”.
   # mv /var/www/git /var/www/html/gitweb
   # chown -R git:git /var/www/html/gitweb
3) Modify the value of $projectroot and $projects_list in gitweb conf file (/etc/gitweb.conf) and set the same value in“/var/www/html/gitweb/gitweb.cgifile.
   # vi /etc/gitweb.conf

     our $projectroot = "/home/git/repositories/";
     our $projects_list = "/home/git/projects.list";

   # vi /var/www/html/gitweb/gitweb.cgi
 
    our $projectroot = "/home/git/repositories";
    our $projects_list = "/home/git/projects.list";
4) Now create a dummy folder git and set the appropriate permission.
   # install -d -m 0755 -o apache -g apache /var/www/git
5) Apache Setup.
Add the following parameters at the end of apache configuration file.
   # vi /etc/httpd/conf/httpd.conf

    

        # You can comment out the below 3 lines and put correct value as per your server information
        #  ServerName        gitserver.example.com
        #  ServerAlias       gitserver
        ServerAdmin       youremailid@example.com
        DocumentRoot /var/www/git
    
        Options       None
        AllowOverride none
        Order         allow,deny
        Allow         from all

    

    SuexecUserGroup git git
    ScriptAlias /git/ /var/www/bin/gitolite-suexec-wrapper.sh
    ScriptAlias /gitmob/ /var/www/bin/gitolite-suexec-wrapper.sh

    
        AuthType Basic
        AuthName "Git Access"
        Require valid-user
        AuthUserFile /etc/httpd/conf/git.passwd
    

    
Note: If you have setup DNS and hostname (FQDN) then uncomment the ServerName and ServerAlias directive.
6) Now update the gitweb apache conf file “/etc/httpd/conf.d/git.conf.
   # vi /etc/httpd/conf.d/git.conf 
 
 Alias /gitweb /var/www/html/gitweb

        
   Options +ExecCGI
   AddHandler cgi-script .cgi
   DirectoryIndex gitweb.cgi
 
        
   AuthType Basic
   AuthName "Git Access"
   Require valid-user
   AuthUserFile /etc/httpd/conf/git.passwd
        
7) We will create Apache Basic auth username and password using *htpasswd*.
   # htpasswd -c /etc/httpd/conf/git.passwd admin
   # htpasswd /etc/httpd/conf/git.passwd userxyz1
   # htpasswd /etc/httpd/conf/git.passwd userxyz2
Note: We used first time “-c flag” to create new password file (/etc/httpd/conf/git.passwd).
8) Restart the Apache Web service and enable it to autostart in runlevel (3 & 5) during system startup.
   # service httpd restart
   # chkconfig httpd on
9) Verify the GitWeb is running fine using your favorite browser.
   http://(ip-address OR FQDN) of git-server/gitweb/
10) If you are unable to view this page or testing.git git repo is not showing up, then either IPTables or SELinux is blocking it.
a) So try to disable iptables temporary and check.
   # service iptables stop
b) See my docs to disable SELinux temporary.
11) Verify that you are able to clone the git using http from Client Machine.
   $ mkdir ~/git-repo/
   $ cd ~/git-repo
   $ git clone git@GitServerIP-or-FQDN:testing.git
IV) Manage user and group of Git Server (from remote client Machine).
1) To manage Git user and groups on Git-Server, we need to clone the gitolite-admin repo.
   $ cd ~/git-repo
   $ git config --global user.name "Git-Admin"
   $ git config --global user.email "youremailid@example.com"
   $ git clone git@GitServerIP-or-FQDN:gitolite-admin.git
2) Adding new users and repos (Client Machine).
First, obtain pubkeys for your users. We will start with the example users “sanjay” and “shyam”.
Ask both of them to generate a keypair just as we did in upper most section of this doc., and send you their keys somehow. Save them with their respective names (sanjay.pub and shyam.pub) in /tmp of your workstation.
Now you have your two users, let us assume that your two new repos are “dev” and “prod”. The “dev” repo must be writeable by sanjay, but read-only to shyam. The “prod” repo is the other way around — writeable by shyam, read-only to sanjay.
Now, on your client machine under “gitolite-admin/keydir” copy the pub keys of sanjay and shyam:
   $ cd ~/git-repo/gitolite-admin
   $ cp /tmp/sanjay.pub /tmp/shyam.pub keydir
3) Now we need to update the gitolite conf file (gitolite.conf).
   $ vim conf/gitolite.conf

 repo    gitolite-admin
        RW+     =   sena

 repo    testing
        RW+     =   @all

 repo    dev
        RW      =   sanjay
        R       =   shyam

 repo    prod
        RW      =   shyam
        R       =   sanjay
Note: R is for Read and W is for Write.
4) Now we need to push the changes of “gitolite.conf” to Git Server.
   $ git add keydir conf
   $ git commit -m 'added users sanjay and shyam, repos dev and prod'
       [master 4932ca2] added users sanjay and shyam, repos dev and prod
       3 files changed, 10 insertions(+), 0 deletions(-)
       create mode 100644 keydir/sanjay.pub
       create mode 100644 keydir/shyam.pub

   $ git push origin master
       Counting objects: 11, done.
       Delta compression using up to 2 threads.
       Compressing objects: 100% (6/6), done.
       Writing objects: 100% (7/7), 1.21 KiB, done.
       Total 7 (delta 0), reused 0 (delta 0)
       remote: Initialized empty Git repository in /home/git/repositories/dev.git/
       remote: Initialized empty Git repository in /home/git/repositories/prod.git/
       To git@10.42.80.70:gitolite-admin.git
          7dd3afe..4932ca2  master -> master

V) Creating repository on Git Server
Login in Git Server as root.And then change to git user.
   # su -l git
   $ cd repositories
   $ mkdir test-repo.git
   $ cd test-repo.git
   $ git --bare init
   $ git update-server-info
VI) Usefull Git Command
1) Setting up of Git Environment variable.
   $ git config --global user.email "you@example.com"
   $ git config --global user.name "Your Name"
   $ git config --global core.editor "vim"
   $ git clone gitolite@GitServerIP-or-FQDN:dev.git

2) Adding file1 in Git.
   $ git add file1
   $ git commit -m "Adding file1"
   $ git push origin master

3) Deleting file in Git.
   $ rm file1
   $ git commit -m "Removing file file1"
   $ git push origin master

4) Sync the file to local File System from Git Server if someone deleted file locally.
   $ git reset --hard
   $ git checkout filename

5) Pull the already created git repo from Git Server.

   $ git clone gitolite@GitServerIP-or-FQDN:ops.git
   $ cd ops
   $ git pull

Saturday, October 25, 2014

Installing Group of Packages from DVD or ISO

Using the yum utility, one can install groups of packages.
In this case, the Development Tools is the group of interest, but it can apply to any other group of packages.
The ISO image, whether virtually or physically present on disk, needs to be set up to be accessed as a repository.
  1. Create a mountpoint to which the ISO image will be mounted:
    # mkdir /mnt/iso
  2. Mount the ISO image:
    REMARQUE : In this case /dev/scd0 points to an iLO virtual media device mapped to an ISO image. But it easily could be a physical DVD or other standalone ISO.
    # mount -o loop,ro /dev/scd0 /mnt/iso
  3. Verify the contents of the mount point:
    [root@dl380g7h08u06 yum.repos.d]# ls /mnt/isoCluster         README-mr.html         RELEASE-NOTES-kn.html     RELEASE-NOTES-U6-ja.htmlClusterStorage  README-or.html         RELEASE-NOTES-ko.html     RELEASE-NOTES-U6-kn.html...README-ja.html  RELEASE-NOTES-gu.html  RELEASE-NOTES-U6-fr.html  RPM-GPG-KEY-redhat-releaseREADME-kn.html  RELEASE-NOTES-hi.html  RELEASE-NOTES-U6-gu.html  ServerREADME-ko.html  RELEASE-NOTES-it.html  RELEASE-NOTES-U6-hi.html  TRANS.TBLREADME-ml.html  RELEASE-NOTES-ja.html  RELEASE-NOTES-U6-it.html  VT
  4. Edit the file /etc/yum.repos.d/file.repo to point to the newly mounted ISO and specific Server and/or VT directory on the ISO.
    This file will be read whenever yum is invoked and should have contents similar to the following:
    # cat file.repo[RHEL_5_ISO_Server_Repository]name=RHEL 5 ISO Repositorybaseurl=file:///mnt/iso/Serverenabled=1
  5. Check the repository list using yum repolist and verify the new ISO repository is listed:
    [root@dl380g7h08u06 yum.repos.d]# yum repolistLoaded plugins: rhnplugin, securityRHEL_5_ISO_Server_Repository                    | 1.3 kB     00:00RHEL_5_ISO_Server_Repository/primary            | 905 kB     00:00RHEL_5_ISO_Server_Repository                    3229/3229repo id                               repo name                repo statusRHEL_5_ISO_Server_Repository          RHEL 5 ISO Repository    enabled:  3,229...
  6. Check the available groups in the repository to confirm the desired package group is listed:
    # yum grouplistLoaded plugins: rhnplugin, securitySetting up Group ProcessRHEL_5_ISO_Server_Repository/group               | 1.0 MB     00:00Installed Groups:   Administration Tools   Authoring and Publishing...Available Groups:   Development Tools   DNS Name Server...Done
  7. Finally, use the command yum groupinstall to install the desired package group:
    # yum groupinstall "Development Tools"

Tuesday, October 7, 2014

How to Protect your Server Against the Shellshock Bash Vulnerability

Introduction

On September 24, 2014, a GNU Bash vulnerability, referred to as Shellshock or the "Bash Bug", was disclosed. In short, the vulnerability allows remote attackers to execute arbitrary code given certain conditions, by passing strings of code following environment variable assignments. Because of Bash's ubiquitous status amongst Linux, BSD, and Mac OS X distributions, many computers are vulnerable to Shellshock; all unpatched Bash versions between 1.14 through 4.3 (i.e. all releases until now) are at risk.
The Shellshock vulnerability can be exploited on systems that are running Services or applications that allow unauthorized remote users to assign Bash environment variables. Examples of exploitable systems include the following:
  • Apache HTTP Servers that use CGI scripts (via mod_cgi and mod_cgid) that are written in Bash or launch to Bash subshells
  • Certain DHCP clients
  • OpenSSH servers that use the ForceCommand capability
  • Various network-exposed services that use Bash
A detailed description of the bug can be found at CVE-2014-6271CVE-2014-7169CVE-2014-7186, and CVE-2014-7187.
Because the Shellshock vulnerability is very widespread--even more so than the OpenSSL Heartbleed bug--and particularly easy to exploit, it is highly recommended that affected systems are properly updated to fix or mitigate the vulnerability as soon as possible. We will show you how to test if your machines are vulnerable and, if they are, how to update Bash to remove the vulnerability.

Check System Vulnerability

On each of your systems that run Bash, you may check for Shellshock vulnerability by running the following command at the bash prompt:
env 'VAR=() { :;}; echo Bash is vulnerable!' 'FUNCTION()=() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"
The highlighted echo Bash is vulnerable! portion of the command represents where a remote attacker could inject malicious code; arbitrary code following a function definition within an environment variable assignment. Therefore, if you see the following output, your version of Bash is vulnerable and should be updated:
Bash is vulnerable!
Bash Test
If your output does not include the simulated attacker's payload, i.e. "Bash is vulnerable" is not printed as output, you are protected against at least the first vulnerability (CVE-2014-6271), but you may be vulnerable to the other CVEs that were discovered later. If there are any bash warnings or errors in the output, you should update Bash to its latest version; this process is described in the next section.
If the only thing that is output from the test command is the following, your Bash is safe from Shellshock:
Bash Test

Test Remote Sites

If you simply want to test if websites or specific CGI scripts are vulnerable, use this link:'ShellShock' Bash Vulnerability CVE-2014-6271 Test Tool.
Simply enter the URL of the website or CGI script you want to test in the appropriate form and submit.

Fix Vulnerability: Update Bash

The easiest way to fix the vulnerability is to use your default package manager to update the version of Bash. The following subsections cover updating Bash on various Linux distributions, including Ubuntu, Debian, CentOS, Red Hat, and Fedora.

APT-GET: Ubuntu / Debian

For currently supported versions of Ubuntu or Debian, update Bash to the latest version available via apt-get:
sudo apt-get update && sudo apt-get install --only-upgrade bash
Now check your system vulnerability again by running the command in the previous section (Check System Vulnerability).

End of Life Ubuntu / Debian Releases

If you are running a release of Ubuntu / Debian that is considered end of life status, you will have to upgrade to a supported to use the package manager to update Bash. The following command can be used to upgrade to a new release (it is recommended that you back up your server and important data first, in case you run into any issues):
sudo do-release-upgrade
After the upgrade is complete, ensure that you update Bash.

YUM: CentOS / Red Hat / Fedora

Update Bash to the latest version available via yum:
sudo yum update bash
Now check your system vulnerability again by running the command in the previous section (Check System Vulnerability).

End of Life CentOS / Red Hat / Fedora Releases

If you are running a release of CentOS / Red Hat / Fedora that is considered end of lifestatus, you will have to upgrade to a supported to use the package manager to update Bash. The following command can be used to upgrade to a new release (it is recommended that you back up your server and important data first, in case you run into any issues):
sudo yum update
After the upgrade is complete, ensure that you update Bash.

Conclusion

Be sure to update all of your affected servers to the latest version of Bash! Also, be sure to keep your servers up to date with the latest security updates!

Sunday, June 8, 2014

CONFIGURING SITE TO SITE IPSEC VPN TUNNEL BETWEEN CISCO ROUTERS

Site-to-Site IPSec VPN Tunnels are used to allow the secure transmission of data, voice and video between two sites (e.g offices or branches). The VPN tunnel is created over the Internet public network and encrypted using a number of advanced encryption algorithms to provide confidentiality of the data transmitted between the two sites.
This article will show how to setup and configure two Cisco routers to create a permanent secure site-to-site VPN tunnel over the Internet, using the IP Security (IPSec) protocol. In this article we assume both Cisco routers have a static public IP address.  Readers interested in configuring support for dynamic public IP address endpoint routers can refer to our Configuring Site to Site IPSec VPN with Dynamic IP Endpoint Cisco Routers article.
IPSec VPN tunnels can also be configured using GRE (Generic Routing Encapsulation) Tunnels with IPsec. GRE tunnels greatly simply the configuration and administration of VPN tunnels and are covered in our Configuring Point-to-Point GRE VPN Tunnels article.  Lastly, DMVPNs – a new VPN trend that provide major flexibility and almost no administration overhead can also be examined by reading ourUnderstanding Cisco Dynamic Multipoint VPN (DMVPN),  Dynamic Multipoint VPN (DMVPN) Deployment Models & Architectures andConfiguring Cisco Dynamic Multipoint VPN (DMVPN) - Hub, Spokes , mGRE Protection and Routing - DMVPN Configuration articles.
ISAKMP (Internet Security Association and Key Management Protocol) and IPSec are essential to building and encrypting the VPN tunnel. ISAKMP, also called IKE (Internet Key Exchange), is the negotiation protocol that allows two hosts to agree on how to build an IPsec security association. ISAKMP negotiation consists of two phases: Phase 1 and Phase 2.  
Phase 1 creates the first tunnel, which protects later ISAKMP negotiation messages. Phase 2 creates the tunnel that protects data.  IPSec then comes into play to encrypt the data using encryption algorithms and provides authentication, encryption and anti-replay services.

IPSEC VPN REQUIREMENTS

To help make this an easy-to-follow exercise, we have split it into two steps that are required to get the Site-to-Site IPSec VPN Tunnel to work.
These steps are:
(1)  Configure ISAKMP (ISAKMP Phase 1)
(2)  Configure IPSec  (ISAKMP Phase 2, ACLs, Crypto MAP)
Our example setup is between two branches of a small company, these are Site 1 and Site 2. Both the branch routers connect to the Internet and have a static IP Address assigned by their ISP as shown on the diagram:
 cisco-routers-s2s-ipsec-vpn-1
Site 1 is configured with an internal network of 10.10.10.0/24, while Site 2 is configured with network 20.20.20.0/24. The goal is to securely connect both LAN networks and allow full communication between them, without any restrictions.

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 the Site 1 router (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.
We should note that ISAKMP Phase 1 policy is defined globally. This means that if we have five different remote sites and configured five different ISAKMP Phase 1 policies (one for each remote router), when our router tries to negotiate a VPN tunnel with each site it will send all five policies and use the first match that is accepted by both ends.
Next we are going to define a pre shared key for authentication with our peer (R2 router) by using the following command:
R1(config)# crypto isakmp key firewallcx address 1.1.1.2
The peer’s pre shared key is set to firewallcx and its public IP Address is 1.1.1.2. Every time R1 tries to establish a VPN tunnel with R2 (1.1.1.2), this pre shared key will be used.

 

CONFIGURE IPSEC

To configure IPSec we need to setup the following in order:
Create extended ACL
Create IPSec Transform
Create Crypto Map
Apply crypto map to the public interface
Let us examine each of the above steps.

 

CREATING EXTENDED ACL

Next step is to create an access-list and define the traffic we would like the router to pass through the VPN tunnel.  In this example, it would be traffic from one network to the other, 10.10.10.0/24 to 20.20.20.0/24.  Access-lists that define VPN traffic are sometimes calledcrypto access-list or interesting traffic access-list.
R1(config)# ip access-list extended VPN-TRAFFIC
R1(config-ext-nacl)# permit ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255

 

CREATE IPSEC TRANSFORM (ISAKMP PHASE 2 POLICY)

Next step is 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
The above command defines the following:  
ESP-3DES - Encryption method
MD5 - Hashing algorithm

CREATE CRYPTO MAP

The Crypto map is the last step of our setup and connects the previously defined ISAKMP and IPSec configuration together:
R1(config)# crypto map CMAP 10 ipsec-isakmp
R1(config-crypto-map)# set peer 1.1.1.2
R1(config-crypto-map)# set transform-set TS
R1(config-crypto-map)# match address VPN-TRAFFIC
We’ve named our crypto map CMAP. The ipsec-isakmp tag tells the router that this crypto map is an IPsec crypto map. Although there is only one peer declared in this crypto map (1.1.1.2), it is possible to have multiple peers within a given crypto map.

APPLY CRYPTO MAP TO THE PUBLIC INTERFACE

The final step is to apply the crypto map to the outgoing interface of the router. Here, the outgoing interface is FastEthernet 0/1.
R1(config)# interface FastEthernet0/1
R1(config- if)# crypto map CMAP
Note that you can assign only one crypto map to an interface.
As soon as we apply crypto map on the interface, we receive a message from the router  that confirms isakmp is on: “ISAKMP is ON”.
At this point, we have completed the IPSec VPN configuration on the Site 1 router.
We now move to the Site 2 router to complete the VPN configuration. The settings for Router 2 are identical, with the only difference being the peer IP Addresses and access lists:
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.1
R2(config)# ip access-list extended VPN-TRAFFIC
R2(config-ext-nacl)# permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255
 
R2(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac
R2(config)# crypto map CMAP 10 ipsec-isakmp
R2(config-crypto-map)# set peer 1.1.1.1
R2(config-crypto-map)# set transform-set TS
R2(config-crypto-map)# match address VPN-TRAFFIC
R2(config)# interface FastEthernet0/1
R2(config- if)# crypto map CMAP

 

NETWORK ADDRESS TRANSLATION (NAT) AND IPSEC VPN TUNNELS

Network Address Translation (NAT) is most likely to be configured to provide Internet access to internal hosts. When configuring a Site-to-Site VPN tunnel, it is imperative to instruct the router not to perform NAT (deny NAT) on packets destined to the remote VPN network(s).
This is easily done by inserting a deny statement at the beginning of the NAT access lists as shown below:
For Site 1’s router:
R1(config)# ip nat inside source list 100 interface fastethernet0/1 overload
R1(config)# access-list 100 remark -=[Define NAT Service]=-
R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255
R1(config)# access-list 100 permit ip 10.10.10.0 0.0.0.255 any
R1(config)# access-list 100 remark

And Site 2’s router:
R2(config)# ip nat inside source list 100 interface fastethernet0/1 overload
R2(config)# access-list 100 remark -=[Define NAT Service]=-
R2(config)# access-list 100 deny ip 20.20.20.0 0.0.0.255 10.10.10.0  0.0.0.255
R2(config)# access-list 100 permit ip 20.20.20.0 0.0.0.255 any
R2(config)# access-list 100 remark

 

BRINGING UP AND VERIFYING THE VPN TUNNEL

At this point, we’ve completed our configuration and the VPN Tunnel is ready to be brought up.  To initiate the VPN Tunnel, we need to force one packet to traverse the VPN and this can be achieved by pinging from one router to another:
R1# ping 20.20.20.1 source fastethernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.20.20.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 44/47/48 ms


The first ping received a timeout, but the rest received a reply, as expected. The time required to bring up the VPN Tunnel is sometimes slightly more than 2 seconds, causing the first ping to timeout.
To verify the VPN Tunnel, use the show crypto session command:
R1# show crypto session
Crypto session current status
Interface: FastEthernet0/1
Session status: UP-ACTIVE    
Peer: 1.1.1.2 port 500
  IKE SA: local 1.1.1.1/500 remote 1.1.1.2/500 Active
  IPSEC FLOW: permit ip 10.10.10.0/255.255.255.0 20.20.20.0/255.255.255.0
        Active SAs: 2, origin: crypto map