CIS 188 CCNP TSHOOT

(Troubleshooting)
Ch. 9 Troubleshooting Security
Implementations
Rick Graziani
Cabrillo College
graziani@cabrillo.edu
Fall 2010

Materials
Book:
Troubleshooting and Maintaining
Cisco IP Networks (TSHOOT)
Foundation Learning Guide:
Foundation learning for the CCNP
TSHOOT 642-832
By Amir Ranjbar
Book
ISBN-10: 1-58705-876-6
ISBN-13: 978-1-58705-876-9
eBook
ISBN-10: 1-58714-170-1
ISBN-13: 978-1-58714-170-6

Troubleshooting Challenges in Secured

Networks

Most security features operate at the Transport Layer and above

But need to first determine whether the problems are related to security
features or caused by underlying Layer 1, 2, or 3 connectivity issues.
A security issue may not be a technical problem but due to security policy
User reports lack of connectivity to a server or an application.

OSPF Authentication
Sometimes a useful diagnostic technique is to temporarily disable the
security feature and see if that fixes the problem.
Caution: You may be creating a situation that is not compliant with the
security policy
Risk of opening the network to an attack.
Example: Two OSPF routers cannot establish an OSPF adjacency and are
using MD5 authentication.
Disable authentication to see if that is the problem? Workaround?

Security Features Review

The implementation of security features can affect router and switch
operation on different planes.
On a network device, there are three fundamental categories of functionality,
also called functional planes.
These planes and their corresponding types of traffic must be secured.

Management Plane:
The management plane represents all the functions and protocols involved
in managing the device.
Includes accessing information about:
Device configuration
Device operation
Device statistics
Securing this plane is vital to the overall security of the device.
If the management plane is compromised, the other planes are also
exposed

Control Plane:
Represents all the functions and protocols that are used between network
devices to control the operation of the network, such as:
Routing protocols
Spanning Tree Protocol (STP)
Other signaling and control protocols
Because the control plane affects the behavior of the data plane, the control
plane protocols need to be secured.
If unauthorized devices are allowed to participate in the control plane
protocols, this opens up possibilities for an attacker to block or divert traffic.

Data Plane:
Represents all the functions involved in forwarding traffic through the device.
Routers and switches can inspect and filter traffic as part of the implementation
of a security policy.
ACLs
Route maps
Note: All management and control plane traffic flow through the data plane as
well.
Consequently, security features on the data plane can be used to secure the
management and control planes too.
Also means failures on the management and control plane may be caused by
the implementation of security features on the data plane.

Review of NAT, IPsec VPN and

GRE

Configuring NAT/PAT for Branch Services

A NAT pool of global IP addresses is available on the branch router.

Also notice that the Branch server has a static NAT global address
(209.165.200.254).
The branch router must be configured to deploy NAT as shown above.
There are three generic steps to configuring NAT.
1. Which traffic will be translated
2. To what address will it be translated
3. Which interfaces are involved in the translation selection
10

Configure the interfaces involved in this

particular NAT translation (outside interface
is ISP facing interface)

Translate addresses coming from the branch

LAN, regardless of destination.

The NAT pool of public IP address is defined

using the ip nat pool command.
The NAT pool is named BRANCH-NATPOOL and identifies a range of valid and
available Internet IP address.

interfaceserial0/0/1
ipnatoutside
interfacefastethernet0/0
ipnatinside
ipaccesslistextendedBRANCHNATACL
permitip192.168.1.00.0.0.255any

ipnatpoolBRANCHNATPOOL209.165.200.249
209.165.200.253prefixlength29
ipnatinsidesourcelistBRANCHNATACLpool
BRANCHNATPOOL
ipnatinsidesourcestatic192.168.1.254
209.165.200.254

ip nat inside source command: From

BRANCH-NAT-ACL to BRANCH-NAT-POOL

Creates a static translation entry in the

router, where the inside local address
192.168.1.254 is always translated to the
global 209.165.200.254 on the outside.

11

 Other than the static translation to the inside web server, there are no
dynamic translations listed in the NAT cache.

12

 Displays the number of active translations, which in this case is one static
and zero dynamic translation.
Lists the interfaces involved in the NAT translations
The specifics of the BRANCH-NAT-POOL in use, including the BRANCHNAT-ACL access list used for the traffic to be translated.
13

telnet

Telnet from inside Branch LAN to HQ router works (well, if we had a

password set on the router)
14

