Topology

Objectives

Our main objective is to create the following LAB in GNS3 1.4 to illustrate and demonstrate for easy study guide for network engineers

  • ·         Configure NAT
  • ·         Configure an IPsec VPN
  • ·         Configure a GRE tunnel over IPsec
  • ·         Enable dynamic routing over a GRE tunnel
  • ·         Verify the configuration an operation using show and debug commands

Background

Your organization is expanding its operation and wants to connect a branch site. To avoid expensive WAN cost, the decision was made to use internet as the WAN Link. You suggest using a test network to implement an IPSEC VPN to support all traffic going between corporate sites. In addition, you want to configure dynamic routing between sites, by implementing GRE.

Note: The intent of this lab is to illustrate the impact on routing services and addressing schemes when deploying IPsec VPN’s at the Branch office routers. The content was derived from the CCNP Routing LAB guide created to assist Network Engineers studying toward CCNP Routing Certification.

Source material form Cisco Networking Academy

ISBN-13: 978-1-58713-303-9

ISBN-10: 1-58713-303-2

Required Resources

  • GNS3 1.4 rel
  •  3 routers (Cisco IOS Software, 3600 Software (C3640-JK9S-M), Version 12.4(16), RELEASE SOFTWARE (fc1)

Step 1: Prepare the routers and configure the router hostname and interface addresses.

Branch (R1)

!

hostname Branch

!

interface Loopback1

description Branch LAN

ip address 192.168.1.1 255.255.255.0

!

interface Serial0/0/1

description Connection to ISP

ip address 209.165.200.242 255.255.255.248

bandwidth 64

no shut

!

end

HQ (R2)

!

hostname HQ

!

interface Loopback1

description Headquarters LAN

ip address 10.10.10.1 255.255.255.0

!

interface Serial0/0/1

description Connection to ISP

ip address 209.165.200.226 255.255.255.248

clock rate 64000

bandwidth 64

no shut

!

End

ISP (R3)

!

hostname ISP

!

interface Loopback1

description Simulating the Internet

ip address 209.165.202.129 255.255.255.240

!

interface Serial0/0/0

description Connection to Branch

ip address 209.165.200.241 255.255.255.248

clock rate 64000

bandwidth 64

no shut

!

interface Serial0/0/1

description Connection to HQ

ip address 209.165.200.225 255.255.255.248

bandwidth 64

no shut

ip route 209.165.200.232 255.255.255.248 Serial0/0/1

ip route 209.165.200.248 255.255.255.248 Serial0/0/0

!

End

!

(b) Verify your configuration by using the show ip interface brief command.

(c) From the Branch LAN interface, use an extended ping to verify connectivity to the directly connected interface of the ISP, the ISPs loopback interface, and the HQ Internet interface. Run the following Tcl script on the Branch router to verify connectivity.

 

Step 2: Configure NAT on the Branch and HQ routers.

The internal LAN private IP addresses will be translated to global public IP addresses using NAT. The ISP has provided the HQ and Branch sites with the following pools of public addresses:

·         HQ: 209.165.200.233 – 209.165.200.238 (209.165.200.232/29)

·         Branch: 209.165.200.249 – 209.165.200.254 (209.165.200.248/29)

(a)   The NAT pool identifies public IP addresses, while the NAT ACL identifies which inside hosts can use these public IP addresses. For the Branch router, this means that    the NAT ACL must identify the 192.168.1.0 LAN, and the NAT pool must identify addresses 209.165.200.248 /29. The LAN interface must be identified as an inside NAT interface, and the Internet interface must be identified as an outside NAT interface.

 

(b) On the HQ router, the NAT ACL must identify the 10.10.10.0 and the 10.10.20.0 LANs. The NAT pool must identify addresses 209.165.200.232 /29. The LAN interface must be identified as an inside NAT interface, and the Internet interface must be identified as an outside NAT interface.

The email server with private IP address 10.10.20.238 will be statically assigned the last public IP address from the NAT pool, 209.165.200.238. Interface loopback 0 on HQ simulates this server.

(c). Verify the NAT configuration by using the show ip nat statistics and show ip nat translations commands.

 

(d) Initiate NAT traffic by pinging from the Branch LAN to the ISP interface, ISP’s loopback, the HQ Internet interface, and this time also include the HQ public email server      address. Run the following Tcl script on the Branch router to verify connectivity.

All pings should be successful.

(e) Verify that NAT is occurring by using the show ip nat statistics and show ip nat translations commands.

Branch# show ip nat translations

(f) Now clear the NAT translations, verify connectivity from the Branch LAN to the HQ LAN interface and then display the NAT translations.

As expected, Branch LAN traffic going to the HQ LAN is not translated by NAT. The ISP cannot route the pings to the private address on HQ and, therefore, the pings fail.

NAT works as expected. Traffic source from the Branch LAN going to Internet destinations is translated while traffic sourced from the Branch LAN to the HQ LAN is not translated. However, this traffic should be protected

Step 3: Implement an IPsec VPN between the Branch and HQ sites.

An IPsec VPN can secure and protect all unicast IP traffic within it. IPsec cannot forward multicast or broadcast traffic, which means it cannot support interior gateway protocols such as EIGRP and OSPF.

For this lab, assume that the network security team has provided a basic IPsec VPN configuration with which to test your network design. As shown in the following figure, it consists of several configuration components:

·         The ISAKMP policy identifies the specifics for the initial key and secure parameters exchange.

·         The IPsec details define how the IP packet is encapsulated.

·         The VPN tunnel information is identified in a named crypto map which combines the ISAKMP policies, IPsec packet detail, the peer address, and the crypto ACL.

·         The crypto ACL identifies traffic that will trigger the tunnel to activate. This component must sometimes be tuned when implemented along with other services such as NAT and GRE.

·         The crypto map is then applied to the tunnel interface.

(a)   Use the show crypto session detail command on the Branch router to verify the overall configuration of the IPsec VPN.

 The VPN tunnel did become active as indicated by the UP-ACTIVE session status. Also notice that it was the permit statement is referring to the private addresses defined in the crypto ACL and that it encrypted and decrypted four packets, with only one packet dropped due to the IPsec negotiation.

(b)    Before proceeding, manually disable the IPsec VPN tunnel using the clear crypto isakmp and clear crypto sa commands on the Branch router. 

      

      You now have encrypted connectivity from the Branch LAN to HQ LAN. the problem with an IPsec VPN is that it does not allow dynamic routing protocols to operate over it. However, GRE can help solve this problem.

Step 4: Implement GRE over IPsec.

A GRE tunnel over IPsec can be implemented between the Branch and HQ sites. The tunnel will protect all corporate LAN traffic. As a bonus, GRE can forward multicast

and broadcast traffic, so dynamic routing can also be enabled.

(a)   Configure the tunnel interfaces on the Branch router and HQ routers with GRE encapsulation. Copy and paste the following configurations on the routers.

 

(b)   Verify that the tunnel interface is up and running using the show interface tunnel 0 command.

 

(c)   Verify connectivity across the tunnel by pinging the tunnel destination on the HQ router. The pings should be successful 

(d)   The pings successfully reach the other side of the tunnel. But is the traffic being encrypted? Display the IPsec VPN specifics.

      

(h)   Ping from LAN to LAN.