NAT is important but if you are talking about how to get the SSL VPN stuff to 'listen' on the 'external' interface:

Code:

webvpn enable external anyconnect enable

Then you need to 'self nat' to pass traffic between your VPN pool IPs and the 'inside' network (I'm assuming that is where you want to get to). Assuming your VPN pool IPs are 10.30.30.0/27 and the inside network is 10.20.20.0/24

Clients will come in from the "Outside", but have to connect to the IP of "External". Then I want them to be able to access hosts on "Inside" once connected. Right now I can't even bring up the anyconnect website on the ip address of "External"

172.31.253.11 is not routable, correct. 172.31.253.0/24 is our transit space between the ASR which handle BGP peering and the ASAs. The "External" interface was created to host the public IP space for that particular ASA.

Now I get Deny IP spoof from (my ip) to X.X.159.249 on interface outside.

Which I would expect from an RFC 1918 transit network on the outside...I'm not entirely sure how to make an exception for that on an ASA...but for now just try turning it off. You can always restrict later once you've got the basic functionality working.

The 'External' interface seems completely inappropriate to the design. How is it physically connected to the rest of the network? And what does the route table on the ASA look like at this point?

From what I can get here, the External interface should be eliminated and the Outside should be the only Outside interface. The ASA will do proxy ARP for any translated IPs so if the ASR takes care of the route information so that the world knows to reach the public IPs in question by delivering traffic to the ASA Outside interface, you are in business.

The Web VPN config goes on the outside interface and it works.

As it is now, you are delivering traffic to the Outside interface in the hopes that it will somehow end up on a totally different interface. The dynamic routing protocol may be getting it where it needs to be but it is certainly not the most efficient design and is probably the cause of the spoofing issues. I am betting traffic is getting 'spoofed' by the outside interface and delivered to the External interface, which is freaking the firewall out.

Yeah, it is fubar, and I'm working on the redesign (I came in after the firewalls were put in place). For now I was hoping to get AnyConnect going as a proof-of-concept to get some people testing it. I'd probably want to get that private transit space replaced with public IP space.

A private transit network isn't a horrible thing, it is nice to have public IPs there, especially since it is usually small but... whatever.

The problem is the interface to interface forwarding of the traffic on the ASA. It just isn't designed to do that without significant wizardry going on and doing that for all internet traffic is really bizarre. I'm not sure how you would ever go about getting VPN stuff working with that.