15

IPsec Encapsulation

One of the benefits of IPsec is its capability to tunnel packets using an

additional encapsulation.
Tunneling is the transmission of data through a public network so that
routing nodes in the public network are unaware that the transmission is part
of a private network.
Allows the use of public networks to carry data on behalf of users as though
the users had access to a private network.
This is where the name VPN comes from.
16

 Tunneling: The original packet is encapsulated inside a new IP packet

before it leaves the branch office.

17

 The VPN routers at Branch and HQ are responsible for this encapsulation
and decapsulation tasks (the tunnel).
The IPsec encapsulation process:
Adds an additional IP header to the original packet
Can performs security functions (confidentiality, integrity, authentication)

18

 Host at branch site 192.168.1.10 wants to contact HQ host 10.10.10.10.

The link is secured using a site-to-site IPsec VPN.
The packet leaves the branch router, this traffic will be flagged as being
interesting so
An IPsec VPN (tunnel) is established between the branch and HQ routers.
The two routers negotiate and secure a tunnel that encapsulates the original IP
header into another, secure new IP header.
The packet will then be forwarded to the HQ site.
Packet arrives at the HQ site:
Decrypts the packet with the correct preshared key
Extracting the IP packet
Forwards it to the HQ host

19

 Configuration commands associated with IPsec VPNs are beyond the scope
of this chapter.
We will focus on the commands to verify proper configuration and operation.
The details of cryptographic services such as confidentiality, integrity, and
VPN end-point authentication will be transparent to us.

20

Scenario, so far
?

We are using NAT so our LANs can access the Internet

We have implemented an IPsec VPN tunnel
We also have a Private WAN connection which we no longer want to use
We want all traffic to travel via our ISP including LAN-to-LAN
LAN-to-LAN traffic will travel over the IPsec VPN (via the ISP) so it is
encrypted. (IPsec configuration not shown but included at the end)
Lets test to make sure this is working

21

Although the ping was successful, it appears that the tunnel is down.
Recall that we also implemented NAT.
Perhaps this is causing some problems with the IPsec tunnel being created.
To test this, we will enable the debug ip nat command and reissue the
extended ping

22

 Again, the pings are successful.

Notice, however, that the internal IP address is being translated to a global
NAT IP address, making the source traffic uninteresting source IP is
NOT 192.168.1.0/24 but from the NAT Pool 209.165.200.249.
Corporate LAN-to-LAN IPsec traffic does not need to be translated by NAT.
It should remain private in its path, because it is encapsulated inside
another IP packet.
However, NAT can interfere with this process.
Because the NAT process takes place before the encryption process,
by the time the traffic arrives at the crypto map ACL, it looks like it is
from 209.165.200.248 /29 going to 10.10.10.0.

23

This presentation
Created our broadband connection
Configured NAT for traffic over Internet
Changes private source IP address for traffic over the Internet
Configured IPsec
Want all traffic including LAN-to-LAN to use Internet (ISP)
Want to secure LAN-to-LAN traffic between Branch and HQ over the
Internet using IPsec
Problem: LAN-to-LAN traffic is being sent over Private WAN
Solution: Modify NAT to create a NAT exemption
Problem: IPsec does not support broadcasts and multicasts so cannot
send EIGRP routing updates
Solution: Use GRE tunnel Encapsulate traffic inside a GRE pointto-point tunnel, then inside an IPsec tunnel
Must add GRE tunnel network to EIGRP so all LAN-to-LAN traffic
uses GRE tunnel
24

Interesting traffic for VPN

Traffic to be translated via NAT

ACL 110 identifies interesting VPN traffic

BRANCH-NAT-ACL identifies traffic to be translated
The crypto map ACL 110 is configured to encrypt traffic between 192.168.1.0/24
to 10.10.10.0/24 but
The traffic arrives at the crypto process with a 209.165.200.249 source IP
address
So, the crypto map does not encrypt it (does not use the VPN tunnel)
So the current NAT configuration is creating a problem
Solution is to create a NAT exemption.
The NAT access list must also identify when traffic should not be translated.

25

NAT exemption
Existing command

For the NAT process (ACL that identified traffic to translate):

a deny line means "do not translate
Do not translate packets going from Branch LAN to HQ LAN
a permit line in an access list means "translate"
Do translate packets to Branch LAN to all other destinations

26

 The ping is successful, but it appears that NAT still translated the inside
