CCNP Route - Branch Office connections (VPNs, IPSec, GRE)

CCNA Security IPSec Site-to-Site Configuration Lab 

Options exist today for connections between an branch office and the core of an Enterprise network:
- private connectivity (provide an inherently private path):  leased lines, Frame Relay, MPLS VPNs, Metro Ethernet.
- public connectivity. All public options use the Internet for connectivity regardless of the particular physical Internet access technology–typically DSL, cable, or wireless broadband–all these options use a public Internet to forward the packets.

Broadband Internet Access Basics
The term broadband - (today) has grown to become synonymous with high speed.
 The hardware typically includes an IP router and either a cable modem or DSL modem.
The term modem has taken new meaning over the years compared to its original historic use. (a cable modem or DSL modem sits in the same location as a traditional analog modem,)

 - LAN interface connected toward the ISP, the router uses a slightly different convention on the Ethernet called PPP over Ethernet (PPPoE).
The frames sent by the router still use an Ethernet header, but then include a PPP header, and then an IP header.
The PPP header gives the router and ISP the capability to use PPP features such as the Challenge Handshake Authentication Protocol (CHAP). CHAP allows the ISP to perform authentication, which allows the ISP to confirm the identity of the router that sent the packet.
- DSL uses a similar protocol, PPP over ATM (PPPoA), also in part to support PPP CHAP.

Consumer-class products enable by default most of the features such as DHCP client, server, and NAT/PAT.
Enterprise-class routers typically rely on explicit configuration by a network engineer for these same features.

Branch Office Security
With a permanent Internet connection near the core of the Enterprise network, the Enterprise typically uses one or more border security products. These products include stateful firewalls such as the ASA appliance from Cisco, plus Intrusion Prevention Systems (IPS).
Again, for economic reasons, it makes more sense to implement those features on the same router platform already needed for so many other reasons. So, Cisco includes firewall and IPS features in IOS. These features include the older Context Based Access Control (CBAC) and newer IOS Zone-Based Firewall. Cisco also supplies the IOS IPS feature as well.
Although it may seem that running such features on a branch router might overload the router, Cisco designed its Integrated Services Routers (ISR) to have the power to concurrently run many services for exactly this type of application. ISRs include the older model
series 800, 1800, 2800, and 3800 ISR families, plus model series 1900, 2900, and 3900, introduced in 2009.

IPsec Tunnels
Typically the engineer configures a tunnel between the branch and the Enterprise core.
Then the branch router directs traffic destined for the Enterprise through the tunnel.
For such packets, the branch router will not translate the IP address of the original packet using NAT. Instead, the branch router will encrypt the IP packet and encapsulate the encrypted packet inside another IPv4 header, using public source and destination addresses in this new packet. Then, the branch router can forward this packet through the public Internet, with a device in the Enterprise core receiving and decrypting the packet.

IP Security (IPsec) defines the details of how this particular tunnel works. IPsec defines which security standards may be used to encrypt the packet–for example, IPsec allows the use of triple DES (3DES) and Advanced Encryption Standard (AES).

Branch Routing for the Small Branch
With the addition of an IPsec tunnel from the branch to the Enterprise core, the branch does have a kind of routing decision to make: to send a packet through the tunnel, or to send it to the local ISP after performing NAT

Routing in Medium and Large Branches
Another private WAN connection exists between the branch and the Enterprise core. So, the branch needs to make choices about when to use routes that use the private connection and when to use routes that use the public connection.

GRE is a tunneling protocol developed by Cisco.
It is capable of encapsulating a wide variety of network layer protocols packets inside IP tunnels. This creates virtual point-topoint links. It is a common option to use GRE to pass dynamic routing protocol traffic across an IPsec tunnel.
GRE tunnels do not provide encryption services. GRE is just an encapsulation protocol. It does not offer other services such as encryption. By default, the traffic leaves in clear text.

Two main routing options exist: using static routes and using an IGP.
Static routes can be used to forward traffic over the private connection and over the IPsec tunnel.

Routing Updates over GRE over IPSec
The routing protocols will be associated with tunnel interfaces, which will use the physical interface of the router to send GRE traffic that will then have to match the parameters of the crypto map and therefore be encrypted by IPsec.
With GRE, multicasts and broadcasts will be carried inside unicast packets, which IPsec can forward.

However, IPsec does not directly support IGP protocols, because the IPsec tunnel cannot natively forward IPv4 multicasts.
To overcome this restriction, you can use a GRE tunnel that actually runs over the IPsec tunnel. GRE supports multicasts by encapsulating them in unicast packets, so GRE supports IGPs.

GRE and IPSec create overhead

Configuring GRE
1. Create tunnel interfaces for GRE.
2. Change the crypto ACL to encrypt GRE traffic.
3. Configure routing protocols to route through the GRE tunnel.

A common best practice is to create a loopback interface, which is then used as the tunnel source IP address.
interface tunnel 0
  ip address
  tunnel source
  tunnel destination
access-list 110 permit gre host host
router eigrp 1
  no auto-summary
