I was working with a Cisco ASA customer that wished to remain with classic IPSEC IKEv1 access from Windows 8 clients (rather than SSL or Anyconnect client access). Cisco no longer make a VPN client that will load onto Windows 8 (they have no 64 bit support), so I recommended they use the Shrewsoft VPN client.
All seemed to be going well, until the customer reported an issue with some of the v2.2.2 clients whereby they could not access privately addressed hosts over the VPN connection from the Shrewsoft client but using another login account, they could.
We collectively scratched our heads over this until it was realised that if the Split-Tunnel ACL had two or more lines AND the first line gave access to a single host (rather than a subnet), then the entire ACL failed to provide any access. If the Split-Tunnel ACL listed the entries with a subnet first, then the subsequent lines could be single hosts without any issue.
So this would fail because the host entry is listed first:
access-list example_fails extended permit ip host 22.214.171.124 172.16.200.0 255.255.255.0
access-list example_fails extended permit ip 126.96.36.199 255.255.255.0 172.16.200.0 255.255.255.0
access-list example_fails extended permit ip 188.8.131.52 255.255.255.0 172.16.200.0 255.255.255.0
but reorder it and it will work:
access-list example_works extended permit ip 184.108.40.206 255.255.255.0 172.16.200.0 255.255.255.0
access-list example_works extended permit ip 220.127.116.11 255.255.255.0 172.16.200.0 255.255.255.0
access-list example_works extended permit ip host 18.104.22.168 172.16.200.0 255.255.255.0
The same ACL in the order that would not work with the Shrewsoft client (example_fails), would work with a 32 bit Cisco IPSEC VPN client, and with a native OSX VPN client. So it was a bug.