ASA not advertising VPN clients into OSPF

[KGrev]

Hi,

I have a cisco ASA with vpn clients attached to it. The neighboring switch it shares ospf neighborship with does not see the vpn clients advertised in ospf. If I check the asa routes through ASDM I can see subnets for the attached devices with (advertised) next to them but the next switch doesnt see them.

Is there anything I can check for the vpn's to make sure they are being advertised?

Thanks for any help.

[Rob Ingram · Accepted solution]

@KGrev redistribute statics for those VPN /32 routes. Guide with more information:

 https://integratingit.wordpress.com/2022/01/01/asa-reverse-route-injection-rri/

[KGrev]

@Rob Ingram  I'm seeing now that when I "show ip route ospf" or "show ip route", my gateway of last resort is the ip to my connected ASA. It shows

"O*E2 0.0.0.0/0 [110/1] via *ASA IP*

With this in place, is it possible that my vpn routes are being summarized into this?

I went through the guide and I do have reverse route injection enabled on my crypto maps already. If I "show route static" on the ASA I can see my vpn links as advertised.

However, on my switch if i "show ip route *vpn client ip*" it does not have a route.

*EDIT* - Sorry it does show a route now.

*Double edite* - Sorry again, it was a static route I just placed. No route if I take that out.

[Rob Ingram]

@KGrev by the sounds of it, why do you even need to advertise each VPN client IP if you have a default route via the ASA?

You have to redistribute statics on the ASA in order for the adjacent switch to receive those VPN routes, which would be loads of /32;for each connected VPN client.

[KGrev]

I suppose its just an unanswered curiosity i have. My vpn clients can ping the switch in question but can not trace to it. Monitoring the traffic in the ASA I can only see the inbound connections being made but no responses from the switch. A ping works fine. I'm probably chasing nonsense as I already put a static route in place with no change. The ACL's for the vpn's allow trace and ping.

[Rob Ingram]

@KGrev it doesn't sound like a routing issue then.

Does the access list permit ICMP unreachable and time exceeded? 

https://integratingit.wordpress.com/2018/12/15/allow-icmp-traceroute-through-cisco-asa/

[KGrev]

@Rob Ingramthanks for your help. Allowing icmp and traceroute is already enabled.

Monitoring the logs in the asa does not show any denies and does show building inbound access but there is no outbound messages.

If i debug the internal switch I can see "echo reply sent" in the logs when I ping at least.

@MHM Cisco World  thank you for your help. Currently I do not see these subnets overlapping. These are single ip loopbacks im using to trace with no nearby subnets configured in the static routes at least.

[MHM Cisco World]

ASA# capture capin interface inside match ip subnet of VPN anyconnect 

can you share this capture 

note:- disable capture after finish. 

[Rob Ingram]

@KGrev if you are not seeing /32 route (one for each connected VPN user) then you are not redistributing the static routes. On the ASA you still need to redistribute static routes for an OSPF neighbour to receive those /32 routes. Anyway the switch doesn't need to know about those /32s if the default route is via the same ASA.

What about the ACL configuration, are the VPN clients allowed to communicate with the intermediatory hops?
Do you use split-tunnel?

Take a pcap as already suggested.

[MHM Cisco World]

Many months ago' I helped one engineer with same issue' in end after we check everything we find that there is subnet conflict.

Check SW if there is aame subnet as vpn client.

If there is then SW will prefer it than defualt route toward ASA.

Thanks A Lot
MHM

[KGrev]

@Rob IngramI was able to follow the guide you submitted earlier to only redistribute the devices from the subnet I was using. In total that comes to 3 devices max so i wasn't worried about redistributing that subnet. The other subnets could get very hairy so its only this one.

And As you said it didn't really amount to much as I already had the ASA as the GW of last resort. But it was scratching a curiosity I had.

I ended up being able to finish the trace by temporarily removing "no ip unreachable" from the interface i was tracing to which you also hinted at in another post.

[MHM Cisco World]

I am lost here

You mention that there is defualt route toward asa. 

So what is issue and what is solution?

Are there any conflicts as I mention before?

[KGrev]

Sorry @MHM Cisco World  This is an issue I was troubleshooting that spreads from another issue I am troubleshooting. I wanted to know with complete certainty that my switch was indeed learning and using the correct routes but i couldn't let go of the ASA not redistributing is vpn routes and the fact that I couldn't traceroute from the vpn device to my internal switch. I was able to redistribute the vpn routes which of course changed nothing (it was just an itch needing to be scratched) then when i took off unreachables the traceroutes were successful. I think i replied to you in an earlier post that I did not see an overlapping subnets preventing me from using the right route. But thank you for reaching out to me.