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
- Configure necessary NAT/PAT if using NAT/PAT (Optional but usually required)
- ACL permit TCP/1723 to server/IP (whether real, mapped, or interface depends on ASA version)
- Enable PPTP inspection
- Explicit ACL permit for GRE is not necessary
If client is behind ASA
- Enable PPTP inspection
Server example
- ASA outside interface IP 1.1.1.2/30
- Server inside IP 10.0.0.10/24
- Static PAT (port forwarding) TCP/1723 using ASA outside interface IP
ASA 8.3 and newer (with focus on objects)
object network hst-10.0.0.10
description Server
host 10.0.0.10
object network hst-10.0.0.10-tcp1723
description Server TCP/1723 Static PAT Object
host 10.0.0.10
nat (inside,outside) static interface service tcp 1723 1723
object-group service svcgrp-10.0.0.10 tcp
port-object eq 1723
access-list outside_access_in extended permit tcp any object hst-10.0.0.10 object-group svcgrp-10.0.0.10-tcp
access-group outside_access_in in interface outside
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect pptp
service-policy global_policy global
ASA 8.2 and prior
access-list outside_access_in extended permit tcp any interface outside eq 1723
access-group outside_access_in in interface outside
static (inside,outside) tcp interface 1723 10.0.0.10 1723 netmask 255.255.255.255
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect pptp
service-policy global_policy global
Client example
Valid for all ASA OS versions
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect pptp
service-policy global_policy global
If these examples don't fit your scenario post your specifics and we can customize a config for you.
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
Hmm in your current setup it looks like you are going to have to double-NAT your inbound traffic if you want inbound access to work, and your VPN traffic may no longer work at all. You'd have to have the pfsense listen on the public IPs and from the public IP, you'll have to NAT on the pfsense to the 172.16.0.0 subnet that is between the pfsense and the ASA, and NAT the 172.16.0.0 subnet on the ASA to the true inside subnet of 10.0.0.0... Fairly complicated since you'll have to maintain 2 separate NAT translations and ACLs on 2 separate firewalls, but is pretty secure too. It would look like this:
I implemented something similar with a pfsense and a PIX without the double-NAT'ing a few years ago with the PIX already handling everything before I implemented the pfsense. Essentially what I did was put both the PIX (VPN, public IPs, etc...) and the pfsense on the same outside subnet that the PIX was currently hooked up to (public subnet). Then I set the clients to use the pfsense's inside IP as a gateway instead of the PIX's inside IP. All their outbound web traffic routed through the pfsense.
Then I migrated the outside IPs & NATs for inbound traffic to be handled by the pfsense instead of the PIX, switching the gateway of the NAT'ed internal server to the pfsense's inside IP as I went along. I never did get VPN working with the pfsense... but it sounds like this should accomplish your goal. The only downside (or maybe upside) was the internal clients and servers were inaccessible through the VPN on the PIX. Also this becomes more complicated if you have multiple internal subnets to route between internally.
If you are just looking to hook up to multiple ISPs for outbound web traffic, you might want to look at a Dual-WAN router instead of a full-blown firewall like the pfsense.