GRE over IPSec VPN

A GRE over IPSec VPN is a legacy solution that uses a crypto map to encrypt GRE traffic between two peer routers. GRE tunnels are required to tunnel unicast, multicast traffic between two peers and useful establishing a routing adjacency between sites, which a crypto map VPN cannot achieve natively. GRE transmits traffic in clear text, which is why IPSec is used to ensure the GRE traffic is encrypted.

Since IOS-XE 16.6 static and dynamic crypto maps are End of Life, Cisco recommends using Virtual Tunnel Interfaces (VTI) such as FlexVPN or DMVPN. Refer to the previous posts on FlexVPN and DMVPN.

This post covers the basic configuration of a GRE over IPSec VPN tunnel on Cisco IOS-XE routers.

FTD Dynamic VTI

Cisco FMC/FTD version 7.3 introduced support for Dynamic Virtual Tunnel Interfaces (DVTI). A DVTI allows for a single tunnel configuration on the Hub FTD for connecting to hundreds of spokes, instead of configured 100s of Static VTI’s peer spokes, which simplifies the configuration of the Hub FTD. Like the Cisco IOS-XE FlexVPN solution, the FTD uses a virtual template, this is dynamically cloned, and a virtual access (VA) interface is created when a VPN is established. The Virtual Access interfaces inherits the settings from the virtual template interface. The Virtual Access interface is active on the Hub for the duration of the VPN tunnel between itself and the spoke, once the tunnel is terminated the Virtual Access interface is removed.

This post covers configuring a Hub and Spoke VPN topology, with an FTD acts as the Hub and two spoke devices, another FTD and a CSR1000V router. Both FTD’s will utilise Loopback interfaces for the tunnel interface and run BGP over the VTI.

The following software versions were used:-

• Management – Cisco FMC 7.4.1
  
• Hub – Cisco FTD 7.4.1
  
• Spoke 1 – Cisco FTD 7.4.1
  
• Spoke 2 – CSR1000V 16.6 Router
  

The figure below represents the topology used in this post.

ASA firmware upgrade

This post will describe how to upgrade a standalone Firepower 1010 hardware running ASA firmware version 9.18.2 to 9.20.2. The software upgrade image will be copied to the ASA using SolarWinds SFTP/SCP Server software, this is free to download and install.

Before upgrade the ASA firmware you should read the release notes of the new version you wish to upgrade to, in order to determine if there are any caveats to be concerned about. https://www.cisco.com/c/en/us/support/security/adaptive-security-appliance-asa-software/products-release-notes-list.html

FTD URL Filtering

With the URL Filtering license, the Cisco Secure Firewall FTD devices can filter based on category and/or reputation of the URL, a URL database is frequently updated from the Cisco Cloud so should always be up to date with the correct information. Without the URL Filtering license (just the Base license) an administrator can manually define URL(s); this does create a management overhead and not practical when permitting access to the internet as a whole.

This post covers URL Filtering on the Cisco Secure Firewall FTD.

FTD Transparent Mode

The Cisco Secure Firewall FTD software supports two firewall modes, routed and transparent. A transparent firewall is a layer 2 firewall that acts like a stealth firewall and is not seen as a router hop between connected devices. Unlike a traditional deployment of a firewall in routed mode, where the firewall is a routed hop between networks. The transparent firewall controls traffic between interfaces using Access Control rules, the same as a firewall in routed mode.

Bridge groups are used to achieve layer 2 connectivity, where interfaces are grouped together, and the FTD uses bridging techniques to pass traffic between the interfaces. Each bridge group includes a Bridge Virtual Interface (BVI) to which an IP address must be assigned for the FTD to pass traffic.

FTD Transparent Mode firewall key points:

• ARPs are allowed through the FTD without an Access Control rule.
  
• Broadcasts and multicast traffic can be passed using Access Control rules.
• Spanning Tree BPDUs are passed by default.
• The BVI IP address should not be the default gateway to connected devices.
• A default route is only required for management traffic.

