ASA Reverse Route Injection (RRI)

  • Post author:
  • Post category:ASA / Cisco / VPN

Reverse Route Injection (RRI) is used to automatically insert static routes of the endpoints (Remote Access VPN users) or networks (Remote Site-to-Site VPN peers) into the routing process for redistribution using a dynamic routing protocol. This is useful in large environments where the ASA is a dedicated VPN Concentrator and not the default route, thus providing routing information for the remote networks to the upstream network devices (Core or WAN Distribution switches).

On the ASA RRI is supported for AnyConnect Remote Access VPN and Site-to-Site VPN sessions.

Remote Access VPN

When using SSL or IPSec protocols the behaviour is slightly different when configuring RRI.

SSL-VPN

By default, RRI is automatically enabled for AnyConnect SSL-VPN connections. Any active AnyConnect SSL-VPN connection will create a /32 static route in the ASA’s routing table. From the output below we can determine that there are 2 active SSL-VPN sessions.

Run the command show route static and we can easily determine the VPN static routes, the code is “V” identifies the /32 route learnt via the active VPN. Observe the keyword “advertised” for each VPN route, this indicates the route will automatically be advertised via a routing protocol.

Redistribution of the VPN routes can be achieved using a prefix-list to match the RAVPN IP network(s), a route-map to match the prefix-list and configuring redistribution of static routes that match the route-map under the dynamic routing protocol. The ASA configuration below redistributes the RAVPN VPN IP address using OSPF.

prefix-list RAVPN-ROUTES seq 5 permit 192.168.14.0/24 le 32
!
route-map VPN-ROUTES permit 10
 match ip address prefix-list RAVPN-ROUTES
!
router ospf 1
 redistribute static subnets route-map VPN-ROUTES

Once configured, on the directly connected switch the routing table will learn the IP addresses of the active AnyConnect SSL-VPN sessions.

IPSec

When using IKEv2/IPSec instead of SSL, the VPN routes are not automatically available to be advertised via a routing protocol. From the output below, we can determine an active IPSec AnyConnect session, with a static route in the ASA’s routing table, but observe the lack of “advertised” keyword, unlike the SSL-VPN example above.

From the Core switch, we can determine that it has not learnt the RAVPN /32 host route.

To configure RRI of AnyConnect IPSec sessions routes, we must explicitly configure RRI under the dynamic crypto map. Use the following command on the ASA.

crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set reverse-route

IMPORTANT NOTE – when this command is issued, all existing AnyConnect sessions will drop. Ensure this command is configured during a change window.

Reconnect to the AnyConnect VPN session using IPSec protocol. Observe the output below, notice the VPN route now has the “advertised” keyword.

Without any further changes to the ASA (other than the prefix-list, route-map and redistribution as configured in the initial steps) the ASA will now redistribute the VPN routes via OSPF. The output of the Core switch below confirms the routes are learnt.

Summarisation

In a large organisation having 100s or 1000s of /32 static routes may not be desired. Route summarisation on the ASA can be used to always advertise the RAVPN range/subnet – in this example 192.168.14.0/24.

The ASA configuration below creates a static route for the RAVPN network via the outside interface, a new prefix-list matching on the exact /24 route and modifies the route-map to remove the previous prefix-list and matching the new prefix-list.

route OUTSIDE 192.168.14.0 255.255.255.0 1.1.1.254
!
prefix-list RAVPN-SUMMARY seq 5 permit 192.168.14.0/24
!
route-map VPN-ROUTES permit 10
 no match ip address prefix-list RAVPN-ROUTES
 match ip address prefix-list RAVPN-SUMMARY

The output on the Core switch confirms the /24 network is now learnt, the /32 host networks have been removed.

Site-to-Site VPN

Policy Based Site-to-Site VPNs on the ASA do not automatically advertise the VPN routes. From the output below we can determine a VPN tunnel to a peer is established, with 2 IKEv2 child SAs – these identify 2 remote selectors (networks) – 10.10.0.0/24 and 10.10.1.0/24. Notice no VPN routes exist even though IKEv2 SA and IPSec SAs have been established.

To advertise the VPN networks for redistribution, enable RRI on the ASA using the following command:

crypto map <CRYPTO MAP NAME> <SEQ NO> set reverse-route

With this command the VPN routes will appear in the ASA’s routing table

The routes will not be learnt by an OSPF neighbour until redistributed. Create a prefix-list to identify the remote peer networks, a route-map to match the prefix-list and configure redistribute statics under the OSPF process.

prefix-list VPN-NETWORKS seq 10 permit 10.10.0.0/24
prefix-list VPN-NETWORKS seq 15 permit 10.10.1.0/24
!
route-map VPN-ROUTES permit 10
 match ip address prefix-list VPN-NETWORKS
!
router ospf 1
 redistribute static subnets route-map VPN-ROUTES

Checking the routing table of the Core switch confirms the VPN routes have been learnt.

Dynamic RRI

Using the command “crypto map <CRYPTO MAP NAME> <SEQ NO> set reverse-route” will add a VPN static route(s) in the ASA’s routing table regardless of whether VPN has been established. By using the “dynamic” keyword at the end of the command syntax will only add the VPN static routes if the VPN has been established. Note dynamic RRI will only work with static crypto maps.

Tags: , , , ,