VRFs can be used on a router acting as a VPN gateway in order to isolate the routing tables of encrypted and cleartext traffic. As default when not using VRFs all routes are within the global routing table. A Frontdoor VRF (FVRF) can be defined on the outside/WAN interface; all traffic within this VRF would be encrypted. An Inside VRF (IVRF) would be used for cleartext traffic defined on the interface(s) on the inside of the network.
In this blogpost scenario the Hub and Spoke routers will be configured as follows:-
The Hub router will use a DVTI (Virtual-Template)
The Spoke router(s) will be configured with an SVTI Tunnel Interface per IVRF (in this scenario 2 IVRFs will be used).
The Hub router will not accept more than 1 tunnel from the same source peer address, therefore a loopback interface per tunnel is defined on the spoke routers’ – this must be routable over the internet/WAN.
RSA Certificates will be used for authentication. The spoke routers’ will require a unique certificate per VRF
Authorization will be performed on the Hub, a unique value in the OU field will distinguish between the spoke tunnels, with the IKEv2 name-mangler feature extracting the OU value.
Multiple Local IKEv2 Authorization Policies will be defined on the Hub, the Policy name matching the exact value in the OU field in the spokes’ certificate. In this instance the OU value is the same as the IVRF, it does not need to the same name as the IVRF.
The Hub’s IKEv2 Authorization Profile will reference a unique AAA Attribute list, which will define the unique VRF to be assigned to the Virtual-Access interface dynamically created on the Hub.
The spoke router(s) will also perform Authorization, but the policy will be static configured (name-mangler not required)
IKEv2 Routing will be used for one VRF and EIGRP will be used for the other
This post does not cover the full configuration of FlexVPN, refer to the previous blog posts for more information:-
A Cisco IOS Router can be configured as a Certificate Authority (CA), distributing and managing (revoking) digital certificates. IOS routers enrol with the PKI Server and issued a certificate for use during the authentication phase when establishing a VPN tunnel. When authenticating peers exchange certificates and validate the identity of the peer and if successful establish a secure IKE Security Association, through which an IPSec SA can be established.
The purpose of this post is to describe the steps to configure a basic PKI/CA Server on a Cisco IOS router.
In this example FlexVPN Remote Access VPN users will authenticate to the Hub router using RSA certificates. Using the IKEv2 Name Mangler feature, the organisation-unit (OU) value will be extracted from the certificate and assigned a Local IKEv2 Policy based on the extracted value. The IKEv2 Policy name must match exactly the value defined in the OU. The IKEv2 Policy in conjunction with the AAA attribute list will assign different attributes to the users’ sessions, for example VRF, IP Pool, Access List etc.
This configuration is an example of FlexVPN Local Authorization, the same can be achieved using a RADIUS server. Refer to the previous posts for additional FlexVPN information:-
This post describes how to configure the Cisco ASA and AnyConnect VPN to use the Start-Before Logon (SBL) feature. This allows the user to connect to the VPN before logging onto Windows, thus allowing login scripts and Windows Group Policies to be applied.
Create/Modify the AnyConnect Profile
Open the AnyConnect VPN Profile Editor
Open the existing VPN Profile or create a new file
Under VPN > Preferences (Part 1) select User Start Before Logon
When using a Cisco ASA for Remote Access VPN (SSL-VPN or IKEv2/IPSec) with the AnyConnect client, in most typical scenarios ALL traffic from the AnyConnect VPN client is encrypted and tunnelled back to the ASA. When using the ASA as the VPN headend device with the AnyConnect client you can use split tunnelling feature, which can be configured to include or exclude certain networks from the VPN tunnel.
The basic configuration of a Remote Access VPN to tunnel all traffic back to the ASA
group-policy GP-1 internal group-policy GP-1 attributes dns-server value 192.168.10.5 192.168.10.6 vpn-tunnel-protocol ssl-client split-tunnel-policy tunnelall address-pools value VPN_POOL
On Windows the AnyConnect Route Details would indicate 0.0.0.0/0 is a Secured Route, meaning all traffic is tunnelled back to the ASA.
When configuring a VPN (crypto map or VTI) on a Cisco ASA firewall, by default all traffic is permitted. The command sysopt connection permit-vpn is enabled by default, with this command the interface ACLs will be ignored for traffic traversing the VPN tunnel, therefore permitting all traffic over the VPN tunnels. In order to restrict traffic within the VPN tunnel on an ASA a VPN Filter must be configured, multiple VPN Filters can be and assigned per group-policy, therefore per VPN tunnel.
The VPN Filter uses an Access List, however the ACE are not written as per a normal ACL, the SOURCE network/port is always the REMOTE network and the DESTINATION is always the LOCAL network/port. The VPN Filter is stateful and will therefore permit the return the traffic without having to explicitly permit the traffic.
This post will not cover the configuration of a VPN on the ASA, this has been covered in the following posts: – VTI or Crypto Map.
In this example a VPN between HQ_ASA and BRANCH-3_ASA is already configured and operational. A VPN Filter will be configured and applied only to the HQ ASA. Important to remember as far as the VPN Filter ACL is concerned the SOURCE network is BRANCH-3 network (10.30.0.0/22) and the DESTINATION will be HQ network (10.10.0.0/22).
The Firepower SSL Decryption feature allows you to block encrypted traffic without inspection or inspect encrypted that would otherwise be unable to be inspected. In order for the FTD to decrypt the traffic the FTD must resign all certificates of websites, this is achieved by a Man in the Middle (MITM) attack. An internal CA must be used to issue a certificate using the Subordinate Certificate Authority template; Firepower will then dynamically create a certificate on the fly (spoofing the real certificate) thus allowing for decryption and inspection of the website. The client computer must trust the Internal CA so as not to receive any certificate errors.
In this scenario an FTD v6.2.2 is acting as the gateway that will decrypt the traffic, all configuration will be made on the FMC v6.2.2.