Help! Remote VPN/asa 5505 issue

Hello! I'm looking for some help - I'm banging my head against a wall with this. I'm out of ideas, its late, its Friday - everyone else I can bounce ideas off of are gone for the day.

We have a site that went from a 172.23.185.0 /25 to a full /24 - the inside interface of the ASA used to be 172.23.185.1 (/25) - it is now 172.23.186.254 255.255.255.248 .. switch connected on inside is 172.23.186.249

We have an inside route on the ASA directing all traffic from 172.23.185.0/24 to the switch, because the local IT support wants to handle the routing on their switch for now in preparing for future upgrades.

When users are VPNing in - this was their previous vpn pool:

ip local pool vpnpool 172.23.185.115-172.23.185.125 mask 255.255.255.128

When we moved this over to a /24 bit network, I was told to keep the same ip pool and just change the mask to 255.255.255.0

Now VPN users can't access anything on the 172.23.185.0/24 network (email, file shares).. any ideas?

Find more posts tagged with

SAVE $250 on Your CISCO Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View CISCO Boot Camps

Comments

Ahriakin

First up it's a very bad idea to have one pool from a subnet isolated from the main pool like this, I would advise using a different one for the VPN users. But if you still need to stick with this then your problem is most likely routing on the switches (which I presume are L3 since you mentioned that is where they are handling it). The switch/router that is directly connected to that subnet will not allow the replies back to the firewall without some playing around even if you have the intermediary routes configured correctly.
You could NAT those addresses internally, either on the ASA or on the downstream L3 Switches. This would be relatively easy to implement but you should never really do something like this as more than a stopgap measure.

If NAT is not an option (depending on the team on the other end) on their L3 devices you will need to set the Administrative Distance (or equivalent if not Cisco) of directly connected routes to higher than that of your Statics, then enter static routes (more explicit than any other route that might exist for those hosts elsewhere, essentially the tighter the mask the better, in fact it would be worth entering them all as host routes to be sure), point those statics back to your ASA inside (you could also do the same with RRI and swap the AD for connected and the routing protocol of choice but not a very good idea even if it is more dynamic). You will also need a generic subnet route for 172.23.185.0/24 on your ASA pointing back to the 'real' subnet, the host routes for your connected VPN peers on the ASA will override the generic route when needed as the more specific route (on the same AD level or lower) always wins.....

...See why it would be a lot easier to just use a new pool? If the local guys complain then point out it's extremely bad design and will be a pain to upgrade as more addresses are needed.

Knives Out wrote: »

When we moved this over to a /24 bit network, I was told to keep the same ip pool and just change the mask to 255.255.255.0

No offense but whoever told you this, if they knew you also had to change the Inside vlan/subnet on the ASA, really needs to go back to subnetting/routing class again, changing the mask alone will not make this work. The ASA will still proxy-arp for the addresses in your pool within the Inside VLAN but without the work described above traffic will never return to it for those addresses.

Knives Out

Thanks for all your info, very helpful! Basically, we're a health IT organization getting $ to pay for the health regions internet connections - they tell us how they want their network to be set up, and we try to accomodate their requests.

Ahriakin wrote: »

No offense but whoever told you this, if they knew you also had to change the Inside vlan/subnet on the ASA, really needs to go back to subnetting/routing class again, changing the mask alone will not make this work. The ASA will still proxy-arp for the addresses in your pool within the Inside VLAN but without the work described above traffic will never return to it for those addresses.

No offense taken, I thought it was kind of a wacky deal myself but wasn't confident nor familiar in the type of work the local IT guys were telling me to perform on the ASA (I've been mainly a videoconference support type for the past 10 months) - I'll have to refer to our seniors once they're back at work on Monday and get this sorted out.

Knives Out

I talked to the local IT support, was able to convince them to use a different subnet than the data subnet for their remote access vpn.

Tossed em on a 192.168.x.x /28, no sysopt connection permit-vpn, used an acl on the outside interface to allow that range of IPs into the data subnet.