Cisco ASA – Port Forward a ‘Range of Ports’
KB ID 0001111
Note: This is for Cisco ASA 5500, 5500-x, and Cisco Firepower devices running ASA Code.
This comes up on forums a lot, some applications and most phone systems require a ‘LOT’ of ports to be open. Normally thats fine you just give the internal IP a static public IP and open the ports. But what if you don’t have a spare public IP? I’ve already covered port forwarding before.
Until version 8.4 you couldn’t even do this, you needed to create a translation for each port! Note: There is a bug in versions 9.0 and 9.1 that can stop this working, so check your OS with a ‘Show Ver’ command to be sure.
As I said this come up a lot on forums so when it asked on EE the other day, I fired up GNS3 and works out how to do it. Here is my topology;
So I will setup ‘port forwarding’ from the outside interface of ASA-1 for TCP ports 1000 to 2000 to then Internal Server (10.2.2.10).
1. Setup object groups for your internal server and for the range of ports you are going to forward.
2.В Then allow the traffic in with an ACL See MY WARNING before doing this.
3. Perform the PAT translation from the outside interface to the internal server.
Note: A lot of people ask to ‘port forward’ a range of ports when they actually mean ‘I would like to open a range of ports to an internal IP address’. Thats essentially just a one-to-one static NAT. I’ve already covered that before, but in our example i use a spare public ip 192.168.253.100.
Author: PeteLong
11 Comments
Pete – How do you do port forwarding for multiple services to one inside host?
Hi Tibby – what services?
I have a requirement
I have one Internal Server 10.10.10.23 & I configured static PAT with interface. But the same server is listening on multiple Ports .in that case how to provide access for it
ERROR: NAT unable to reserve ports.
Usually seen if you have HTTPS or SSH in the list, the firewall has these reserved?
I’m on version 8.2 and unable to upgrade to a later version due to expired support contract with Cisco. to make things worse, the customer has only one usable public IP froma /30 public IP network. so there are only 2 usable and the ISP uses one for their router already as our gateway. All the Cisco docs on 8.2 state that a range cannot be used adding the Static PAT rules, and the answer is to one-to-one it to an unused IP in the public block, which we don’t have. All we have is the same IP that is used for SNAT. I seem to remember some CCIE coming in and saving the day on a similar issue several years ago on 8.2, but I can’t recall exactly what they did. any suggestions? Cisco is saying we have to map each RTP port with it’s own statement for udp 10000 – 20000..but that’s 10001 separate NAT statements! That can’t be right. We had a real UTM device in there that got zapped last week and have had to fall back onto an old ASA 5520 with cli 8.3
Cisco are correct thats how it used to be done! Your code is ten years old, you need a new firewall.
Thanks so much for this post as it really helped me resolve a problem on a 5506-x with 9.x. One question for you that got me. I originally build the nats with the port ranges like so which I found on a cisco article here: https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/118996-config-asa-00.html
nat (inside,outside) source static obj_host interface service obj_port_range obj_port_range
This was a valid nat but the outside interface didn’t seem to relay the ports as intended.
Once I created it with your example outside,inside it started working as intended. I think the thing that confused me this that when you do a NAT at the network object level it seems to work fine on a standard port map but it didn’t work this way building it as a normal nat rule.
Thank for the feedback, I’ve struggled with this myself in the past, (hence the post). I just hammered away at it until it worked!
Quick question. With respect to the command:
nat (outside,inside) source static any any destination static interface Obj-Internal-Server service Obj-Ports-Range Obj-Ports-Range
Is that applied to the “Obj-Internal-Server” or the “object service Obj-Ports-Range” object? I’m guessing the latter since the interfaces are reversed from what I normally use when applied to a host rather than a service.
Both really! so it works like, map the outside interface to obj-internal-server, but only for the ports included in obj-ports-range
ASA NAT Configuration And Recommendations For The Expressway-E Dual Network Interfaces Implementation
Available Languages
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Contents
Introduction
This document describes how to implement the Network Address Translation (NAT) configuration required in the Cisco Adaptive Security Appliance (ASA) for the Expressway-E Dual Network Interfaces implementation.
Tip: This deployment is the recommended option for Expressway-E implementation, rather than the Single-NIC implementation with NAT reflection.
Prerequisites
Requirements
Cisco recommends that you have knowledge of these topics:
Cisco ASA basic configuration and NAT configuration
Cisco Expressway-E and Expressway-C basic configuration
Components Used
The information in this document is based on these software and hardware versions:
Cisco ASA 5500 and 5500-X Series appliances that run software Version 8.0 and later.
Cisco Expressway version X8.0 and later.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Note: Through the entire document, the expressway devices are referred to as Expressway-E and Expressway-C. However, the same configuration applies for the Video Communication Server (VCS) Expressway and VCS Control devices.
Background Information
By design, Cisco Expressway-E can be placed either in a Demilitarized Zone (DMZ) or with an Internet-facing interface, while it is able to communicate with Cisco Expressway-C in a private network. When Cisco Expressway-E is placed in a DMZ, these are the additional benefits:
- In the most common scenario, Cisco Expressway-E is managed by the Private Network. When Cisco Expressway-E is in a DMZ, a perimeter (external) firewall can be used to block unwanted access to Expressway from external networks via Hypertext Transfer Protocol Secure (HTTPS) or Secure Shell (SSH) requests.
- If the DMZ doesn’t permit direct connections between internal and external networks, dedicated servers are required to handle traffic that traverses the DMZ. Cisco Expressway can act as a proxy server for Session Initiation Protocol (SIP) and/or H.323 voice and video traffic. In this case, you can use the Dual Network Interfaces option which allows Cisco Expressway to have two different IP addresses, one for traffic to/from the external firewall, and one for traffic to/from the internal firewall.
- This setup prevents direct connections from the external network to the internal network. This improves the internal network security overall.
Expressway C and E — Dual Network Interfaces/Dual NIC Implementation
This image shows an example deployment for an Expressway-E with dual network interfaces and static NAT. Expressway-C acts as the traversal client. There are two firewalls (FW A and FWB). Typically, in this DMZ configuration, FW A cannot route traffic to FW B, and devices such as the Expressway-E are required to validate and forward traffic from FW A’s subnet to FW B’s subnet (and vice versa).
This deployment consists of these components.
DMZ subnet 1 – 10.0.10.0/24
- FW A internal interface – 10.0.10.1
- Expressway-E LAN2 interface – 10.0.10.2
DMZ subnet 2 – 10.0.20.0/24
- FW B external interface – 10.0.20.1
- Expressway-E LAN1 interface – 10.0.20.2
LAN subnet – 10.0.30.0/24
- FW B internal interface – 10.0.30.1
- Expressway-C LAN1 interface – 10.0.30.2
- Cisco TelePresence Management Suite (TMS) Server network interface – 10.0.30.3
Specifics of this implementation:
- FW A is the external or perimeter firewall; it is configured with NAT IP (public IP) of 64.100.0.10 which is statically translated to 10.0.10.2 (Expressway-E LAN2 interface)
- FW B is the internal firewall
- Expressway-E LAN1 has static NAT mode disabled
- Expressway-E LAN2 has static NAT mode enabled with Static NAT address 64.100.0.10
- Expressway-C has a traversal client zone which points to 10.0.20.2 (Expressway-E LAN1 interface)
- There is no routing between 10.0.20.0/24 and 10.0.10.0/24 subnets. Expressway-E bridges these subnets and acts as a proxy for SIP/H.323 signaling and Real-time Transport Protocol (RTP) / RTP Control Protocol (RTCP) media.
- Cisco TMS has Expressway-E configured with IP address 10.0.20.2
Requirements/Limitations
Non-overlapping Subnets
If Expressway-E is configured to use both LAN interfaces, LAN1 and LAN2 interfaces must be located in non-overlapped subnets to ensure that traffic is sent out to the correct interface.
Clustering
When clustering Expressway devices with the Advanced Networking option configured, each cluster peer needs to be configured with its own LAN1 interface address. In addition, clustering must be configured on an interface that does not have Static NAT mode enabled. Therefore, it is recommended that you use LAN2 as the external interface, on which you can apply and configure static NAT where applicable.
External LAN Interface Settings
The External LAN interface configuration settings on the IP configuration page control which network interface uses Transversal Using Relays around NAT (TURN). In a dual network interface Expressway-E configuration, this is normally set to the Expressway-E external LAN interface.
Static Routes
Expressway-E must be configured with a default gateway address of 10.0.10.1 for this scenario. This means that all traffic sent out via LAN2 is, by default, sent to the IP address 10.0.10.1.
If FW B translates traffic sent from 10.0.30.0/24 subnet to the Expressway-E LAN1 interface (for example, Expressway-C traversal client traffic or TMS Server management traffic), this traffic appears as it comes from the FWB external interface (10.0.20.1) as it reaches Expressway-E LAN1. Expressway-E is then able to reply to this traffic via its LAN1 interface since the apparent source of that traffic is located on the same subnet.
If NAT is enabled on FW B, traffic sent from the Expressway-C to Expressway-E LAN1 shows as it comes from 10.0.30.2. If Expressway does not have a static route added for 10.0.30.0/24 subnet, it sends the replies for this traffic to its default gateway (10.0.10.1) out from LAN2, as it is not aware that the 10.0.30.0/24 subnet is located behind the internal firewall (FW B). Therefore, a static route needs to be added, run the xCommand RouteAdd CLI command through an SSH session to Expressway.
In this particular example, Expressway-E must know that it can reach the 10.0.30.0/24 subnet behind FW B, which is reachable via the LAN1 interface. To accomplish this, run the command:
Note: S tatic route configuration can be applied through the Expressway-E GUI as well as section System/Network > Interfaces/Static Routes.
In this example, the Interface parameter can also be set to Auto as the gateway address (10.0.20.1) is only reachable via LAN1.
If NAT is not enabled on FW B and Expressway-E needs to communicate with devices in subnets (other than 10.0.30.0/24) which are also located behind FW B, static routes must be added for these devices/subnets.
Note: This includes SSH and HTTPS connections from network management workstations or for network services like NTP, DNS, LDAP/AD, or Syslog.
The xCommand RouteAdd command and syntax are described in full detail in VCS Administrator Guide.
Configuration
This section describes how to configure the static NAT required for the Expressway-E dual network interface implementation on the ASA. Some additional ASA Modular Policy Framework (MPF) configuration recommendations are included for handling SIP/H323 traffic.
Expressway C and E — Dual Network interfaces/Dual NIC Implementation
In this example, the IP address assignment is the next one.
Expressway-C IP address: 10.0.30.2/24
Expressway-C default-gateway: 10.0.30.1 (FW-B)
Expressway-E IP addresses:
On LAN2: 10.0.10.2/24
On LAN1: 10.0.20.2/24
Expressway-E default-gateway: 10.0.10.1 (FW-A)
TMS IP address: 10.0.30.3/24
FW-A Configuration
Step 1. Static NAT Configuration for the Expressway-E.
As explained in the Background Information section of this document, the FW-A has a static NAT translation to allow Expressway-E to be reachable from the internet with public IP address 64.100.0.10. This last one is NATed to Expressway-E LAN2 IP address 10.0.10.2/24. That said, this is the required FW-A static NAT configuration.
For ASA Versions 8.3 and later:
Caution: When you apply the static PAT commands you receive this error message on the ASA command-line interface, » ERROR: NAT unable to reserve ports» . After this, proceed to clear the xlate entries on the ASA, for this, run the command clearxlatelocal x.x.x.x, from where x.x.x.x corresponds to the ASA outside IP address. This command clears all the translations associated with this IP address, run it with caution in production environments.
For ASA Versions 8.2 and earlier:
Step 2. Access Control List (ACL) configuration allows the required ports from the Internet to the Expressway-E.
According to the Unified Communication: Expressway (DMZ) to public internet documentation, the list of TCP and UDP ports that the Expressway-E requires to allow in FW-A, are as shown in the image:
This is the ACL configuration required as inbound in the FW-A outside interface.
For ASA Versions 8.3 and later:
For ASA Versions 8.2 and earlier:
FW-B Configuration
As explained in the Background Information section of this document, FW B may require a dynamic NAT or PAT configuration to allow the internal subnet 10.0.30.0/24 to be translated to the IP address 10.0.20.1 when it goes to the outside interface of the FW B.
For ASA Versions 8.3 and later:
For ASA Versions 8.2 and earlier:
Tip: Be sure that all of the required TCP and UDP ports allow the Expressway-C to work properly and are open in the FW B, just as specified in this Cisco document: Cisco Expressway IP Port Usage for Firewall Traversal
Verify
Use this section in order to confirm that your configuration works properly.
Packet Tracer can be used on the ASA to confirm that the Expressway-E static NAT translation works as required.
Packet Tracer to Test 64.100.0.10 at TCP/5222
Packet Tracer to Test 64.100.0.10 at TCP/8443
Packet Tracer to Test 64.100.0.10 at TCP/5061
Packet Tracer to Test 64.100.0.10 at UDP/24000
Packet Tracer to Test 64.100.0.10 at UDP/36002
Troubleshoot
Step 1. Compare Packet Captures.
Packet captures can be taken at both ASA ingress and egress interfaces.
Packet captures for 64.100.0.10 at TCP/5222:
Packet captures for 64.100.0.10 at TCP/5061:
Step 2. Inspect Accelerated Security Path (ASP) Drop Packet Captures.
Packet drops by an ASA are captured by the ASA ASP capture. The option all,captures all the possible reasons why the ASA dropped a packet. This can be narrowed down if there is any suspected reason. For a list of reasons an ASA uses to classify these drops, run the command show asp drop.
Tip: The ASA ASP capture is used in this scenario to confirm whether the ASA drops packets due to a missed ACL or NAT configuration, which would require to open a specific TCP or UDP port for the Expressway-E.
Tip: The default buffer size for every ASA capture is 512 KB. If too many packets are dropped by the ASA, the buffer is filled quickly. The buffer size can be increased with the buffer option.
Recommendations
Ensure that SIP/H.323 inspection is completely disabled on the firewalls involved.
It is highly recommended to disable SIP and H.323 inspection on firewalls that handle network traffic to or from an Expressway-E. When enabled, SIP/H.323 inspection is frequently found to negatively affect the Expressway built-in firewall/NAT traversal functionality.
This is an example of how to disable SIP and H.323 inspections on the ASA:
Alternative VCS Expressway Implementation
An alternative solution to implement the Expressway-E with dual network interfaces/dual NIC is to implement the Expressway-E but with a single NIC and NAT reflection configuration on the firewalls. The next link shows further details about this implementation Configure NAT Reflection on the ASA for VCS Expressway TelePresence Devices.
Tip: The recommended implementation for the VCS Expressway is the dual network interfaces/dual NIC VCS Expressway implementation described in this document.