OSPF route stuck on ASA for VPN users IP address

[fhk-cwempe]

Hello,

I have a strange issue.

We are using static VPN IP adresses for most of our VPN users.

The routes to this IPs are distributed via OSPF.

They are created and deleted according to the VPN session.

But there is one IP (from a specific user) that does not get deleted and therefore results in an issue for this user when he wants to connect to another on of your VPN servers.

When he is connected to another server I get two routes to his IP on my central router.

central-router#sh ip route 192.168.1.222

Routing entry for 192.168.1.222/32
  Known via "ospf 13906", distance 110, metric 2
  Tag 200, type extern 2, forward metric 1
  Last update from 192.168.0.5 on Vlan300, 00:17:36 ago
  Routing Descriptor Blocks:
    192.168.0.5, from 192.168.0.5, 00:17:36 ago, via Vlan300
      Route metric is 2, traffic share count is 1
      Route tag 200
  * 192.168.0.3, from 192.168.0.3, 3w0d ago, via Vlan300
      Route metric is 2, traffic share count is 1
      Route tag 200

Notice that the second route is 3 weeks old.

When the user connects to the first VPN server (192.168.0.3) everything works fine, because there is ony one working route.

Output from the VPN server:

vpn-3# sh route  | i 192.168.1.222
V        192.168.1.222 255.255.255.255 connected by VPN (advertised), redundant
vpn-3# sh vpn-sessiondb anyconnect filter a-ipaddress 192.168.1.222
INFO: There are presently no active sessions of the type specified

 As you can see, the users IP is getting advertised even there is no active session with this address.

My questions:

How is this possible? Is it a big?

How can I delete this old routig entry without affecting other connected users?

I guess a reboot would solve this issue, but I would like to prevent this.

Thanks

VPN server: Cisco Adaptive Security Appliance Software Version 9.14(3)15

IP addresses are changed in this post.

[Mohammed al Baqari]

Hi,

Couple of things:

1. Check your ospf database on the central router to confirm the neighbor
that advertised this route. Keep doing this until you confirm that it's
advertised to neighbors from vpn-3 routers. This is just to confirm the
culprit
2. Check if you have any nat statement for this IP.
3. Confirm if the user IP is changing when he reconnects. This is to
identify if its IP specific problem or user specific problem
4. I don't think it's a good practice to use same vpn subnet across
different locations. This can create routing loops as you already have.
5. If the problem specific to user rather than IP, check the user vpn
settings of they are pushed through radius.

These are general suggestions. Hope they help

***** please remember to rate useful posts

[fhk-cwempe]

Hi,

1. I checked the database.

There is only one entry for this IP address and is advertised from the vpn-3.

2. We use public ip addresses. No natting.

3. The IP in question is tied to the user via RADIUS.

The user gets the same IP avery time he connects.

4. We are not using subnetzs for client VPN-IPs.

Each user gets a /32 address.

So the VPN server the user connects to can advertise a host route to itself.

There might be better solutions, but that is how we implemented it.

5. I think the problem is specific to the VPN server.

The same user (and same IP) can connect to another VPN server and the route is deleted afterwards correctly.

Thank you anyway.