CCNP Route Lab 7-1 , Configure Routing Facilities to the Branch Office

CCNP Route Lab 7-1 , Configure Routing Facilities to the Branch Office

Topology

Objectives

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

Background
Your organization is expanding its operation and wants to connect a branch site. To avoid expensive WAN costs, the decision was made to use the 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 Generic Routing Encapsulation (GRE).

Note: The intent of this lab is to illustrate the impact on routing services and addressing schemes when deploying IPsec VPNs at branch office routers. Although sample configurations are provided, detailed explanations of Network Address Translation (NAT), IPsec VPNs, and GRE are beyond the scope of this course. For more details on these technologies, see the Cisco Networking Academy CCNA Security course or www.cisco.com.

Note: This lab uses Cisco 1841 routers with Cisco IOS Release 12.4(24)T1 and the Advanced IP Services
image c1841 -advipservicesk9-mz.124-24.T1 .bin. You can use other routers (such as a 2801 or 2811) and
Cisco IOS Software versions if they have comparable capabilities and features. Depending on the router and
Cisco IOS Software version, the commands available and output produced might vary from what is shown in
this lab.

Required Resources

• 3 routers (Cisco 1841 with Cisco IOS Release 12.4(24)T1 Advanced IP Services or comparable)
• Serial and console cables
  

Step 1: Prepare the routers and configure the router hostname and interface addresses.
a. Cable the network as shown in the topology diagram. Erase the startup configuration and reload each router to clear previous configurations. Using the addressing scheme in the diagram, apply the IP addresses to the interfaces on Branch, HQ, and ISP.

You can copy and paste the following configurations into your routers to begin.

Note: Depending on the router model, interfaces might be numbered differently than those listed. You might need to alter the designations accordingly.

Branch (R1)

HQ (R2)

ISP (R3)

b. Verify your configuration by using the show ip interface brief command. The output from the Branch router is shown here as an example.

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.

Why do the pings to the ISPs loopback and HQ router address fail?
The ping fails because the Branch and HQ routers require a default route to ISP.

d. Configure a default static route to ISP on the Branch and HQ routers.

You can copy and paste the following configurations into your routers.

e. From the Branch router, run the following Tcl script on the Branch router to verify connectivity.

Are the pings now successful?
Yes. If not, troubleshoot.

f. Connectivity from the Branch router to external addresses has been established. But could a Branch LAN user successfully reach those external addresses? To verify, initiate pings sourced from the Branch LAN interface to the ISP interface, the ISPs loopback interface, and the HQ Internet interface. Run the following Tcl script on the Branch router to verify connectivity.

Note: You can also specify the router interface designator (for example, S0/0/0, Fa0/0, or Lo1) as the source for the extended ping, as follows:

Why are the pings unsuccessful?
The pings fail because the source 192.168.1.1 IP address is an internal private address, and the ISP is unaware of this address.

The ISP cannot route back to the internal private address of the Branch LAN.

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)

The HQ site also has an email server that must be accessible to mobile users and Branch office users. Therefore, static NAT must also be configured to use a public address to reach the email server.

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.

Note: The NAT ACL must not translate the Branch LAN addresses if they are destined to the corporate HQ LAN. Therefore, the NAT ACL denies the Branch LAN public addresses from being translated when attempting to connect to the HQ LANs. This will be required when the IPsec VPN is configured. You can copy and paste the following configuration into the Branch router.

Branch Router

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.

Note: Again the NAT ACL denies the HQ LAN public addresses from being translated when attempting to connect to the Branch LAN which will be required when the IPsec VPN is configured.You can copy and paste the following configuration into the HQ router.

HQ Router

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

As shown above, the pool has been configured and the interfaces assigned. The output of the show ip nat translations command confirms that there are currently no active NAT translations:

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.

Notice that translations are occurring. The output lists the details of the NAT translations sourced by the 192.168.1.1 Branch LAN IP address, which was translated to public IP address 209.165.200.249.

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 when traversing the public Internet. To solve this problem, an IPsec VPN will be configured next.

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.
  

Note: How to configure an IPsec VPN is beyond the scope of this lab. For more information on cryptography, IPsec VPNs, and GRE, see the Cisco Networking Academy CCNA Security courses or www.cisco.com.

a. Copy and paste the following configurations on the routers.

Branch Router

HQ Router

Notice that the crypto ACLs are referring to the public IP addresses and not the private IP addresses. This is because the crypto map applies to the traffic after the NAT has already taken place. Another alternative approach would be to exempt site-to-site traffic from the NAT translation pool and have the crypto ACLs trigger based on private addresses instead of the public address pool.

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

