1. Home
  2. Cisco Systems
  3. reverse route injection maintenance

reverse route injection maintenance

Hi all,

posted a while back on issues of 'reverse routes' not being removed from an IOS (12.4) routing table, and no reply back so please help !

This is question re maintenance of the static routes that are dynamically inserted when we have the "REVERSE ROUTE" configuration in the dynamic crypto map.

IOS version - c1700-advsecurityk9-mz-124-17a.bin

VPN clients - Cisco vpn clients v4.6

the expected behaviour is that the static route to the IP address that is 'leased' by the vpn client by way of "ip local pool' configuration via the (public) IP address of the vpn client would be removed when the IPSEC SA is torn down or timed out by the IOS vpn server.

the observed behaviour is that instead of any of these routes being removed, another route to the leased IP address is added via the public address of the next VPN client that leases that IP address such that a sample of the output from 'show ip route' gives us;

192.168.2.10 [1/0] via 86.145.45.34 via 86.140.228.10 .......

192.168.2.8 [1/0] via 87.56.23.34 via 78.56.42.34 via 89.34.62.23 ....

etc for all the IP addresses in the local pool.

this is even though the destination IP addr is freed from the IP pool, and the IPsec SA should no longer be valid.

Help in this will be gladly received.

Reply to
Graham Turner
Loading thread data ...

Please post relevant portions of config

Reply to
Merv

Merv, thanks for note;

i insert the crypto configuration here which i think is the pertinent config - if any other is needed let me know

crypto dynamic-map SDM_DYNMAP_1 1

set transform-set ESP-3DES-SHA

reverse-route

!

crypto map SDM_CMAP_1 client authentication list sdm_vpn_xauth_ml_1

crypto map SDM_CMAP_1 client accounting list acct_list_2

crypto map SDM_CMAP_1 isakmp authorization list sdm_vpn_group_ml_1

crypto map SDM_CMAP_1 client configuration address respond

crypto map SDM_CMAP_1 10 ipsec-isakmp

set peer Q.W.E.R

set transform-set ESP-3DES-SHA1

match address 110

crypto map SDM_CMAP_1 65535 ipsec-isakmp dynamic SDM_DYNMAP_1

!
Reply to
Graham Turner

If the RRI created routes are still there after the IPSEC SA for the peer expires then that is a bug

Check that the IPSEC SA's are being removed after the VPN client disconnects

Reply to
Merv

ipsec SA's are being removed such that they do not appear in 'show crypto ipsec sa"

however, what is 'interesting' is that the peers that should no longer be valid seem to be retained perhaps in the SA table ? such that they are listed (but with no spi, transform etc ..) in the output of;

'show crypto ipsec sa address'.

this indicates to me that perhaps they are not in fact being 'purged' from the SA table ?,

Reply to
GT

If you have SmartNet on the unit, then suggest you open a case with the Cisco TAC

Reply to
Merv

Just curious if there was any sort of solution to this... I'm seeing the exact same issue.

Reply to
kicker4

none received i am afraid

would seem a bug, poss on account of these routes being associated with not 'real' interfaces, and as such not being managed correctly.

looking at virtual tunnel interfaces, which hopefully support dynamic clients and routes that are managed correctly as interfaces / aka ipsec tunnels go up and down

Reply to
GT

Thanks for the response... I was able to clear mine with a reboot of the box and I've not seen them come back yet. Hopefully it stays that way, but I'll be reading the release notes to see if it's mentioned!

rg

Reply to
kicker4

the observed behaviour in my case, was that while router reload did flush these routes, they would return and not be removed as would be expected.

Reply to
GT

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.