FTD Traffic Zones (ECMP)

Cisco Secure Firewall (FTD) Firewall supports Equal Cost Multi-Path (ECMP) routing using traffic zones to group interfaces to load balance traffic over multiple interfaces.

• ECMP supports asymmetric routing and load balancing.
  
• Up to 8 interfaces can be grouped within a zone.
  
• ECMP traffic zones are supported in routed mode only.
  
• Supported using FTD 6.5 and higher.
  
• FMC 7.1 allows native configuration of ECMP in the GUI, older versions require using FlexConfig.
  

ASA NAT Traversal (NAT-T)

An IPSec VPN uses IKEv1 or IKEv2 on udp/500 to establish a secure control plane tunnel, the IPSec SAs can then be negotiated and established using Encapsulating Security Payload (ESP) to encapsulate the encrypted packets.

ESP is an IP protocol without ports, which prevents ESP from being translated using NAT. When traffic between the two VPN peers is translated using NAT, this requires the VPN peers to use NAT Traversal (NAT-T). NAT between two peers is detected by NAT-T during IKE SA negotiation and before the IPSec SA are established. NAT Traversal is enabled on Cisco ASA Firewall as default.

NAT Traversal performs the following:

• NAT discovery is run by both peers to detect if the remote peer supports NAT-T.
  
• Both peers compute a hash of the the source and destination IP address and Port and sends to the remote peer.
  
• If the hashes match, each peer knows that NAT does not exist in the path to the VPN peer and traffic is encapsulated using ESP. If the hashes differ, then one of the devices is behind NAT and each peer uses NAT-T to encapsulate the packets using udp/4500.
  

NOTE – NAT keepalives are sent between the peers at regularly intervals to ensure the NAT devices do not expire translations after an idle period.

This post describes the purpose of NAT Traversal (NAT-T) when establishing a VPN behind a device performing NAT using Cisco ASA Firewalls.

ASA tunnel internet over VPN

In some circumstances organisations require routing internet traffic from remote branch sites over an IPSec VPN back to the Data Centre and then access the internet from the Data Centre rather than directly access the internet from the remote site.

This post covers the configuration of a Cisco ASA VPN to allow routing internet traffic from a branch site over the VPN and assumes there is already a functioning Policy Based (crypto map) VPN between 2 Cisco ASA Firewalls.

ASA 3DES License

When configuring a reimaged ASA device either using ASA or Firepower hardware, the device will not have a 3DES-AES license, which will mean cryptographic functionality will be disabled, this includes SSL, SSH and IPSec. For example, If configuring SSL ciphers, you may receive errors as per the output below.

ASA(config)# ssl cipher tlsv1.2 custom "ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256"
ERROR: Invalid version/level combination: no compatible ciphers found
ERROR: Unable to update ciphers.

You can confirm the 3DES-AES license is enabled or disabled by running the command show version from the CLI.

Securing IOS-XE Routing Protocols

Securing the routing information prevents an attacker from introducing false routing information into the network, which could be used as part of a Denial of Service (DoS) or Man-in-the-Middle (MiTM) attack. This can be mitigated in part by using password authentication with routing protocols between routers. Cisco router/switches support plaintext, MD5 and SHA authentication with RIP, EIGRP, OSPF and BGP routing protocols.

Plaintext authentication is used when devices are unable to support MD5 or SHA for authentication, which is unlikely on modern hardware. Using plaintext passwords makes the routers vulnerable if the packets are captured and the password can be read. MD5 (message digest) authentication provides higher security than plaintext authentication, when you use MD5 hash capabilities to the authentication process, routing updates no longer contain cleartext passwords, and the entire contents of the routing update is more resistant to tampering. However, MD5 authentication is still susceptible to brute force and dictionary attacks if weak passwords are chosen. SHA authentication is more secure than MD5 (and plaintext) authentication.