You can use a range/subnet of the inside lan subnet as your pool. This has one advantage - in that the inside lan is known in the internal routing tables of the inside network without having to forward routes to the pool via the pix inside ip. Using a part of the local LAN addresses for the pool works because the pix does proxy arp replies for the pool hosts that are active. As is sometimes the easy option if adding routing inside a more of a fiddle.
HOWEVER if you share the pool with the inside lan a number issues and risks arrise. First the "inside in access list" and "nat 0" rules can be a tricky to get right and/or read because you may want different access control for the pool vs inside hosts. And you may want different internal ACLs on internal routers for the VPN pool(s) compared with the real inside lan IPs. You may also find that internal users or net-admins "use ping" to see if inside ip is free and then - you end up overlapping the pool - Rather than looking at your well kept network reference info and the address spreedsheet that every good network engineer should maintain...
If you think about it - It is easier to read and understand your policy as controlled with acls and nat/static statements if the pool is a unique subnet/range. If the pool is unknown inside the network routing domain and the default route points to the pix then there's no proxy arp going on for the pool, and no static routes are needed. Finally any internal Audit trail (system, network, FW, IDS etc) is also effected since its more obvious that a given clients events are a VPN source if a totally different address is used.
So in summary, If your happy with the reading the config, and you can seperate the vpn users in logging, or have no specific internal audit or downstream security policy needs - feel free to "steel" ip addresses from the local lan rather than pick a seperate range. Both work.