LAN address.
Lets verify the NAT translation

27

 Notice that the 192.168.1.1 address is still in the NAT cache.

This is the cause of our current problem.
The NAT translations should be cleared, and only then will the branch router
enforce the new BRANCH-NAT-ACL entries.

28

 Now our VPN link has been activated

Notice four out of the five pings were successful.
Typical for the initial traffic that initiates the VPN tunnel may time out

29

 Verify

30

This presentation
Created our broadband connection
Configured a floating static route
If Private WAN is down use Internet (ISP)
Configured NAT for traffic over Internet
Changes private source IP address for traffic over the Internet
Configured IPsec
Want all traffic including LAN-to-LAN to use Internet (ISP)
Want to secure LAN-to-LAN traffic between Branch and HQ over the
Internet using IPsec
Problem: LAN-to-LAN traffic is being sent over Private WAN
Solution: Modify NAT to create a NAT exemption
Problem: IPsec does not support broadcasts and multicasts so
cannot send EIGRP routing updates
Solution: Use GRE tunnel Encapsulate traffic inside a GRE pointto-point tunnel, then inside an IPsec tunnel
Must add GRE tunnel network to EIGRP so all LAN-to-LAN traffic
uses GRE tunnel

31

Multicast and
Broadcast

Impact on Routing
A significant drawbacks of an IPsec VPN is that it cannot route multicast
and broadcast packets.
Routing protocols (IGPs) such as EIGRP and OSPF that use multicast
packets cannot send routing advertisements through an IPsec VPN.
However, IPsec can be combined with Generic Routing Encapsulation
(GRE) to create a tunnel to circumvent the issue with IGP routing within
VPN tunnels.

32

Configuring GRE Tunnels

There are four options to route dynamic routing protocols through an IPsec
tunnel:
Point-to-point generic routing encapsulation (P2P GRE)
Virtual tunnel interface (VTI)
Dynamic multipoint VPN (DMVPN)
Group encrypted transport VPN (GET VPN)
In this section, we focus on P2P GRE
33

IPsec Tunnel (LAN-toLAN)

GRE Tunnel

EIGRP traffic

GRE is a tunneling protocol developed by Cisco

Creates a virtual point-to-point link
Common option to use GRE to pass dynamic routing protocol traffic across
an IPsec tunnel.
GRE and IPsec:
Tunnel Within a Tunnel
Does not provide encryption services.
GRE is just an encapsulation protocol.
Our GRE packets will be encrypted by IPsec
34

 Point-to-point GRE encapsulates routing protocols in GRE first

Then the GRE packets are encapsulated in IPsec and encrypted.

35

Configuring
GRE

These following three configuration steps will help us accomplish our goal:
1. Create tunnel interfaces for GRE.
First configure the tunnel interfaces with GRE encapsulation.
Make sure that the tunnel is up and running.
2. Change the crypto ACL to encrypt GRE traffic.
Make a change to the IPsec configuration to include GRE traffic to the
crypto ACL.
This will cause GRE traffic (routing updates) to be channeled
across the IPsec VPN tunnel like other interesting traffic.
3. Configure routing protocols to route through the GRE tunnel.
Last configure our routing protocol to use the tunnel interface.

36

 To avoid errant EIGRP neighbor messages from appearing, remove EIGRP

The tunnel IP address is 172.16.100.2 /30, which will serve as the tunnel
destination in the HQ router tunnel configuration.
Internet-facing interface on the branch router.
The tunnel source command
Used to specify either the source interface or the source IP address
We have chosen to specify the IP address.
The tunnel destination address will be the reachable global IP address of
the HQ router.

37

 Repeat the preceding configurations on the HQ router

The tunnel IP address is 172.16.100.1 /30, which will serve as the tunnel
destination in the HQ router tunnel configuration.
Internet-facing interface on the HQ router.
The tunnel source command
Used to specify either the source interface or the source IP address
The tunnel destination address will be the reachable global IP address of the
Branch router.
Note: GRE over IP is the default for tunnel interfaces (tunnelmodegreip)

38

Tunnel is up and up
Tunnel IP address

Tunnel protocol is GRE over IP

Tunnel source and

destination IP addresses

Verify the current tunnel interface configuration

No traffic is currently using these tunnel interfaces because EIGRP is not
yet aware that it has to use them to communicate.

39

 We must now change the crypto ACL to make the GRE traffic interesting
