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

Written 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 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 R1s public IP address, and destination R2s public IP address As soon as we complete R1s 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 R2s 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, well 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 peers 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. Weve named this TS: R1(config)# crypto ipsec transform-set 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. Weve 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 TS esp-3des esp-md5-hmac

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

Configuring Site to Site IPSec VPN Tunnel Between Cisco Routers

Written 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 siteto-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:

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, well 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 peers 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 list or interesting traffic access-list. VPN traffic are sometimes called crypto access-

R1(config)# ip access-list extended R1(config-ext-nacl)# permit ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255

VPN-TRAFFIC

Create IPSec Transform (ISAKMP Phase 2 policy)

Next step is to create the transform set used to protect our data. Weve 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 Weve 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 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 FastEthernet0/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 1s 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 2s 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, weve 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

Configuring NAT Overload On A Cisco Router

Written 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 Scenario
The 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

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: terminal fastethernet0/0 nat inside serial0/0 outside

R1# configure R1(config)# interface R1(config-if)# ip R1(config-if)# interface R1(config-if)# ip R1(config-if)# exit

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

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]== R1(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any 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 Outside local 74.200.84.4:53 195.170.0.1:53 64.233.189.99:80 69.65.106.48:110 69.65.106.48:110 Outside global 74.200.84.4:53 195.170.0.1:53 64.233.189.99:80 69.65.106.48:110 69.65.106.48:110 translations

Pro Inside global Inside local udp 200.2.2.1:53427 192.168.0.6:53427 udp 200.2.2.1:53427 192.168.0.6:53427 tcp 200.2.2.1:53638 192.168.0.6:53638 tcp 200.2.2.1:57585 tcp 200.2.2.1:57586 192.168.0.7:57585 192.168.0.7:57586

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 Routers
Written 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 weve 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, 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 Siteto-Site IPSec Dynamic IP Endpoint 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 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.

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, well start working on the Headquarter router (R1). First step is to configure an ISAKMP Phase 1 policy: crypto isakmp policy 1 encr 3des hash md5 authentication pre-share group 2 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. 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 Let us examine each of the above steps. map to the public interface

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, well 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

Create IPSec Transform (ISAKMP Phase 2 policy)

Now we need to create the transform set used to protect our data. Weve named our transform set TS: crypto ipsec transform-set TS esp-3des esp-md5-hmac The above command defines the following: - ESP-3DES - Encryption method - MD5 - Hashing algorithm

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 set transform-set TS 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 (VPN1TRAFFIC , 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 crypto encr 3des hash md5 authentication pre-share 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 ipsec transform-set TS esp-3des esp-md5-hmac ! crypto map vpn-to-hq 10 ipsec-isakmp set peer 74.200.90.5 set transform-set TS match ! interface FastEthernet0/1 crypto map vpn-to-hq Remote Site 2 Router crypto isakmp policy 1 encr 3des hash md5 authentication pre-share group 2 lifetime 86400 ! crypto isakmp key firewallcx address 74.200.90.5 ! address VPN-TRAFFIC isakmp policy 1

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 ipsec transform-set TS esp-3des esp-md5-hmac ! crypto map vpn-to-hq 10 ipsec-isakmp set peer 74.200.90.5 set transform-set TS match address VPN-TRAFFIC ! interface FastEthernet0/1 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 100 100 100 100 deny deny source list 100 interface fastethernet0/1 NAT 20.20.20.0 30.30.30.0 0.0.0.255 overload Service]=0.0.0.255 0.0.0.255 any

access-list access-list access-list access-list

remark -=[Define ip 10.10.10.0 0.0.0.255 ip permit 10.10.10.0 ip 0.0.0.255 10.10.10.0

access-list 100 remark

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

ip nat inside source list 100 interface fastethernet0/1 overload ! access-list 100 remark -=[Define NAT Service]=access-list 100 deny ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255 access-list 100 permit ip 20.20.20.0 0.0.0.255 any access-list 100 remark

For Remote Site 2 Router, deny NAT for packets destined to the headquarter network: ip nat inside source list 100 interface fastethernet0/1 overload ! access-list 100 remark -=[Define NAT Service]=access-list 100 deny ip 30.30.30.0 0.0.0.255 10.10.10.0 0.0.0.255 access-list 100 permit ip 30.30.30.0 0.0.0.255 any access-list 100 remark

Bringing Up and Verifying the VPN Tunnel

At this point, weve 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 headquarters 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, lets ping the headquarter router: R2# ping 10.10.10.1 source fastethernet0/1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds: Packet sent with a source address of 73.54.120.100 .!!!! 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.

To verify the VPN Tunnel, use the show crypto session command: R2# show crypto session Crypto session current status Interface: FastEthernet0/1 Session status: UP-ACTIVE Peer: 74.200.90.5 port 500 IKE SA: local 73.54.120.100/500 remote 74.200.90.5 /500 Active IPSEC FLOW: permit ip 20.20.20.0/255.255.255.0 10.10.10.0/255.255.255.0 Active SAs: 2, origin: crypto map

From Remote Site 2, lets ping the headquarter router: R3# ping 10.10.10.1 source fastethernet0/1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds: Packet sent with a source address of 85.100.120.5 .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 47/50/53 ms 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. To verify the VPN Tunnel, use the show crypto session command: R3# show crypto session Crypto session current status Interface: FastEthernet0/1 Session status: UP-ACTIVE Peer: 74.200.90.5 port 500 IKE SA: local 85.100.120.5/500 remote 74.200.90.5 /500 Active IPSEC FLOW: permit ip 30.30.30.0/255.255.255.0 10.10.10.0/255.255.255.0 Active SAs: 2, origin: crypto map 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 Client to Layer-4 (TCP, UDP) Services Applying IP, TCP & UDP Access Lists
Written 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), youd 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.

Lets 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 aaa aaa aaa aaa ! crypto isakmp policy 1 encr 3des authentication pre-share group 2 ! crypto isakmp policy 2 encr 3des hash md5 authentication pre-share group 2 ! crypto key pool acl 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 isakmp client configuration group CCLIENT-VPN firewall.cx VPN-Pool 120 authentication authentication authorization login login network session-id default vpn_xauth_ml_1 vpn_group_ml_1 new-model local local local common

! 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-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 todays complex and demanding VPN networks. Access Lists]==

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 110 remark ! 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 access-list 121 remark 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 VirtualTemplate3 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 VirtualTemplate3 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-profile2 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.