Post on 24-Oct-2015
description
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
whereas IPSec VPN does not support multicast packets. In large networks where routing protocols such
as OSPF, EIGRP are necessary, GRE tunnels are your best bet. For this reason, plus the fact that GRE
tunnels are much easier to configure, engineers prefer to use GRE rather than IPSec VPN.
This article will explain how to create simple (unprotected) and secure (IPSec encrypted) GRE tunnels
between endpoints. We explain all the necessary steps to create and verify the GRE tunnel
(unprotected and protected) and configure routing between the two networks.
Creating a Cisco GRE Tunnel
GRE tunnel uses a ‘tunnel’ interface – a logical interface configured on the router with an IP address
where packets are encapsulated and decapsulated as they enter or exit the GRE tunnel.
First step is to create our tunnel interface on R1:
R1(config)# interface Tunnel0
R1(config-if)# ip address 172.16.0.1 255.255.255.0
R1(config-if)# ip mtu 1400
R1(config-if)# ip tcp adjust-mss 1360
R1(config-if)# tunnel source 1.1.1.10
R1(config-if)# tunnel destination 2.2.2.10
All Tunnel interfaces of participating routers must always be configured with an IP address that is not
used anywhere else in the network. Each Tunnel interface is assigned an IP address within the same
network as the other Tunnel interfaces.
In our example, both Tunnel interfaces are part of the 172.16.0.0/24 network.
Since GRE is an encapsulating protocol, we adjust the maximum transfer unit (mtu) to 1400 bytes
and maximum segment size (mss) to 1360 bytes. Because most transport MTUs are 1500 bytes and we
have an added overhead because of GRE, we must reduce the MTU to account for the extra overhead.
A setting of 1400 is a common practice and will ensure unnecessary packet fragmentation is kept to a
minimum.
Closing, we define the Tunnel source, which is R1’s public IP address, and destination – R2’s public IP
address
As soon as we complete R1’s configuration, the router will confirm the creation of the tunnel and inform
about its status:
R1#
*May 4 21:30:22.971: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state
to up
Since the Tunnel 0 interface is a logical interface it will remain up even if there is no GRE tunnel
configured or connected at the other end.
Next, we must create the Tunnel 0 interface on R2:
R2(config)# interface Tunnel0
R2(config-if)# ip address 172.16.0.2 255.255.255.0
R2(config-if)# ip mtu 1400
R2(config-if)# ip tcp adjust-mss 1360
R2(config-if)# tunnel source 2.2.2.10
R2(config-if)# tunnel destination 1.1.1.10
R2’s Tunnel interface is configured with the appropriate tunnel source and destination IP address. As
with R1, R2 router will inform us that the Tunnel0 interface is up:
R2#
*May 4 21:32:54.927: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state
to up
Routing Networks Through the GRE Tunnel
At this point, both tunnel endpoints are ready and can ‘see’ each other. An icmp echo from one end will
confirm this:
R1# ping 172.16.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R1#
Again, this result means that the two tunnel endpoints can see each other. Workstations on either
network will still not be able to reach the other side unless a static route is placed on each endpoint:
R1(config)# ip route 192.168.2.0 255.255.255.0 172.16.0.2
On R1 we add a static route to the remote network 192.168.2.0/24 via 172.16.0.2 which is the other
end of our GRE Tunnel. When R1 receives a packet for 192.168.2.0 network, it now knows the next hop
is 172.16.0.2 and therefore will send it through the tunnel.
The same configuration must be repeated for R2:
R2(config)# ip route 192.168.1.0 255.255.255.0 172.16.0.1
Now both networks are able to freely communicate with each over the GRE Tunnel.
Securing the GRE Tunnel with IPSec
As mentioned earlier, GRE is an encapsulation protocol and does not perform any encryption. Creating
a point-to-point GRE tunnel without any encryption is extremely risky as sensitive data can easily be
extracted from the tunnel and viewed by others.
For this purpose, we use IPSec to add an encryption layer and secure the GRE tunnel. This provides us
with the necessary military-grade encryption and peace of mind. Our example below covers GRE IPSec
Tunnel mode.
GRE IPSec modes are covered extensively in our GRE and IPSec – GRE Over IPSec - Selecting and
Configuring Gre IPSec Tunnel or Transport Mode.
Configuring IPSec Encryption for GRE Tunnel (GRE over IPSec)
IPSec encryption involves two steps for each router. These steps are:
(1) Configure ISAKMP (ISAKMP Phase 1)
(2) Configure IPSec (ISAKMP Phase 2)
Configure ISAKMP (IKE) - (ISAKMP Phase 1)
IKE exists only to establish SAs (Security Association) for IPsec. Before it can do this, IKE must negotiate
an SA (an ISAKMP SA) relationship with the peer.
To begin, we’ll start working on R1.
First step is to configure an ISAKMP Phase 1 policy:
R1(config)# crypto isakmp policy 1
R1(config-isakmp)# encr 3des
R1(config-isakmp)# hash md5
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 2
R1(config-isakmp)# lifetime 86400
The above commands define the following (in listed order):
3DES - The encryption method to be used for Phase 1.
MD5 - The hashing algorithm
Pre-share - Use Pre-shared key as the authentication method
Group 2 - Diffie-Hellman group to be used
86400 – Session key lifetime. Expressed in either kilobytes (after x-amount of traffic, change the key)
or seconds. Value set is the default value.
Next we are going to define a pre shared key for authentication with R1's peer, 2.2.2.10:
R1(config)# crypto isakmp key firewallcx address 2.2.2.10
The peer’s pre shared key is set to firewallcx. This key will be used for allISAKMP negotiations with
peer 2.2.2.10 (R2).
Create IPSec Transform (ISAKMP Phase 2 policy)
Now we need to create the transform set used to protect our data. We’ve named this TS:
R1(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac
R1(cfg-crypto-trans)# mode transport
The above commands defines the following:
- ESP-3DES - Encryption method
- MD5 - Hashing algorithm
- Set IPSec to transport mode
Finally, we create an IPSec profile to connect the previously defined ISAKMP and IPSec configuration
together. We’ve named our IPSec profile protect-gre:
R1(config)# crypto ipsec profile protect-gre
R1(ipsec-profile)# set security-association lifetime seconds 86400
R1(ipsec-profile)# set transform-set TS
We are ready to apply the IPSec encryption to the Tunnel interface:
R1(config)# interface Tunnel 0
R1(config-if)# tunnel protection ipsec profile protect-gre
Now it's time to apply the same configuration on R2:
R2(config)# crypto isakmp policy 1
R2(config-isakmp)# encr 3des
R2(config-isakmp)# hash md5
R2(config-isakmp)# authentication pre-share
R2(config-isakmp)# group 2
R2(config-isakmp)# lifetime 86400
R2(config)# crypto isakmp key firewallcx address 1.1.1.10
R2(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac
R2(cfg-crypto-trans)# mode transport
R2(config)# crypto ipsec profile protect-gre
R2(ipsec-profile)# set security-association lifetime seconds 86400
R2(ipsec-profile)# set transform-set TS
R2(config)# interface Tunnel 0
R2(config-if)# tunnel protection ipsec profile protect-gre
Verifying the GRE over IPSec Tunnel
Finally, our tunnel has been encrypted with IPSec, providing us with the much needed security layer. To
test and verify this, all that is required is to ping the other end and force the VPN IPSec tunnel to come
up and start encrypting/decrypting our data:
R1# ping 192.168.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
Using the show crypto session command, we can quickly verify the encryption is in place and doing
its work:
R1# show crypto session
Crypto session current status
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 2.2.2.10 port 500
IKE SA: local 1.1.1.10/500 remote 2.2.2.10/500 Active
IPSEC FLOW: permit 47 host 1.1.1.10 host 2.2.2.10
Active SAs: 2, origin: crypto map
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:
(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, 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
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
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]==
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 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,
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:
(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, we’ll 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 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
Create IPSec Transform (ISAKMP Phase 2 policy)
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:
- 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 (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
crypto isakmp policy 1
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 address VPN-TRAFFIC
!
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
!
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 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 deny ip 10.10.10.0 0.0.0.255 30.30.30.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:
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, 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:
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, let’s 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 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
!
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 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 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 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.