to enable the IPsec tunnel.
Remove the current crypto ACL and replace it
We will address the LAN-to-LAN tunnel in a moment.
The new crypto map ACL specifies that whenever the public IP address of
the branch router attempts to send a GRE update to the public IP
address of the HQ router an IPsec VPN should be enabled.
The reciprocating crypto map is configured

40

 Ping the tunnel interface on peer

We should now have basic GRE over IPv4 connectivity.
The pings are 80 percent successful, indicating that perhaps the first ping
timed out because of the IPsec VPN being activated.

41

Verify connectivity from the branch LAN to the HQ LAN

LANs can no longer reach each other.

42

X
Default

?
We have the 172.16.100.0 network connected to the Tunnel 0 interface.
Still have the default static route we configured earlier pointing to the ISP.
However, the branch LAN does not know about the HQ LAN located on
Private address space of 10.10.10.0 /24 via the VPN tunnel.

43

 Configure EIGRP to propagate the LAN and the tunnel routing information between the
sites
LAN-to-LAN traffic will now use the Tunnel, encapsulated by GRE and therefore will use
IPsec
44
Verify

 This confirms that packets are indeed traversing the IPsec VPN.

45

 As you can see, regular traffic (non-LAN-to-LAN and non-router-to-router

EIGRP traffic) does not take the GRE over IPsec VPN tunnel

46

 GRE Tunnel Summary

47

Summary
Created our broadband connection
Configured a floating static route
If Private WAN is down use Internet (ISP)
Configured NAT for traffic over Internet
Changes private source IP address for traffic over the Internet
Configured IPsec
Want all traffic including LAN-to-LAN to use Internet (ISP)
Want to secure LAN-to-LAN traffic between Branch and HQ over the
Internet using IPsec
Problem: LAN-to-LAN traffic is being sent over Private WAN
Solution: Modify NAT to create a NAT exemption
Problem: IPsec does not support broadcasts and multicasts so cannot
send EIGRP routing updates
Solution: Use GRE tunnel Encapsulate traffic inside a GRE pointto-point tunnel, then inside an IPsec tunnel
Must add GRE tunnel network to EIGRP so all LAN-to-LAN traffic
uses GRE tunnel

48

49

Suggested Readings on VPNs

IPsec Virtual Private Network
Fundamentals
By James Henry
Carmouche
Implementing Cisco IOS
Network Security (IINS): (CCNA
Security exam 640-553)
(Authorized Self-Study Guide)
By Catherine Paquet
CIS 146 CCNA Security class
Instructor: Gerlinde Brady
Offered Spring 2011

50

Troubleshooting Examples

51

Branch Office and Remote Worker

Connectivity

Branch office connectivity involves multiple topics and technologies,

including WAN connectivity through:
VPN and GRE tunnels
Routing
LAN Services
Security
And other topics

52

Troubleshooting Examples: Connectivity Issues for

Branch Offices and Remote Workers

The examples presented in this section are all based on the network
topology diagram shown
There is a private WAN and an Internet option for branch connectivity. There
is also a remote-access service for mobile users and traveling users.
53

Troubleshooting Example: Address Translation Error

Public IP address

Public IP address

NAT inside source address

The first troubleshooting example is a very common case.

The branch router is using an IPsec tunnel to provide connectivity to headquarters for
its LAN users.
Both LANs use 10.1.1.0/24 networks so any communications between them must be
translated to an address from a different network:
10.1.3.0/24 and 10.1.4.0/24 respectively
This deployment has been working for a while, but a recent change in Network
Address translation (NAT) configuration has caused the tunnel go down and do not
get re-established, and virtual private network (VPN) connectivity to fail.
Regular Internet access however, has been restored, and users are able to connect
to web sites normally.

54

 It seems reasonable to look at the NAT changes and start from there.
On the branch router we use the show ip nat statistics command to
display NAT information
55

NAT Source IP Address Pool

VPN Source IP Address Pool

