topic Yes, this tunnel is up and in Network Security

ASA has static route in routing table that isn't in configuration

esa_fresa — Tue, 12 Mar 2019 09:23:04 GMT

Our ASA, version 9.6.1, has multiple static routes showing in the routing table that are not in the configuration as a "route" statement.

For example:

#sh route | i 192.168.1.0

S 192.168.1.0 255.255.255.0 [1/0] via 1.1.1.1, Outside

#sh run | i 192.168.1.0

access-list route_map_acl standard permit host 192.168.1.0

Is a route-map doing this somehow? Any ideas what would cause this?

Hi,

Dinesh Moudgil — Thu, 18 May 2017 16:57:20 GMT

Hi,

Couple of things to confirm:

1. Is this a standalone or device in failover?
2. If failover, is this active or standby ?
3. Do you have any IP SLA tracking for routes ?
4. output of "show resource usage"
5. output of "show run all | in 192.168.1.0"
6. output of "show run all crypto map | in reverse-route"

Regards,
Dinesh Moudgil

P.S. Please rate helpful posts.

Active/Standby failover. This

esa_fresa — Thu, 18 May 2017 17:51:43 GMT

Active/Standby failover. This device is secondary-active while the other is in primary-standby. The primary is also running 9.1.6. It's setup this way just while we test; we want to get this issue resolved before we move both permanently to 9.6.1

No IP SLA's are configured.

4. and 5. I'm unable to complete at the moment. On 6, below is the normal show run for this crypto map. We do have reverse-route setup on all of our crypto maps.

crypto map Outside_map 21 match address Outside_cryptomap_20
crypto map Outside_map 21 set pfs
crypto map Outside_map 21 set peer 2.3.4.5
crypto map Outside_map 21 set ikev1 transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-
DES-MD5
crypto map Outside_map 21 set nat-t-disable
crypto map Outside_map 21 set reverse-route

It is possible that reverse

Dinesh Moudgil — Thu, 18 May 2017 18:04:05 GMT

It is possible that reverse route is pushing this route in routing table.

Are these VPN tunnels up ? Check for 192.168.1.0 as the destination address for any crypto access-list for VPN peer. If the tunnel is up , then you will see the route in the routing table.

route_map_acl where is this being used? can you share complete configuration related to this access-list ?

Regards,
Dinesh Moudgil

P.S. Please rate helpful posts.

Yes, this tunnel is up and

esa_fresa — Thu, 18 May 2017 18:25:51 GMT

Yes, this tunnel is up and the static route matches the ACL in the crypto map, so that must be where this route is coming from.

We have other tunnels though that come up when the remote peer initiates the connection, but the static routes do not get created and show crypto ipsec sa shows decrypts but no encrypts. The tunnels are configured the same as far as I can tell; I confirmed these one-way tunnels also have the reverse-route configured.

The route_map_acl is only

esa_fresa — Thu, 18 May 2017 18:27:12 GMT

The route_map_acl is only being used in a route map that redistributes static routes to ospf.

The link below is what I

esa_fresa — Thu, 18 May 2017 22:01:54 GMT

The link below is what I think we're running into. Thanks for your help Dinesh!

https://supportforums.cisco.com/discussion/11617891/asa-5515-x-reverse-route-injection-lan-lan-problem-eigrp-redistribution

Glad I could be of help!

Dinesh Moudgil — Fri, 19 May 2017 01:00:45 GMT

Glad I could be of help!

That will be quite unusual if you have reverse-route set for other VPN tunnels and routes are not properly getting populated. That goes in accordance with the fact that encrypt counters are not incrementing.

Great find on https://supportforums.cisco.com/discussion/11617891/asa-5515-x-reverse-route-injection-lan-lan-problem-eigrp-redistribution.
You might want to check for any known defects on RRI for your ASA version.

Regards,
Dinesh Moudgil