Cisco error nat unable to reserve ports

Forwarding ports on ASA5510

For the life of me I cannot seem to get this to work. I am working on a new (used) asa5510 with image 8.41 and asdm 6.41. I am trying to forward RDP to my internal server but every time I add the NAT rule, This is the error I get: nat (Outside,Outside) 2 source static any any destination static interface Netserv1 service RemoteDesktop RemoteDesktop unidirectional
NAT unable to reserve ports.

I have made this work with an ASA5505 but I seem to be stumped as to why it won’t work on this device. Here is the config:
ASA Version 8.4(1)
!
hostname netasa1
domain-name testing.com
enable password 2KFQnsdbNIdI.2KYOU encrypted
passwd 2KFQnbNdsIdI.2KYOU encrypted
names
dns-guard
!
interface Ethernet0/0
nameif Outside
security-level 0
ip address dhcp setroute
!
interface Ethernet0/1
nameif Inside
security-level 90
ip address 10.1.1.1 255.255.255.0
!
interface Ethernet0/2
shutdown
no nameif
no security-level
no ip address
!
interface Ethernet0/3
shutdown
no nameif
no security-level
no ip address
!
interface Management0/0
nameif management
security-level 100
ip address 10.1.2.1 255.255.255.0
management-only
!
boot system disk0:/asa841-k8.bin
ftp mode passive
clock timezone EST -5
clock summer-time EDT recurring
dns domain-lookup Outside
dns server-group DefaultDNS
domain-name testing.com
object network Netserv1
host 10.1.1.3
object service RemoteDesktop
service tcp source range 1 65535 destination eq 3389
object network Inside_Network
subnet 10.1.1.0 255.255.255.0
object-group service RDP tcp
description Remote Desktop Protocol
port-object eq 3389
access-list Outside_access_in remark Incoming Remote Desktop Clients
access-list Outside_access_in extended permit tcp any interface Outside object-group RDP
pager lines 24
logging enable
logging asdm informational
mtu Outside 1500
mtu Inside 1500
mtu management 1500
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-641.bin
no asdm history enable
arp timeout 14400
nat (any,Outside) source dynamic any interface
access-group Outside_access_in in interface Outside
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
dynamic-access-policy-reco rd DfltAccessPolicy
http server enable
http 10.1.2.0 255.255.255.0 management
http 10.1.1.0 255.255.255.0 Inside
no snmp-server location
no snmp-server contact
telnet timeout 5
ssh timeout 5
console timeout 0
dhcpd address 10.1.1.31-10.1.1.50 Inside
dhcpd dns 10.1.1.3 4.2.2.2 interface Inside
dhcpd lease 86400 interface Inside
dhcpd domain minettech.com interface Inside
dhcpd update dns both override interface Inside
dhcpd enable Inside
!
dhcpd address 10.1.2.2-10.1.2.254 management
!
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map global_policy
class inspection_default
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
inspect icmp
!
service-policy global_policy global
prompt hostname context
call-home
profile CiscoTAC-1
no active
destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
destination address email callhome@cisco.com
destination transport-method http
subscribe-to-alert-group diagnostic
subscribe-to-alert-group environment
subscribe-to-alert-group inventory periodic monthly
subscribe-to-alert-group configuration periodic monthly
subscribe-to-alert-group telemetry periodic daily
Cryptochecksum:6a1b318d685 1ds5a38ab9 0d28dab409 28b
: end

Any help is greatly appreciated. Thank you.

Источник

ASA Network Address Translation Configuration Troubleshooting

Available Languages

Download Options

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 troubleshoot Network Address Translation (NAT) configuration on the Cisco Adaptive Security Appliance (ASA) platform. This document is valid for ASA Version 8.3 and later.

Note: For some basic examples of NAT configurations, which include a video that shows a basic NAT configuration, see the section Related Information at the bottom of this document.

Troubleshoot NAT Configuration on the ASA

When you troubleshoot NAT configurations, it is important to understand how the NAT configuration on the ASA is used to build the NAT policy table.

These configuration mistakes account for the majority of the NAT problems encountered by ASA administrators:

• The NAT configuration rules are out of order. For example, a manual NAT rule is placed at the top of the NAT table, which causes more specific rules placed farther down the NAT table to never be hit.
• The network objects used in the NAT configuration are too broad, which causes traffic to inadvertently match these NAT rules, and miss more specific NAT rules.