Notice that all traffic is being correctly translated into a public address range: PUBLIC
PUBLIC pool contains public IP addresses (172.16.0.0 is assumed to be public)
Source IP addresses (10.1.10/24 is translated to a public IP address (172.16.1.100 to .200)
This looks fine
NAT configuration however, includes more translation entries
There is another access list called VPN is being translated into something else...
VPN traffic is exempted from public NAT because it remains private as it goes through the
56
tunnel.

Source IP: 10.1.10.10-200

Source IP: 10.1.10.10-200

VPN Source IP Address Pool

Assuming the same output for both Branch and HQ

Based on the network topology diagram there is a culprit however:
The subnets on the opposite sides of the VPN are both using address 10.1.1.0/24
(overlapping)!
Because of this overlap, NAT is needed to translate VPN traffic into something other
than 10.1.1.0/24 on both sides.
57

Source IP: 10.1.10.10-200

Source IP: 10.1.10.10-200

Change to
Source IP: 10.1.3.0/24
Source IP: 10.1.4.0/24

show ip nat statistics - traffic matching the VPN access list is being statically
translated into an address from the range 10.1.10.10 to 10.1.10.200.
This doesn't seem correct.
Based on the information on the diagram:
Traffic leaving the branch towards the headquarters (destination 10.1.4.0/24) should
have its source address translate to an address from the 10.1.3.0/24 subnet.
The traffic leaving the headquarters network should have its source address
translated to an address from the 10.1.4.0/24 subnet.

58

Source IP: 10.1.10.10-200

Change to
Source IP: 10.1.3.0/24

The branch traffic's source address is being translated to 10.1.10.x instead of 10.1.3.x as it
goes through the IPsec tunnel.
This does matter.
The translated VPN traffic must be tunneled through the IPsec VPN.
The source IP address must match the crypto access list or it won't go through the VPN
tunnel.
You can verify this information using the show crypto map
The crypto map contains a crypto access control list (ACL) which defines the traffic that it
will accept to the VPN tunnel.
ACL 106 and it only matches traffic with source address of 10.1.3.x and destination address
of 10.1.4.x.
Therefore, if the source address of the traffic from the branch translates to anything other
than 10.1.3.x, it will not go through the VPN tunnel
59

 Fix: Remove the old VPN_NAT and adding the new definition which
translates the source IP addresses to 10.1.3.10-200.
Make a similar fix on HQ.
To test that the problem is solved, we ping an address from the 10.1.4.0
pool (headquarters), and notice that now the ping is successful and the
issue is indeed taken care of.
60

Troubleshooting Example: Crypto Map ACL Error

172.16.1.2/24

This time that there is no subnet overlapping between the branch and
headquarters networks (LANs are different subnets).
The symptoms of this troubleshooting example are similar to the last one:
The VPN connection is down, but the Internet connection is working
well.
The culprit could be anything from incorrect DHCP pools to routing issues
and VPN configurations.
61

 This branch router is providing DHCP services to LAN hosts, so we can

start there and use a bottom-up approach for each phase or step along the
path.
show ip interfaces brief we check the Layer 1 and Layer 2 status of the
Branch routers interfaces.
Both the LAN and WAN interfaces are up.

62

 Check if hosts are obtaining IP address and related parameters through

DHCP.
The show ip dhcp pool command on the Branch router shows us that the
address space 10.1.1.0/24 is being served to hosts through DHCP

63

 Check to see if there is a routing problem.

Using the show ip route command see what we expect for a small branch
office: a static default pointing to a next hop on the WAN interface.
64

Deny traffic if coming from 10.1.1.0/24

and going to 10.2.2.0/24, because it does
not need to be translated to go through
VPN tunnel only to the Internet.

Next, you should check NAT.

Basic rule of VPN connectivity is that VPN traffic should not use NAT (remains private
between LANs)
Except for the overlapping network scenario, which is not the case here as
demonstrated
show ip nat statistics command:
The output reveals that traffic matching access list 107 will be translated.
ACL 107 looks correct - denies traffic going from branch to headquarters - means the
traffic going from branch to headquarters will not be subjected to NAT.
65

 Next, check the VPN configuration using the show crypto map on the Branch
router.
The ACL 106 used in the crypto map states that only the traffic with source
address 10.1.3.x and destination address 10.2.2.y will go through the VPN tunnel.
That is not correct, because the traffic from the branch going to the headquarters
(which is not subject to NAT) will have source address of 10.1.1.x, which is
furnished by the DHCP server.
66

 Problem: the source IP addresses of the packets from the branch office are
not matching the crypto ACL.
You can test this hypothesis simply by changing the crypto ACL 106 and
using ping to verify connectivity.
The ping from branch to the headquarters is successful and the problems is
fixed.
67

Troubleshooting Example: GRE Configuration Error

Public IP address

Public IP address

We are routing Enhanced Interior Gateway Routing Protocol (EIGRP)

across an IPsec VPN tunnel, using GRE.
The GRE tunnel is sourced at the loopback interfaces on each router:
10.100.100.1 on the branch router
10.200.200.2 on the headquarters router.
EIGRP is used to advertise internal networks, the networks on the 10.0.0.0
address space, for branch-to-headquarters connectivity.
This time the problem is that traffic is not reaching the headquarters
network, which hosts multiple mission-critical servers.

68

192.168.1.2172.16.1.1

Check for the status of the VPN tunnel and look for the IP address of the
branch router as a destination using the show crypto isakmp sa
The status of the tunnel to branch at 172.16.1.1 is ACTIVE.
The same command at the Branch router shows an ACTIVE status as well.
69

No route

The next step is to determine if the headquarters destinations can be found

in the Branch routers routing table.
Use the show ip route command and search for network 10.2.2.0/24.
This subnet is not in there.

70

 We know that routing (advertisement) is supposed to happen over GRE

across the VPN tunnel.
Examine the GRE (tunnel0) using the show interfaces tunnel 0 command.
The tunnel is up but line protocol is down.
Tunnel source is 10.100.100.1 (loopback101)
Tunnel destination is 10.200.200.22 (our diagram show differently)
We must check the Headquarters router and see if address 10.200.200.22
is a valid destination for this tunnel.

71

HQ#

show interfaces tunnel 0 command on the HQ router.

The tunnel source is loopback101 with the IP address 10.200.200.2, not
10.200.200.22.
It looks like a typing error has happened at the Branch router

72

 We return to the Branch router to fix the tunnel destination address error.
We first enter the debug ip routing command to see the EIGRP routes
popping up in our routing table as a result of repairing the tunnel.
tunnel 0 interface
Remove the incorrect tunnel destination address
Enter the correct tunnel destination address (10.200.200.2)

73

 EIGRP neighbor session going up, and almost immediately you see the
routing table being populated across the tunnel.
To confirm end to end connectivity, you then try an extended ping from the
Branch router using its Fa0/0 interface as the source, to the address
10.2.2.1, which resides at the Headquarters
74

Troubleshooting Example: Recursive Routing Problem

Public IP address

Public IP address

The IPsec tunnel was established and tested, and it was carrying user traffic
with no problem.
Then suddenly tunnel interface went down and EIGRP was no longer able to
advertise routes.
Resetting the interfaces didnt help.
Tunnels get established, only to go down after a few seconds every time.

75

Branch#showipprotocols

Verify the EIGRP configuration and learn the autonomous system number
and the networks that belong to this routing process.
The show ip protocols command provides all that information.

76

 Check the status of the GRE tunnel interface using the show interfaces
tunnel command.
The results show that interface tunnel0s line protocol is down, however:
The source and destination of the tunnel, based on the network diagram,
are correct.
The same command on the HQ router shows correct configuration, but the
line protocol is down there as well.
77

noshutdown

Sometimes beneficial to replicate the symptoms and the problem itself.

This can be somewhat challenging in some cases.
Shut down the physical interfaces and bring them back up.
That should initiate the establishment of the tunnel.
We see some informational message:
1. New adjacency with neighbor 10.1.3.2 across tunnel0 is reported.
2. A few seconds we see a message: Tunnel0 temporarily disabled due to
recursive routing.
3. After that, the line protocol on interface tunnel0 changes state to down, and so
does the neighbor 10.1.3.2

78

X
HQ(config)# interface tunnel 0
HQ(config-if)# shutdown
HQ(config-if)# exit
HQ(config)# ip route 10.100.100.1 255.255.255.255 172.16.1.1
HQ(config)# interface tunnel 0
HQ(config-if)# no shutdown

One way to fix this issue is to make sure that there is always a path to the tunnel
destination (10.100.100.1) via the public IP address (or other) and that not through
the tunnel itself.
In other words the router needs a path directly to the public IP address of the tunnel
(172.16.1.1) and that path can not be through the tunnel
A static route is a way to do this.
ip route 10.200.200.2 255.255.255.255 192.168.1.2
Enter a similar command on the Branch router mirroring the one entered at the HQ
router
Problem solved

79

CIS 188 CCNP TSHOOT

(Troubleshooting)
Ch. 9 Troubleshooting Security
Implementations
Rick Graziani
Cabrillo College
graziani@cabrillo.edu
Fall 2010