The VPN tunnel is currently down because the traffic identified in the IPSEC FLOW has not yet been processed.

c. To test the VPN link, use an extended ping from the Branch LAN interface to the HQ LAN interface.

This time 80% of the pings were successful. This is typical because the VPN tunnel requires a few seconds to negotiate the security parameters specified in the crypto map.

d. Now display the VPN tunnel details again.

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.

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

Branch Router

HQ Router

You should notice the state of the tunnel interfaces to change to up on both routers.

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

The tunnel interface is up. Also notice that the encapsulation and tunnel transport protocol is GRE/IP.

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.

The IPsec VPN is down because the tunnel traffic has not been identified in the crypto ACL.

e. To solve this problem, replace the crypto ACL to make GRE traffic interesting on the Branch and HQ routers. Copy and paste the following configurations on the routers.

HQ Router

f. Test the link again. Notice the pings are 80% successful again.

g. Display the IPsec session details.

The IPsec tunnel is now up and active. The “permit 47” identifies GRE traffic as interesting. The value 47 refers to the GRE protocol number.

h. Ping from LAN to LAN.

The pings are unsuccessful. Does the Branch router have an entry to the 10.10.10.0 network?

i. Verify the routing table.

The pings are unsuccessful because there is no specific route to the other LAN. The traffic is finally routed using the default route, which bypasses the GRE tunnel. The Branch router and the HQ router must be configured to share each other’s LAN information.

This could be accomplished using static routes pointing to the GRE tunnel destination IP address. Although this is valid option, GRE tunnels also support multicast and broadcast traffic. Therefore, a dynamic routing protocol should be configured.

j. Configure EIGRP, and advertise the LANs and the tunnel segment on the Branch and HQ routers. Copy and paste the following configurations on the routers.

Branch Router

HQ Router

An EIGRP neighbor adjacency message should appear almost immediately.

k. Verify the routing table.

l. Display the IPsec session detail.

m. Test the LAN-to-LAN connectivity, and display the IPsec session detail.

The pings are successful, but notice that the packet counters have increased by more than five ping packets. The reason is because EIGRP is also exchanging hello packets and therefore increasing the counters.

n. Trace the path that the packets take from the Branch LAN to the email server using the inside private address.

Notice that the packet hops only to the end of the tunnel. It is completely unaware that it actually traversed the public Internet.

o. To prove that you still have Internet access without going through the GRE tunnel, trace the path from the Branch LAN to the email server using the outside static NAT address.

The packet now hops across the ISP router and then to the HQ router. In essence, this proves that Internet-bound traffic will not be encrypted.

Router Interface Summary Table

Router Interface Summary
Router Model	Ethernet Interface #1	Ethernet Interface #2	Serial Interface #1	Serial Interface #2
1700	Fast Ethernet 0 (Fa0)	Fast Ethernet 1 (Fa1)	Serial 0 (S0)	Serial 0/0/1 (S0/0/1)
1800	Fast Ethernet 0/0 (Fa0/0)	Fast Ethernet 0/1 (Fa0/1)	Serial 0/0/0 (S0/0/0)	Serial 0/0/1 (S0/0/1)
2600	Fast Ethernet 0/0 (Fa0/0)	Fast Ethernet 0/1 (Fa0/1)	Serial 0/0 (S0/0)	Serial 0/1 (S0/1)
2800	Fast Ethernet 0/0 (Fa0/0)	Fast Ethernet 0/1 (Fa0/1)	Serial 0/0/0 (S0/0/0)	Serial 0/0/1 (S0/0/1)
Note: To find out how the router is configured, look at the interfaces to identify the type of router and how many interfaces the router has. Rather than list all combinations of configurations for each router class, this table includes identifiers for the possible combinations of Ethernet and serial interfaces in the device. The table does not include any other type of interface, even though a specific router might contain one. For example, for an ISDN BRI interface, the string in parenthesis is the legal abbreviation that can be used in Cisco IOS commands to represent the interface.

Device Configurations (Instructor version)

Router Branch

Router HQ

Router ISP

More Resources

• CCNP Route Lab Manual with Solutions
• CCNP Route FAQ
• CCNP Switch Lab Manual with Solutions
• CCNP Switch FAQ
• CCNP Security VPN FAQ
• CCNP Secure IPS FAQ
• CCNA Exam Answers Cisco Learning Network
• CCNA Frequently Asked Questions
• CCNA Exam Questions with Explanation