The packet tracer utility can be used to diagnose most NAT-related issues on the ASA. See the next section for more information about how the NAT configuration is used to build the NAT policy table, and how to troubleshoot and resolve specific NAT problems.

Additionally, the show nat detail command can be used in order to understand which NAT rules are hit by new connections.

How the ASA Configuration is Used to Build the NAT Policy Table

All packets processed by the ASA are evaluated against the NAT table. This evaluation starts at the top (Section 1) and works down until a NAT rule is matched. Once a NAT rule is matched, that NAT rule is applied to the connection and no more NAT policies are checked against the packet.

The NAT policy on the ASA is built from the NAT configuration.

The three sections of the ASA NAT table are:

This diagram shows the different NAT sections and how they are ordered:

This example shows how the ASA’s NAT configuration with two rules (one Manual NAT statement and one Auto NAT configuration) are represented in the NAT table:

How to Troubleshoot NAT Problems

Use the Packet Tracer Utility

In order to troubleshoot problems with NAT configurations, use the packet tracer utility in order to verify that a packet hits the NAT policy. Packet tracer allows you to specify a sample packet that enters the ASA, and the ASA indicates what configuration applies to the packet and if it is permitted or not.

In the example below, a sample TCP packet that enters the inside interface and is destined to a host on the Internet is given. The packet tracer utility shows that the packet matches a dynamic NAT rule and is translated to the outside IP address of 172.16.123.4:

Choose the NAT rule and click Packet Trace in order to activate the packet tracer from the Cisco Adaptive Security Device Manager (ASDM). This uses the IP addresses specified in the NAT rule as the inputs for the packet tracer tool:

View the Output of the Show Nat Command

The output of the show nat detail command can be used in order to view the NAT policy table. Specifically, the translate_hits and untranslate_hits counters can be used in order to determine which NAT entries are used on the ASA. If you see that your new NAT rule has no translate_hits or untranslate_hits, that means that either the traffic does not arrive at the ASA, or perhaps a different rule that has a higher priority in the NAT table matches the traffic.

Here is the NAT configuration and the NAT policy table from a different ASA configuration:

In the previous example, there are six NAT rules configured on this ASA. The show nat output shows how these rules are used to build the NAT policy table, as well as the number of translate_hits and untranslate_hits for each rule. These hit counters increment only once per connection. After the connection is built through the ASA, subsequent packets that match that current connection do not increment the NAT lines (much like the way access-list hit counts work on the ASA).

Translate_hits: The number of new connections that match the NAT rule in the forward direction.

«Forward direction» means that the connection was built through the ASA in the direction of the interfaces specified in the NAT rule. If a NAT rule specified that the inside server is translated to the outside interface, the order of the interfaces in the NAT rule is «nat (inside,outside). «; if that server initiates a new connection to a host on the outside, the translate_hit counter increments.

Untranslate_hits: The number of new connections that match the NAT rule in the reverse direction.

If a NAT rule specifies that the inside server is translated to the outside interface, the order of the interfaces in the NAT rule is «nat (inside,outside). «; if a client on the outside of the ASA initiates a new connection to the server on the inside, the untranslate_hit counter increments.

Again, if you see that your new NAT rule has no translate_hits or untranslate_hits, that means that either the traffic does not arrive at the ASA, or perhaps a different rule that has a higher priority in the NAT table matches the traffic.

NAT Problem Troubleshooting Methodology

Use packet tracer in order to confirm that a sample packet matches the proper NAT configuration rule on the ASA. Use the show nat detail command in order to understand which NAT policy rules are hit. If a connection matches a different NAT configuration than expected, troubleshoot with these questions:

• Is there a different NAT rule that takes precedence over the NAT rule you intended the traffic to hit?
• Is there a different NAT rule with object definitions that are too broad (the subnet mask is too short, such as 255.0.0.0) which causes this traffic to match the wrong rule?
• Are the manual NAT policies out-of-order, which causes the packet to match the wrong rule?
• Is your NAT rule incorrectly configured, which causes the rule to not match your traffic?

See the next section for sample problems and solutions.

Common Problems with NAT Configurations

Here are some common problems experienced when you configure NAT on the ASA.

Problem: Traffic fails due to NAT Reverse Path Failure (RPF) Error: Asymmetric NAT rules matched for forward and reverse flows

