Since a couple of years actually I noticed that when I use recent IOS versions on a Cisco ISR device. That there are some struggles with NAT rules in combination with a VPN client. In somecases you have to put the access-list for the NAT rule with a Permit like below.
ip access-list extended ACL_OUTSIDE_NO_NAT
permit ip 192.168.0.0 0.0.0.255 host 2.3.4.50
permit ip 192.168.0.0 0.0.0.255 10.20.54.0 0.0.0.255
permit ip 192.168.0.0 0.0.0.255 host 10.20.54.243
permit ip 192.168.0.0 0.0.0.255 host 10.20.54.6
But I don’t know why it happened, but there are IOS version which configured differently during manufacturing. So when you use a no nat rule for client vpn access and you were first able to use the configuration above and suddenly i couldn’t get any data over the vpn connection you might need to change the permit into deny.
ip access-list extended ACL_OUTSIDE_NO_NAT
deny ip 192.168.0.0 0.0.0.255 host 2.3.4.50
deny ip 192.168.0.0 0.0.0.255 10.20.54.0 0.0.0.255
deny ip 192.168.0.0 0.0.0.255 host 10.20.54.243
deny ip 192.168.0.0 0.0.0.255 host 10.20.54.6
To figure out it’s in the no nat rule you can disable the ip route policy on the internal interface to see if data is flooding. I know you don’t really need the no nat rule for client vpn for sure not if you use a VPN tunnel to another location. So the best advice is to do a trial and error test. To see if the data is flooding some way. In this case you know you have a different IOS than previously. Weird enough it happened to me with in the same IOS build schedule. in a 15-1.t version it worked with the first one and after an upgrade to 15-1.t5 it didn’t worked anymore and I had to use the second solution.