CCNP Topology VPN 02

Our second VPN will be from the remote site to the HQ office R2. GRE is used to build a tunnel between sites, and IPSec will be used for encrypting traffic. Initially, we will use static routes to send traffic over the tunnel. Later, we can implement dynamic routing over the VPN.

Remote Site 1 R6 Configuration

Both sites are configured in a mirrored configuration, so we will be showing the R6 side of the set up. Once the configuration is done, verification will show bi-directional communication.

First, we will set up the new VPN settings that will be used. We will set up a new PSK for the new remote peer address of R2, and we will create an IPSec profile using our original transform set. The original isakmp policy will also be used for phase 1 negotiations.

After setting up the VPN portion of the configuration we create the tunnel interface and apply settings. The tunnel interface is a logical interface on the router, and receives an IP address. The 192.168.16.0/30 address space is used in case the remote office needs to add additional VLANs in the future. The Tunnel source is set with our interface, and the destination is the ISP facing interface of R2. Last, the ipsec profile is assigned to the tunnel to encrypt traffic.

Sending Traffic Over the Tunnel

After this, the tunnel exists, but won’t have any traffic. We need routes to move traffic to the tunnel.

We will start with static routes to send traffic to the tunnel, but if connection to the router is lost, we want to use the crypto map VPN. IP SLA Tracking is added to identify loss of connection to the remote router.

IP SLA 20 is sending ICMP to the HQ site, and track 20 is used with the route to the remote networks. A mirrored configuration is set up on the remote side.

Verification

We send ICMP from an inside interface to the remote host and get responses. The responses look good, and the isakmp sa is built for the new peering.

Review of the IPSec security association also shows bi-directional traffic. Everything with the VPN is working. When incrementing counters are seen in our IPSec SAs, we know the tunnel is sending traffic.

Issues with the design as it is now

Although the VPN works as it is set up, the overall topology has an issue. Without going too in depth, given the VPN set up, HSRP, and routing, we can end up in a situation with asynchronous traffic patterns.

Some situations end up with traffic from the HQ office being sent over one VPN path, and return traffic over a second path. This can work, but depending on the actual network, firewall configuration, NAT configuration, and application, we can see issues.

Later, this will be changed, so that we get rid of the asynchronous pattern, but for now we will leave things how they are.