The NAT RPF check ensures that a connection that is translated by the ASA in the forward direction, such as the TCP synchronize (SYN), is translated by the same NAT rule in the reverse direction, such as the TCP SYN/acknowledge (ACK).

Most commonly, this problem is caused by inbound connections destined to the local (untranslated) address in a NAT statement. At a basic level, the NAT RPF verifies that the reverse connection from the server to the client matches the same NAT rule; if it does not, the NAT RPF check fails.

When the outside host at 209.165.200.225 sends a packet destined directly to the local (untranslated) IP address of 10.2.3.2, the ASA drops the packet and logs this syslog:

Solution:

First, ensure that the host sends data to the correct global NAT address. If the host sends packets destined to the correct address, check the NAT rules that are hit by the connection. Verify that the NAT rules are correctly defined, and that the objects referenced in the NAT rules are correct. Also verify that the order of the NAT rules is appropriate.

Use the packet tracer utility in order to specify the details of the denied packet. Packet tracer should show the dropped packet due to the RPF check failure. Next, look at the output of packet tracer in order to see which NAT rules are hit in the NAT phase and the NAT-RPF phase.

If a packet matches a NAT rule in the NAT RPF-check phase, which indicates that the reverse flow would hit a NAT translation, but does not match a rule in the NAT phase, which indicates that the forward flow would NOT hit a NAT rule, the packet is dropped.

This output matches the scenario shown in the previous diagram, where the outside host incorrectly sends traffic to the local IP address of the server and not the global (translated) IP address:

When the packet is destined to the correct mapped IP address of 172.18.22.1, the packet matches the correct NAT rule in the UN-NAT phase in the forward direction, and the same rule in the NAT RPF-check phase:

Problem: Manual NAT Rules are out-of-order, which causes incorrect packet matches

The manual NAT rules are processed based on their appearance in the configuration. If a very broad NAT rule is listed first in the configuration, it might override another, more specific rule farther down in the NAT table. Use packet tracer in order to verify which NAT rule your traffic hits; it might be necessary to rearrange the manual NAT entries to a different order.

Solution:

Reorder NAT rules with ASDM.

Solution:

NAT rules can be reordered with the CLI if you remove the rule and reinsert it at a specific line number. In order to insert a new rule at a specific line, enter the line number just after the interfaces are specified.

Problem: A NAT rule is too broad and matches some traffic inadvertently

Sometimes NAT rules are created that use objects that are too broad. If these rules are placed near the top of the NAT table (at the top of Section 1, for example), they might match more traffic than intended and cause NAT rules farther down the table to never be hit.

Solution:

Use packet tracer in order to determine if your traffic matches a rule with object definitions that are too broad. If this is the case, you should reduce the scope of those objects, or move the rules farther down the NAT table, or to the after-auto section (Section 3) of the NAT table.

Problem: A NAT rule diverts traffic to an incorrect interface

NAT rules can take precedence over the routing table when they determine which interface a packet will egress the ASA. If an inbound packet matches a translated IP address in a NAT statement, the NAT rule is used in order to determine the egress interface.

The NAT divert check (which is what can override the routing table) checks to see if there is any NAT rule that specifies destination address translation for an inbound packet that arrives on an interface. If there is no rule that explicitly specifies how to translate that packet’s destination IP address, then the global routing table is consulted to determine the egress interface. If there is a rule that explicitly specifies how to translate the packets destination IP address, then the NAT rule «pulls» the packet to the other interface in the translation and the global routing table is effectively bypassed.

This problem is most often seen for inbound traffic, which arrives on the outside interface, and is usually due to out-of-order NAT rules that divert traffic to unintended interfaces.

Solutions:

This problem can be resolved with either of these actions:

• Reorder the NAT table so that the more specific entry is listed first.
• Use non-overlapping global IP address ranges for the NAT statements.

Note that if the NAT rule is an identity rule, (which means that the IP addresses are not changed by the rule) then the route-lookup keyword can be used (this keyword is not applicable to the example above since the NAT rule is not an identity rule). The route-lookup keyword causes the ASA to perform an extra check when it matches a NAT rule. It checks that the routing table of the ASA forwards the packet to the same egress interface to which this NAT configuration diverts the packet. If the routing table egress interface does not match the NAT divert interface, the NAT rule is not matched (the rule is skipped) and the packet continues down the NAT table to be processed by a later NAT rule.

