Cisci - VPN Configuring Point

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

Friday, 04 May 2012 21:10

inShare

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

http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/868-cisco-router-gre-ipsec.html?tmpl=component&print=1&page=

http://www.firewall.cx/component/mailto/?tmpl=component&link=b2794afc4002b9fd04379ac20ff7ab6e5fa4de20

http://www.addthis.com/bookmark.php

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(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



!!!!!


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

Configuring Site to Site IPSec VPN Tunnel Between Cisco RoutersWritten by Administrator

Sunday, 29 April 2012 02:43

inShare

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:

http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/867-cisco-router-site-to-site-ipsec-vpn.html?tmpl=component&print=1&page=

http://www.firewall.cx/component/mailto/?tmpl=component&link=832cb6ff96c38d99f2dc6c8c46767da85bc5b084



(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:

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.




To begin, we’ll start working on the Site 1 router (R1).















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:


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


Next step is to create the transform set used to protect our data. We’ve named this TS:


The above command defines the following:



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)# 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 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 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



Packet sent with a source address of 10.10.10.1

.!!!!


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:



Interface: FastEthernet0/1


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

Configuring NAT Overload On A Cisco RouterWritten by Administrator

Thursday, 07 July 2011 22:40

inShare

Introduction

NAT (Network Address Translation) is a method that allows the translation (modification) of IP

addresses while packets/datagrams are traversing the network. NAT Overload, also known as PAT (Port

Address Translation) is essentially NAT with the added feature of TCP/UDP ports translation.

The main purpose of NAT is to hide the IP address (usually private) of a client in order to reserve the

public address space. For example a complete network with 100 hosts can have 100 private IP

addresses and still be visible to the outside world (internet) as a single IP address. Other benefits of

NAT include security and economical usage of the IP address ranges at hand.

The following steps explain basic Cisco router NAT Overload configuration. NAT overload is the most

common operation in most businesses around the world, as it enables the whole network to access the

Internet using one single real IP address. If you would like to know more about the NAT theory, be sure

to read our popular NAT articles, which explain in great depth the NAT functions and applications in

today's networks.

Example ScenarioThe diagram below represents our example network which consists of a number of internal clients and

a router connected to our ISP via its serial interface. The company has been assigned the following

Class C subnet: 200.2.2.0/30 (255.255.255.252).

This translates to one usable real IP address - 200.2.2.1 - configured on our router's serial interface. IP

address 200.2.2.2 will be used on the other end, that is, the ISP's router. Our ISP has also provided us

with the necessary default gateway IP address (configured on our router - not shown) in order to route

all traffic to the Internet.

Our goal in this example is to configure NAT Overload (PAT) and provide all internal workstations with

Internet access using one public IP address (200.2.2.1).

Configure NAT Overload - PAT (Port Address Translation)

'Overloading' means that the single public IP assigned to your router can be used by multiple internal

hosts concurrently. This is done by translating source UDP/TCP ports in the packets and keeping track

of them within the translation table kept in the router (R1 in our case). This is a typical NAT

http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/260-cisco-router-nat-overload.html?tmpl=component&print=1&page=

http://www.firewall.cx/component/mailto/?tmpl=component&link=5da2cfb3bd9a1355e272847048b41497b77a9c04


configuration for almost all of today's networks.

In addition, NAT Overload (PAT) is covered in great depth on Firewall.cx, please click here to read more.

The first step in any NAT configuration is to define the inside and outside interfaces. It is imperative

that we define the these interfaces for NAT overload to function.

Set the fast ethernet 0/0 interface as the inside interface:

R1# configure terminal

R1(config)# interface fastethernet0/0

R1(config-if)# ip nat inside

Next step is to set the serial interface S0/0 as the outside interface:

R1(config-if)# interface serial0/0

R1(config-if)# ip nat outside

R1(config-if)# exit

We now need to create an Access Control List (ACL) that will include local (private) hosts or network(s).

This ACL will later on be applied to the NAT service command, effectively controlling the hosts that will

be able to access the Internet. You can use standard or extended access lists depending on your

requirements:

R1(config)# access-list 100 remark == [Control NAT Service]==


The above command instructs the router to allow the 192.168.0.0/24 network to reach any destination.

Note that Cisco router standard and extended ACLs always use wildcards (0.0.0.255).

All that's left now is to enable NAT overload and bind it to the outside interface previously selected:

R1(config)# ip nat inside source list 100 interface serial 0/0 overload

From this point onward, the router will happily create all the necessary translations to allow the

192.168.0.0/24 network access to the Internet.

Verifying NAT Overload operation

Viewing the NAT translation table can sometimes reveal a lot of important information on your

network's activity. Here you'll be able to identify traffic that's not supposed to be routed to the Internet

or traffic that seems suspicious.

As packets start traversing the router it will gradually build up its NAT/PAT translation table as shown

below:

R1# show ip nat translations

Pro Inside global Inside local Outside local Outside global

udp 200.2.2.1:53427 192.168.0.6:53427 74.200.84.4:53 74.200.84.4:53

udp 200.2.2.1:53427 192.168.0.6:53427 195.170.0.1:53 195.170.0.1:53

tcp 200.2.2.1:53638 192.168.0.6:53638 64.233.189.99:80 64.233.189.99:80

tcp 200.2.2.1:57585 192.168.0.7:57585 69.65.106.48:110 69.65.106.48:110

tcp 200.2.2.1:57586 192.168.0.7:57586 69.65.106.48:110 69.65.106.48:110

As shown, the first 2 translations directed to 74.200.84.4 & 195.170.0.1 are DNS requests from

internal host 192.168.0.6. The third entry seems to be an http request to a web server with IP

address 64.233.189.99.

Looking at the fourth and fifth translation entry, you should identify them as pop3 requests to an

external server, possibly generated by an email client.

Because these entries are all dynamically created, they are temporary and will be removed from the

translation table after some time.

Another point you might want to keep in mind is that when we use programs that create a lot of

connections e.g Utorrent, Limewire, etc., you might see sluggish performance from the router as it tries

to keep up with all connections. Having thousands of connections running through the router can put

some serious stress on the CPU.

In these cases, we might need to clear the IP NAT table completely to free up resources.

This is easily done using the following command:

R1# clear ip nat translation *

Assuming no request has been sent right after the command was entered, the NAT translation table

should be empty:

R1# show ip nat translations

Pro Inside global ...........Inside local .....Outside local .......Outside global

Lastly, you can obtain statistics on the overload NAT service. This will show you the amount of current

translations tracked by our NAT table, plus a lot more:

R1# show ip nat statistics

Total active translations: 200 (0 static, 200 dynamic; 200 extended)

Outside interfaces:

Serial 0/0

Inside interfaces:

FastEthernet0/0

Hits: 163134904 Misses: 0

CEF Translated packets: 161396861, CEF Punted packets: 3465356

Expired translations: 2453616

Dynamic mappings:

-- Inside Source

[Id: 2] access-list 100 interface serial 0/0 refcount 195

Appl doors: 0

Normal doors: 0

Queued Packets: 0

Configuring Cisco Site to Site IPSec VPN with Dynamic IP Endpoint Cisco RoutersWritten by Administrator

Monday, 21 January 2013 02:07

inShare

This article serves as an extension to our popular Cisco VPN topics covered here on Firewall.cx. While

we’ve covered Site to Site IPSec VPN Tunnel Between Cisco Routers (using static public IP addresses),

we will now take a look on how to configure our headquarter Cisco router to support remote Cisco

routers with dynamic IP addresses. One important note to keep in mind when it comes to this

implementation, is that Site-to-Site VPN networks with Dynamic remote Public IP addresses

can only be brought up by the remote site routers as only they are aware of the

headquarter's router Public IP address.

IPSec VPN tunnels can also be configured using GRE (Generic Routing Encapsulation) Tunnels with IPsec

encryption. 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 outstanding flexibility and almost no administration overhead can also be examined by

reading our Understanding Cisco Dynamic Multipoint VPN (DMVPN), Dynamic Multipoint VPN (DMVPN)

Deployment Models & Architecturesand Configuring Cisco Dynamic Multipoint VPN (DMVPN) - Hub,

http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/936-cisco-router-vpn-dynamic-endpoint.html?tmpl=component&print=1&page=

http://www.firewall.cx/component/mailto/?tmpl=component&link=bdcfff824fb0c3b93bdadb63b10c8b6fddafce86


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 required steps to get the Site-to-

Site IPSec Dynamic IP Endpoint VPN Tunnel to work.

These steps are:


(2) Configure IPSec (ISAKMP Phase 2, ACLs, Crypto MAP)

Our example setup consists of the headquarter router R1 which is assigned a static public IP

address, and two remote routers, R2 &R3. Both remote routers (R2 & R3) connect to the Internet and

have a dynamic public IP address assigned by the ISP, as shown in the diagram below:

Our Headquarters is assigned an internal network of 10.10.10.0/24, while Remote Site 1 has been

assigned network20.20.20.0/24. and Remote Site 2 network 30.30.30.0/24. The goal is to securely

connect both remote sites with our headquarters and allow full communication, without any

restrictions.




To begin, we’ll start working on the Headquarter router (R1).


crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

group 2

lifetime 86400








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. Since we only have one ISAKMP policy, this will be

used for all remote VPN routers.

Next we are going to define a pre-shared key for authentication with our peers (R2 & R3 routers) by

using the following command:

crypto isakmp key firewallcx address 0.0.0.0 0.0.0.0

The peers pre-shared key is set to firewallcx and note that we are defining a remote public IP address

of 0.0.0.0 0.0.0.0. This tells our headquarter router that the remote routers have dynamic public IP

addresses and ensures it will try to negotiate and establish a VPN tunnel with any router that requests

it.

Configure IPSec

To configure IPSec we need to setup the following in order:

- Create extended ACL

- Create IPSec Transform

- Create Dynamic Crypto Maps

- 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 each

VPN tunnel. In this example, for the first VPN tunnel it would be traffic from headquarters

(10.10.10.0/24) to remote site 1 (20.20.20.0/24) and for the second VPN tunnel it will be from our

headquarters (10.10.10.0/24) to remote site 2 (30.30.30.0/24). Access-lists that define VPN traffic are

sometimes called crypto access-list or interesting traffic access-list.

Because we are dealing with two separate VPN tunnels, we’ll need to create one set of access-lists for

each:

ip access-list extended VPN1-TRAFFIC

permit ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255

!

ip access-list extended VPN2-TRAFFIC

permit ip 10.10.10.0 0.0.0.255 30.30.30.0 0.0.0.255


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

crypto ipsec transform-set TS esp-3des esp-md5-hmac

The above command defines the following:



Create Dynamic Crypto Maps

The Crypto Map is the last step of our setup and connects the previously defined ISAKMP and IPSec

configuration together. We will need one dynamic crypto map for each remote endpoint, which means

a total of two crypto maps for our setup.

First we create a crypto map named VPN which will be applied to the public interface of our

headquarter router, and connect it with the dynamic crypto maps we named as hq-vpn.

crypto map VPN 1 ipsec-isakmp dynamic hq-vpn

The ipsec-isakmp tag tells the router that this crypto map is an IPsec crypto map. Now we create our

two dynamic crypto maps using the following configuration commands:

crypto dynamic-map hq-vpn 10

set security-association lifetime seconds 86400

set transform-set TS

match address VPN1-TRAFFIC

!

crypto dynamic-map hq-vpn 11

set security-association lifetime seconds 86400


match address VPN2-TRAFFIC

Notice how we create one dynamic map for each remote network. The configuration is similar for each

dynamic crypto map, with only the instance number (10 , 11) and match address (VPN1-

TRAFFIC , VPN2-TRAFFIC) changing.

Adding additional remote sites in the future is as easy as simply adding more dynamic crypto maps,

incrementing the index number and specifying the match address extended access-lists for each

remote network.

Apply Crypto Map to the Public Interface

The final step is to apply our crypto map to the public interface of the headquarter router, which is

FastEthernet0/1. In many cases, this might be a serial or ATM (ADSL - Dialer) interface:

interface FastEthernet0/1

crypto map VPN

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 our headquarter router and we can

move to the remote endpoint routers.

Configuring Remote Endpoint Routers (Dynamic Public IP Addresses)

Our remote routers connect to the Internet and are assigned a dynamic IP address which changes

periodically by the ISP. In most part, the configuration is similar to that of the headquarter router, but

with a few minor changes.

In the configuration below, IP address 74.200.90.5 represents the public IP address of our headquarter

router.

Remote Site 1 Router


encr 3des

hash md5


group 2

lifetime 86400

!

crypto isakmp key firewallcx address 74.200.90.5

!

ip access-list extended VPN-TRAFFIC

permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255

!


!

crypto map vpn-to-hq 10 ipsec-isakmp

set peer 74.200.90.5


match address VPN-TRAFFIC

!


crypto map vpn-to-hq

Remote Site 2 Router


encr 3des

hash md5


group 2

lifetime 86400

!

crypto isakmp key firewallcx address 74.200.90.5

!

ip access-list extended VPN-TRAFFIC

permit ip 30.30.30.0 0.0.0.255 10.10.10.0 0.0.0.255

!


!

crypto map vpn-to-hq 10 ipsec-isakmp

set peer 74.200.90.5


match address VPN-TRAFFIC

!


crypto map vpn-to-hq

It is noticeable that the only major difference between the two routers configuration is the extended

access list.

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 networks.

This is easily done by inserting a deny statement at the beginning of the NAT access lists as shown

below:

For the headquarter router, deny NAT for packets destined to the remote VPN networks, but allow

NAT for all other networks (Internet):

ip nat inside source list 100 interface fastethernet0/1 overload

!

access-list 100 remark -=[Define NAT Service]=-

access-list 100 deny ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255


access-list 100 permit ip 10.10.10.0 0.0.0.255 any

access-list 100 remark

For Remote Site 1 Router, deny NAT for packets destined to the headquarter network:


!





For Remote Site 2 Router, deny NAT for packets destined to the headquarter network:


!





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. There is however one caveat that was mentioned in the beginning

of this article:

Site to Site VPN networks with Dynamic remote Public IP addresses can only be brought up by the

remote sites.

The reason for this is simple and logical. Only the remote site routers are aware of the headquarter’s

public IP address (74.200.90.5) because it is static, and therefore only the remote router can initiate

the VPN tunnel.

From Remote Site 1, let’s ping the headquarter router:





.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 42/46/5 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.






Peer: 74.200.90.5 port 500

IKE SA: local 73.54.120.100/500 remote 74.200.90.5 /500 Active



From Remote Site 2, let’s ping the headquarter router:





.!!!!


Again, 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.






Peer: 74.200.90.5 port 500

IKE SA: local 85.100.120.5/500 remote 74.200.90.5 /500 Active



Issuing the show crypto session command at the headquarter router will reveal all remote routers

public IP addresses. This is usually a good shortcut when trying to figure out the public IP address of

your remote routers.

How to Restrict Cisco IOS Router VPN

http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/941-cisco-router-vpn-client-acls.html?tmpl=component&print=1&page=

http://www.firewall.cx/component/mailto/?tmpl=component&link=3313f9e8c7ad1555259a9b6f17f44a78ae7b7cb6

Client to Layer-4 (TCP, UDP) Services - Applying IP, TCP & UDP Access ListsWritten by Administrator

Tuesday, 05 February 2013 01:06

inShare

In our article Cisco VPN Client Configuration - Setup for IOS Router we explained how to setup up a

Cisco IOS router to support Cisco IPSec VPN clients, allowing remote users to securely connect to the

company network and access the available resources.

It is recommended that users with little or no experience on Cisco router VPN client configuration read

our Cisco Router VPN Client Configuration article before proceeding.

Restricting access to your IPSec VPN clients (or Groups) is possible with the use of standard or

extended access lists, which are applied to the crypto isakmp client configuration group section.

The problem many administrators and Cisco engineers are faced with is even though usage

of extended ACLs, defining layer-4 services such as TCP or UDP, is allowed, the router will only apply

up to layer-3 access list information. Layer-4 information in the defined access lists is completely

ignored.

Layer-4 VPN Access Lists Ignored? What Does this Mean?

To put it simply, if there is a need to restrict Cisco IPSec VPN clients to layer 4 services e.g. http access

(TCP port 80) or MSSQL access (TCP port 1433) to an internal server (e.g 192.168.0.6), you’d be

surprised to know that even though the vpn group access lists can be defind to restrict access to these

services, vpn clients will have full access to host 192.168.0.6 when connecting to the VPN!

The Cisco IOS Router will completely ignore any layer 4 information (TCP – UDP) available in the

extended access lists applied to the VPN group.


Let’s take for example the following configuration, designed to restrict our CCLIENT-VPN VPN group to

host 192.168.0.6 and TCP ports 80 & 1433:

!

aaa new-model

aaa authentication login default local

aaa authentication login vpn_xauth_ml_1 local

aaa authorization network vpn_group_ml_1 local

aaa session-id common

!


encr 3des


group 2

!


encr 3des

hash md5


group 2

!

crypto isakmp client configuration group CCLIENT-VPN

key firewall.cx

pool VPN-Pool

acl 120

max-users 5

!

crypto isakmp profile vpn-ike-profile-1

match identity group CCLIENT-VPN

client authentication list vpn_xauth_ml_1

isakmp authorization list vpn_group_ml_1

client configuration address respond

virtual-template 2

!

crypto ipsec transform-set encrypt-method-1 esp-3des esp-sha-hmac

!

crypto ipsec profile VPN-Profile-1

set transform-set encrypt-method-1

!

!

interface Virtual-Template2 type tunnel

ip unnumbered Vlan1

tunnel mode ipsec ipv4

tunnel protection ipsec profile VPN-Profile-1

!

access-list 120 remark ==[VPN Group CCLIENT-VPN Access Lists]==

access-list 120 permit tcp host 192.168.0.6 eq 80 192.168.0.0 0.0.0.255

access-list 120 permit tcp host 192.168.0.6 eq 1433 192.168.0.0 0.0.0.255

When a VPN client belonging to the CCLIENT-VPN group connects, he is expected to have access to

host 192.168.0.6 and the defined (by the ACLs) services - TCP ports 80 & 1433 - right? Wrong!

Access lists under the crypto isakmp client configuration group are not filtering access lists. Their

purpose is not to control Layer-4services, but identify the network routes the remote VPN user(s) will

have access to. This is also called Split-Tunneling.

It is for this reason the IOS router will allow full access to our host 192.168.0.6. TCP/UDP services,

located on Layer-4 of the OSI model, are completely ignored when defined in VPN group access lists.

As a result, this design or limitation (if you like) is a big problem for many network administrators and

engineers as it does not provide the flexibility and granularity required in today’s complex and

demanding VPN networks.

The Solution to Making Extended ACLs Work For Cisco IOS VPN Clients – Restricting VPN Clients to Layer 4 Services

Despite the setback, it is possible to control access to layer 4 TCP/UDP services for your VPN groups.

The solution involves creating different Virtual-Template interfaces to which the ISAKMP profiles,

and therefore VPN groups, are bound. We then create a new set of access lists and apply them to

the Virtual-Template in the inbound direction as shown below:

!

crypto isakmp client configuration group web-sql-group

key $firewall.cx$

pool VPN-Pool

acl 110

max-users 3

!

crypto isakmp profile vpn-ike-profile-2

match identity group web-sql-group

client authentication list vpn_xauth_ml_5

isakmp authorization list vpn_group_ml_1

client configuration address respond

virtual-template 3

!

!

interface Virtual-Template3 type tunnel

ip unnumbered Vlan1

ip access-group 121 in

tunnel mode ipsec ipv4

tunnel protection ipsec profile VPN-Profile-1

!

access-list 110 remark ==[Cisco VPN- WEB Service ]==

access-list 110 permit ip host 192.168.0.6 any


!

access-list 121 remark ==[Virtual Template3 - Restrict Access to 192.168.0.6 - HTTP &

MSSQL]==

access-list 121 permit tcp any host 192.168.0.6 eq www

access-list 121 permit tcp any host 192.168.0.6 eq 1433

access-list 121 deny ip any any


Notice how we still use a set of access-lists (110) for our new group web-sql-group, restricting access

to host 192.168.0.6. These will ensure the VPN group will be able to access the particular host.

Next, we create a new set of access-lists (121) which are placed under the new Virtual-Template3 in

the inbound direction. These are the extended access-lists that do the job.

Keep in mind that these access-lists must always be placed in the inbound direction of the Virtual-

Template3 interface, to ensure they work correctly and block other types of VPN user traffic from

reaching our network or hosts.

Finally, it is equally important to pay attention to the crypto isakmp profile vpn-ike-profile-

2 command, which essentially maps the VPN group with our new Virtual-Template3 interface. If there

is a need to create additional vpn groups with restricted access, all that is required is to configure new

crypto isakmp profiles and Virtual-Templates along with the necessary access lists as shown by this

example.

Documents

Cisci - VPN Configuring Point