A GRE tunnel can be configured to operate within an IPv4, IPv6, or multipoint configuration using the tunnel mode gre command.
However, by default the encapsulation of GRE is within an IPv4 packet, and therefore the tunnel mode gre ip command is not required.
Optionally, the keepalive command could also be configured to provide a trigger mechanism to cause the line protocol to be changed from an up/up to an up/down state during a failure event.

GRE implementation plan to upgrade a branch office:
Step 1. Deployed broadband connectivity
Step 2. Configured static routing
Step 3. Verified other services
Step 4. Implemented and tuned the IPsec VPN
Step 5. Configured GRE tunnels

show interfaces tunnel 0
show crypto session detail
The IPSEC FLOW is permitting IP protocol 47, which is the protocol number for GRE

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)

GRE features:
■ A GRE tunnel acts like a point-to-point link from a Layer 3 perspective.
■ A GRE tunnel supports many passenger protocols, including IPv4.
■ A GRE tunnel encapsulates/forwards broadcasts and multicasts, therefore supporting IPv4 IGPs.
■ A GRE tunnels can run through IPsec tunnels.

A major benefit of VTI is that the configuration does not require a static mapping of an IPsec session to a physical interface.
The IPsec endpoint is associated with an actual virtual interface. This is then a routable interface at the tunnel endpoint, and many common interface capabilities can be applied to the IPsec tunnel. They include the association of routing protocols and therefore routing across the VPN tunnel. In the end, VTI is a good alternative to IPsec over GRE tunnels.

Nowadays, with VoIP, branch offices expect to call other branch offices directly, without going through headquarters, which would only contribute latency.

Scalable alternatives to GRE when full-mesh connectivity is necessary between the branches are DMVPN and GET VPN. 
These technologies combine multipoint GRE tunnels, dynamic resolutions of endpoints, and crypto profiles that overwrite the requirement for defining crypto maps.

VTI, DMVPN, and GET VPN are beyond the scope of CCNP

Floating Static Routes
Routing Using Floating Static Routes

A floating static route - ip route command configures a static route in which the command overrides the default AD value of 1.
For example, if the IGP learns a route for the same prefix as defined in the static route, the router does not use the static route with the higher AD, instead uses the dynamically learned route with the lower AD.
The term floating static refers to that the route may float in and out of the routing table.

Dynamic Routing over the GRE Tunnel
Simply configure an IGP to run as normal, over both the private WAN connection and over a GRE tunnel.
The design can then use all the usual tools to manipulate the choice of routes, including tuning the metrics and configuring variance to influence load sharing.

DSL uses the Telco local loop: the phone line that runs between the phone company’s nearby facility (called the central office, or CO) and the customer site.

From the customer premise perspective, the customer can still use the same old analog phones, which still use frequencies below 4000 Hz. The DSL router connects to another RJ-11 socket in the wall, just as if it were just another analog telephone. However, the
router sends digital signals at frequencies above 4000 Hz, which does not interfere with the voice traffic. So, both the voice and DSL electrical signals flow over the same cable, at the same time, just at different frequencies.
 - some DSL installations require the use of filters on the lines connected to the phones. These filters prevent humans from hearing some of the higher frequency DSL tones.

From the telco perspective, the Telco has to separate the voice and DSL signals. To do so, the Telco uses a device called a DSL Access Multiplexor (DSLAM). It splits the analog signal off to the switch that handles traditional analog voice calls and splits the digital
traffic to a router.
DSL: Customer and Telco perspectives

At Layer 1, the DSL uses digital signals that use some encoding.
At Layer 2, DSL uses two different data link protocols: Asynchronous Transfer Mode (ATM) and Point-to-Point Protocol (PPP).

DSL uses ATM in the traditional role of a data link protocol, and PPP for several reasons, but particularly for its CHAP authentication. For DSL, ATM controls the use of the Layer1 medium so that data can be successfully sent over the link and to the right device.
ATM defines the headers used on the link, the data link addresses, and the rules for passing Layer 3 data up and down the protocol stack. For instance, the ATM cell headers enable the DSLAM to know where to send the data received from a customer over a DSL link.
ATM uses a PVC concept similar to a Frame Relay PVC. With DSL, an ATM PVC would exist between the DSL router at the branch and the ISP router.
 - ATM address identifies the PVC, but the address value is local, so the value used by one endpoint may be different than the address used on the other end of the PVC,
 - Frame Relay uses the DLCI as the identifier of a PVC, whereas ATM uses a twopart address, called the Virtual Path Identifier/Virtual Connection Identifier (VPI/VCI).

When a packet needs to be sent out a Frame Relay interface, the router adds a Frame Relay header and trailer and sends the frame.
ATM adds a short extra header to the packet and then performs segmentation. The segmentation process breaks the data into 48-byte segments and adds a 5-byte header to each to create ATM cells. The cell header holds the VPI/VCI pair, which allows the network to forward the cells to the correct destination end of the PVC.

Encapsulation process also adds a PPP header to the IP packet before sending the data over the DSL link. The routers use the PPP header for several reasons, including PPP authentication with CHAP, and for dynamic address assignment and discovery. This convention to use both PPP and ATM protocols together is called PPP over ATM (PPPoA).