The route-lookup option is only available if the NAT rule is an ‘identity’ NAT rule, which means that the IP addresses are not changed by the rule. The route-lookup option can be enabled per NAT rule if you add route-lookup to the end of the NAT line, or if you check the Lookup route table to locate egress interface check box in the NAT rule configuration in ASDM:

Problem: A NAT rule causes the ASA to Proxy Address Resolution Protocol (ARP) for traffic on the mapped interface

The ASA Proxy ARPs for the global IP address range in a NAT statement on the global interface. This Proxy ARP functionality can be disabled on a per-NAT rule basis if you add the no-proxy-arp keyword to the NAT statement.

This problem is also seen when the global address subnet is inadvertently created to be much larger than it was intended to be.

Solution:

Add the no-proxy-arp keyword to the NAT line if possible.

This can be also accomplished with ASDM. Within the NAT rule, check the Disable Proxy ARP on egress interface check box.

Источник

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.

Источник

ASA Version 8.4(4)1
!
hostname ciscoasa
enable password xxxxx encrypted
passwd xxxxx encrypted
names
!
interface Ethernet0/0
switchport access vlan 100
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
switchport access vlan 103
!
interface Ethernet0/4
!
interface Ethernet0/5
!
interface Ethernet0/6
!
interface Ethernet0/7
!
interface Vlan100
nameif outside
security-level 0
ip address dhcp
!
interface Vlan103
nameif inside
security-level 100
ip address 192.xx.xx.xx 255.255.255.0
!
ftp mode passive
dns domain-lookup outside
dns domain-lookup inside
dns server-group DefaultDNS
name-server xx.xx.xx.250
name-server xx.xx.xx.250
object network obj_any
subnet 0.0.0.0 0.0.0.0
!
object network obj_sip
host 192.xx.xx.200
!
object service objg_sip_tcp2_4050
service tcp source eq 4050
object service objg_sip_tcp2_4054
service tcp source eq 4054
!
object service objg_sip_udp2_4003
service udp source range 4003 4005
object service objg_sip_udp2_5060
service udp source eq sip
object service objg_sip_udp2_9000
service udp source range 9000 19000
!
object-group service objg_sip_tcp tcp
port-object eq 4050
port-object eq 4054
!
object-group service objg_sip_udp udp
port-object range 4003 4005
port-object eq sip
port-object range 9000 19000
!
access-list i-to-o extended permit tcp 192.xx.xx.0 255.255.255.0 any
access-list i-to-o extended permit icmp 192.xx.xx.0 255.255.255.0 any
access-list i-to-o extended permit udp 192.xx.xx.0 255.255.255.0 any
!
access-list o-to-i extended permit tcp any object obj_sip object-group objg_sip_tcp
access-list o-to-i extended permit udp any object obj_sip object-group objg_sip_udp
!
logging asdm informational
mtu outside 1500
mtu inside 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
!
nat (inside,outside) source static obj_sip interface service objg_sip_tcp2_4050 objg_sip_tcp2_4050
nat (inside,outside) source static obj_sip interface service objg_sip_tcp2_4054 objg_sip_tcp2_4054
nat (inside,outside) source static obj_sip interface service objg_sip_udp2_4003 objg_sip_udp2_4003
!
object network obj_any
nat (inside,outside) dynamic interface
!
access-group o-to-i in interface outside
access-group i-to-o in interface inside
route outside 0.0.0.0 0.0.0.0 xx.xx.xx.xx 1
!
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
dynamic-access-policy-record DfltAccessPolicy
user-identity default-domain LOCAL
aaa authentication ssh console LOCAL
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
telnet 192.xx.xx.xx 255.255.255.255 inside
telnet timeout 30
ssh timeout 5
ssh key-exchange group dh-group1-sha1
console timeout 0
!
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
username igor password xxx encrypted privilege 15
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect rsh
inspect netbios
inspect tftp
inspect icmp
!
service-policy global_policy global
prompt hostname context
no call-home reporting anonymous
Cryptochecksum:ec0d658a23cfaa327a78ca2847a57c07
: end

Ошибка: «NAT unable to reserve ports» для этих строк
nat (inside,outside) source static obj_sip interface service objg_sip_udp2_5060 objg_sip_udp2_5060
и
nat (inside,outside) source static obj_sip interface service objg_sip_udp2_9000 objg_sip_udp2_900
Но почему? порты свободны!!!