Can you post the output of your log while trying to establish a vpn connection at the debugging level? (in the asdm go to Monitoring -> Logging -> set logging level to debug in the drop down -> click view)
Also unless there is a compelling reason to stay at 7.2(4) I would upgrade to the latest 8.x release. The 7.2 series had some pretty major issues.
EDIT
That error means that the interface the incoming vpn is setup on doesn't have a crypto-map applied.
if you were following the instructions there, you probably applied the crypto map like this:
crypto map outside_map interface outside
if you are testing on the same lan you would need to do this:
crypto map outside_map interface inside
Ugly i know but it'll let you test, then remove from the inside interface and you are good to go.
If that doesn't work, would you be willing put post your running config?
EDIT 2:
Ok, lets simplify this config a little. Try disconnecting the XP machine from the ASA. And also remove the 192.168.1.1 ip address and DHCP pool from the ASA. Then try to connect via the vpn.
ASA 8.3 and up pretty much forces the use of objects when configuring NAT. While this can be troubling to those who have been administering PIX/ASA for many years without using objects, over the last 6 or so months I have actually grown to like the new NAT paradigm. Static PAT -- what you will be doing to "port forward" in ports to inside and dmz hosts, does not fit quite as cleanly as I would have liked.
Some may disagree with my object naming scheme -- know that it is in use in over 100 ASA's, a few with over 1500 line configuration files -- and does wonders for keeping things straight on the CLI.
The links posted in the aforementioned answers are a great start.
I highly advise reading the ASA 8.4 CLI configuration guide NAT section first. Even if you do not understand it -- read it first to get the terms.
http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/nat_overview.html
Then follow-up with Jay Johnston's video. I found it quite helpful when I was first trying to wrap my head around things.
https://supportforums.cisco.com/docs/DOC-12324
Moving on to your question directly.
Assuming
- outside interface IP: 1.1.1.2/30
- inside interface IP: 192.168.10.1/24
dmz interface IP: 192.168.20.1/24
Dynamic PAT needed for inside and dmz subnets.
Static PAT (port forwarding) needed for particular inside and dmz hosts defined below
- inside 192.168.10.10 needs TCP/22
- dmz 192.168.20.20 needs TCP/53, TCP/80, TCP/443, and UDP/53
Define the network objects for your networks first, and configure the object NAT for dynamic PAT for both objects. Note that I am using my object naming standard. If you show run you will see the "object network ..." for each object twice. Once for the object definition and then again later on in the configuration with only nat statement.
object network net-192.168.10.0-24
description inside Network
subnet 192.168.10.0 255.255.255.0
nat (inside,outside) dynamic interface
object network net-192.168.20.0-24
description dmz Network
subnet 192.168.20.0 255.255.255.0
nat (dmz,outside) dynamic interface
Define the network objects for your hosts. This is where PAT gets a little hairy in 8.3 and up. We define an object for the host itself (to be used in the ACL to make it easy). Then we define another network object for each port that is needed. With traditional static NAT this is very easy and beautiful -- with static PAT it can get a little a little cumbersome, but is still very descriptive.
object network hst-192.168.10.10
description My inside Host
host 192.168.10.10
object network hst-192.168.10.10-tcp22
description My inside Host NAT SSH
host 192.168.10.10
nat (inside,outside) static interface service tcp 22 22
object network hst-192.168.20.20
description My dmz Host
host 192.168.20.20
object network hst-192.168.20.20-udp53
description My dmz Host DNS
host 192.168.20.20
nat (dmz,outside) static interface service udp 53 53
object network hst-192.168.20.20-tcp80
description My dmz Host HTTP
host 192.168.20.20
nat (dmz,outside) static interface service tcp 80 80
object network hst-192.168.20.20-tcp443
description My dmz Host HTTPS
host 192.168.20.20
nat (dmz,outside) static interface service tcp 443 443
Now define object-group service groups for use in ACL.
object-group service svcgrp-192.168.10.10-tcp tcp
port-object eq 22
object-group service svcgrp-192.168.20.20-udp udp
port-object eq 53
object-group service svcgrp-192.168.20.20-tcp tcp
port-object eq 80
port-object eq 443
With objects and object-groups configured, NAT configured (using network object NAT dynamic PAT and static PAT) -- all that is left is the ACL side of things.
This is where this really comes together -- especially traditional static NAT scenarios. In ASA 8.3+ UN-NAT (and NAT) happens before L3/L4/access-group ACL check -- so use real IP's in access-group ACL's -- even when bound to outside interface.
access-list outside_access_in extended permit tcp any object hst-192.168.10.10 object-group svcgrp-192.168.10.10-tcp
access-list outside_access_in extended permit udp any object hst-192.168.20.20 object-group svcgrp-192.168.20.20-udp
access-list outside_access_in extended permit tcp any object hst-192.168.20.20 object-group svcgrp-192.168.20.20-tcp
Don't forget to bind your ACL to the interface.
access-group outside_access_in in interface outside
Note that I stay away from "friendly names" in the object identifiers. Makes it a PITA when you are debugging on the CLI. I find the object names I use is very descriptive and handy in real world scenarios.
Additionally, with static NAT permitting additional ports you only have to add a port-object entry to the host's svcgrp object. With static PAT, however, you will have to add a new network object for the static PAT -- only one nat statement permitted per object -- and add the port-object to the host's svcgrp object.
A feature request has been filed with Cisco to allow multiple static PAT statements per network object. This would reduce the number of network objects needed greatly in static PAT scenarios. As of yet, it has not been added.
-Weaver
Best Answer
The stock ASA configuration does not include support for PPTP passthrough by default -- crazy as to why. Cisco TAC likely gets a handful of cases related to this...
There are at most three things required to get PPTP working through an ASA
If server is behind ASA
If client is behind ASA
Server example
ASA 8.3 and newer (with focus on objects)
ASA 8.2 and prior
Client example
Valid for all ASA OS versions
If these examples don't fit your scenario post your specifics and we can customize a config for you.