DSL Configuration
First consider that DSL is a switched connection. (is not always ON service- a router can start and stop the DSL connection).
The idea that DSL routers do something to dial the connection means that the connection is actually switched.
 IOS implements DSL configuration using some older switched network commands, including dialer interfaces and virtual templates. (logic and features related to a dialed connection).
The main pieces of the DSL configuration as shown in this section are as follows:
■ The configuration creates a dialer interface.
■ The Layer 3 and PPP configuration related to DSL is applied to the dialer interface.
■ The ATM configuration is applied to the physical ATM interface.
■ The ATM interface is linked to the dialer interface.
■ An IP route forwards traffic out the dialer interface, which triggers the DSL encapsulation process.
interface ATM 0/0
 no ip-address
 pvc 0/42
    encapsulation aal5mux ppp dialer
    dialer pool-member 1
interface dialer 2
 encapsulation ppp
  ! Use PPP to Ask ISP the IP Address to Use
 ip address negotiated
 dialer pool 1
! Chap-Related Commands
hostname BO1
ppp authentication chap callin
ppp chap password reallysecret
ip route dialer 2
Configuring NAT
NAT configuration easily supports the concept of performing NAT for traffic going to Internet destinations and not performing NAT for traffic in the tunnel.
! NAT overload example
interface fastethernet 0/0
  ip address
  ip nat inside
interface dialer 2
  ip nat outside
! source IP address is from the branch’s local LAN subnet (
ip nat inside source list local-lan interface dialer2 overload
ip access-list extended local-lan
   permit ip any
Configuring DHCP Server
The branch router also may need to act as the DHCP server.
ip dhcp pool fred
  ip dhcp exclude-address
Note that no interface configuration is needed on the LAN interface–the router notices the incoming interface of the DHCP request, compares the connected subnets to the pool, and picks a pool that matches the correct address range.

IPSec Configuration
IPsec tunnel unfortunately does not allow IGP traffic to  flow directly over the IPsec VPN tunnel.
 - GRE,
 - Virtual Tunnel Interfaces:Similar in concept to GRE tunnels but it uses an encapsulation that does not add and extra 4-byte header. (GRE adds such a header.)
 - Dynamic Multipoint VPN (DMVPN):Creates a multipoint VPN concept, allowing less configuration to add new sites.
 - Group Encrypted Transport (GET) VPN:A more recent addition to IOS, also supporting multipoint VPNs with less configuration to add new sites.

Configuring an IPsec VPN
! Security details
crypto isakmp policy 1
  encryption 3des
  authentication pre-share
  group 2
crypto isakmp key donttellitsasecret address
crypto ipsec transform-set name-i-chose esp-3des esp-sha-hmac
! Tunnel details
crypto map branchmap 10 ipsec-isakmp
  set transform-set name-i-chose
  set peer               <-destination (another end-point) of tunnel
  match address 101
! The crypto map causes IOS to only encrypt and tunnel the packets that are matched by ACL 101
access-list 101 permit ip
access-list 101 permit gre any any
! enable the logic - causing IOS to consider applying IPsec to packets exitingDialer 2
interface dialer 2
   crypto map branchmap
GRE Tunnels Configuration

interface tunnel 9
   ip address
   tunnel source loopback 1
   tunnel destination
! tunnel mode command is not needed, because IOS defaults to use IPv4 as the transport protocol
interface loopback 1
   ip address
router eigrp 1
ip route dialer2
The configuration also requires two main branches of logic for routing to work correctly:
 - the tunnel destination must be reachable (a static route was added for this purpose),
 - the routers need to exchange routes that will list the tunnel interface as the outgoing interface, which in turn directs
packets through the tunnel. (EIGRP configuration that enables EIGRP on tunnel 9)

Summary–Branch Routing from PC1 to Enterprise Server S1

1. R1 receive packet with dst=
2. R1’s best route for destination uses outgoing interface tunnel 9
3. R1 adds a new private IPv4 header and GRE header to the original packet (tunnel destination is address
4. R1 best route for lists Dialer 2 as the outgoing interface. The crypto map on interface Dialer 2 refers to an ACL, and ACL matches this packet with a permit action. This combination of logic tells R1 to use IPsec to encrypt this packet for transmission over the IPsec tunnel.
5. R1 encrypts the packet the GRE-created packet (step 3).
6. R1 encapsulates the encrypted data, adding several IPsec headers, plus a new IPv4 header (src_ip=R1 Public IP, dst_ip= end of the IPsec tunnel  ==
7. R1 routes packet to matching a route (probably a default route) that lists Dialer 2 (again) as the outgoing interface.
However, the crypto map’s ACL does not match the packet with a permit action, so BO1 bypasses any further IPsec functions and simply tries to forward the packet.
8. Forwarding out the dialer interface then causes this DSL-connected router to forward the packet out the underlying ATM interface, which performs the encapsulation and segmentation.

Interestingly, this process drives the branch router to make comparisons to the routing table three separate times when forwarding this data.