reverse route injection maintenance

[Graham Turner]

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.

[Merv]

Please post relevant portions of config

[Graham Turner]

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

!

"Merv" <merv....@rogers.com> wrote in message
news:dfb4f2bd-ec33-4c72...@e53g2000hsa.googlegroups.com...

[Merv]

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

[GT]

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 ?,

[Merv]

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

[kic...@gmail.com]

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

[GT]

On May 7, 8:48 pm, kick...@gmail.com wrote:
> Just curious if there was any sort of solution to this... I'm seeing
> the exact same issue.

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

[kic...@gmail.com]

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

[GT]

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.