Cisco Expressway Basic Configuration Deployment Guide X8 1
Cisco Expressway Basic Configuration Deployment Guide X8 1
Basic Configuration
Deployment Guide
D15060.03
August 2014
Contents
Introduction 4
Example network deployment 5
Network elements 6
Internal network elements 6
DMZ network element 6
External network elements 7
NAT devices and firewalls 7
SIP and H.323 domain 7
Prerequisites and process summary 8
Prerequisites 8
Summary of process 8
Expressway system configuration 9
Task 1: Performing initial configuration 9
Task 2: Setting the system name 9
Task 3: Configuring DNS 10
System host name 10
Domain name 10
DNS servers 11
Task 4: Replacing the default server certificate 12
Task 5: Configuring NTP servers 13
Routing configuration 14
Pre-search transforms 14
Search rules 14
Task 6: Configuring transforms 14
Task 7: Configuring the traversal zone 15
Task 8: Configuring traversal zone search rules 19
Task 9: Configuring the DNS zone 22
Task 10: Configuring DNS zone search rules 23
Task 11: Configuring external (unknown) IP address routing 24
System checks 27
Zone status 27
Call signaling 27
Maintenance routine 28
Creating a system backup 28
Optional configuration tasks 29
Task 12: Configuring routes to a neighbor zone (optional) 29
Example: Cisco VCS neighbor zone 29
SIP trunks to Unified CM 30
Task 13: Configuring logging (optional) 30
Task 14: Restricting access to ISDN gateways (optional) 31
Expressway-E 31
Expressway-C 34
Appendix 1: Configuration details 36
Expressway-C configuration details 36
Introduction
Cisco Expressway is designed specifically for comprehensive collaboration services provided through Cisco
Unified Communications Manager. It features established firewall-traversal technology and helps redefine
traditional enterprise collaboration boundaries, supporting our vision of any-to-any collaboration.
This document describes how to configure an Expressway-E and an Expressway-C as the cornerstones of a
basic video infrastructure deployment.
n It takes the video network administrator through the series of tasks required to set up the Expressways and
then describes how to check that the system is working as expected.
n It provides the required DNS, NAT and firewall configuration information but assumes that the network
administrator has a working knowledge of configuring these systems.
Descriptions of system configuration parameters can be found in Expressway Administrator Guide and the
Expressway web application’s online field help and page help .
This document does not describe details of how to deploy a cluster of Expressways. For more details on
clustering, see Expressway Cluster Creation and Maintenance Deployment Guide.
To configure your Expressway system for Unified Communications services, see Unified Communications
Mobile and Remote Access via Expressway Deployment Guide.
Note that endpoints or other devices cannot register to the Expressway.
This example network includes internal and DMZ segments – in which Expressway-C and Expressway-E
platforms are respectively deployed.
Network elements
Internal network elements
The internal network elements are devices which are hosted on the organization’s local area network.
Elements on the internal network have an internal network domain name. This internal network domain name
is not resolvable by a public DNS. For example, the Expressway-C is configured with an internally resolvable
name of expc.internal-domain.net (which resolves to an IP address of 10.0.0.2 by the internal DNS servers).
Expressway-C
The Expressway-C is a SIP Proxy and communications gateway for Unified CM.
The Expressway-C is configured with a traversal client zone to communicate with the Expressway-E to
allow inbound and outbound calls to traverse the NAT device.
EX90 and EX60
These are example endpoints hosted on the internal network which register to Unified CM.
Note that endpoints or other devices cannot register to the Expressway. Registration requests will be
rejected and will be logged with 'License limit exceeded' messages.
DNS (local 1 & local 2)
DNS servers used by the Expressway-C, to perform DNS lookups (resolve network names on the internal
network).
DHCP server
The DHCP server provides host, IP gateway, DNS server, and NTP server addresses to endpoints located
on the internal network.
Router
The router device acts as the gateway for all internal network devices to route towards the DMZ (to the NAT
device internal address).
Unified CM
Endpoint devices register to Unified CM and the Expressway acts as a Unified Communications gateway for
third-party devices and to provide mobile and remote access.
To configure your Expressway system for Unified Communications services, see Unified Communications
Mobile and Remote Access via Expressway Deployment Guide.
Syslog server
A logging server for Syslog messages (see Task 13: Configuring logging (optional) [p.30]).
The Expressway-E is configured with a traversal server zone to receive communications from the
Expressway-C in order to allow inbound and outbound calls to traverse the NAT device.
The Expressway-E has a public network domain name. For example, the Expressway-E is configured with
an externally resolvable name of expe.example.com (which resolves to an IP address of 192.0.2.2 by the
external / public DNS servers).
The DNS SRV configurations are described in Appendix 2: DNS records [p.40].
Summary of process
The configuration process consists of the following tasks.
Expressway system configuration:
n Task 1: Performing initial configuration [p.9]
n Task 2: Setting the system name [p.9]
n Task 3: Configuring DNS [p.10]
n Task 4: Replacing the default server certificate [p.12]
n Task 5: Configuring NTP servers [p.13]
Routing configuration:
n Task 6: Configuring transforms [p.14]
n Task 7: Configuring the traversal zone [p.15]
n Task 8: Configuring traversal zone search rules [p.19]
n Task 9: Configuring the DNS zone [p.22]
n Task 10: Configuring DNS zone search rules [p.23]
n Task 11: Configuring external (unknown) IP address routing [p.24]
Note that Expressway requires a static IP address (it will not pick up an IP address from a DHCP server).
The initial configuration can be performed in one of three ways:
n using a serial cable
n via the front panel of the Expressway appliance
n via the default IP address of 192.168.0.100
See the “Initial configuration” section in Expressway Getting Started Guide for details.
This deployment guide is based on configuration using the web interface. If you cannot access the
Expressway using the web interface after completing the initial configuration (assigning the IP address),
speak to your network administrator.
The follow configuration values are used in the example deployment:
Expressway-C Expressway-E
Expressway-C Expressway-E
3. Click Save.
Expressway-C
Expressway-E
Expressway-C Expressway-E
3. Click Save.
Domain name
The Domain name is the name to append to an unqualified host name before querying the DNS server.
To configure the Domain name:
1. Go to System > DNS.
2. Configure the Domain name as follows:
Expressway-C Expressway-E
3. Click Save.
DNS servers
The DNS server addresses are the IP addresses of up to 5 domain name servers to use when resolving
domain names. You must specify at least one default DNS server to be queried for address resolution if you
want to either:
n use FQDNs (Fully Qualified Domain Names) instead of IP addresses when specifying external addresses
(for example for LDAP and NTP servers, neighbor zones and peers)
n use features such as URI dialing or ENUM dialing
The Expressway only queries one server at a time; if that server is not available the Expressway will try
another server from the list.
In the example deployment 2 DNS servers are configured for each Expressway, which provides a level of
DNS server redundancy. The Expressway-C is configured with DNS servers which are located on the
internal network. The Expressway-E is configured with DNS servers which are publicly routable.
To configure the Default DNS server addresses:
1. Go to System > DNS.
2. Configure the DNS server Address fields as follows:
Expressway-C Expressway-E
3. Click Save.
The Expressway allows you to install appropriate files so that it can act as either a client or a server in
connections using TLS. The Expressway can also authenticate client connections (typically from a web
browser) over HTTPS. You can also upload certificate revocation lists (CRLs) for the CAs used to verify
LDAP server and HTTPS client certificates.
The Expressway can generate server certificate signing requests (CSRs). This removes the need to use an
external mechanism to generate and obtain certificate requests.
For secure communications (HTTPS and SIP/TLS) we recommend that you replace the Expressway default
certificate with a certificate generated by a trusted certificate authority.
Note that in connections:
n to an endpoint, the Expressway acts as the TLS server
n to an LDAP server , the Expressway is a client
n between two Expressway systems, either Expressway may be the client with the other Expressway being
the TLS server
n via HTTPS, the web browser is the client and the Expressway is the server
TLS can be difficult to configure. For example, when using it with an LDAP server we recommend that you
confirm that your system is working correctly before you attempt to secure the connection with TLS. You are
also recommended to use a third party LDAP browser to verify that your LDAP server is correctly configured
to use TLS.
Note: be careful not to allow your CA certificates or CRLs to expire as this may cause certificates signed by
those CAs to be rejected.
To load the trusted CA list, go to Maintenance > Security certificates > Trusted CA certificate.
To generate a CSR and/or upload the Expressway's server certificate, go to Maintenance > Security
certificates > Server certificate.
Additional server certificate requirements apply when configuring your Expressway system for Unified
Communications. For full information, see Expressway Certificate Creation and Use Deployment Guide.
Expressway-C Expressway-E
3. Click Save.
Routing configuration
Pre-search transforms
Pre-search transform configuration allows the destination alias (called address) in an incoming search
request to be modified. The transformation is applied by the Expressway before any searches are sent to
external zones.
The pre-search transform configuration described in this document is used to standardize destination aliases
originating from both H.323 and SIP devices. This means that the same call searches will work for calls from
both H.323 and SIP endpoints.
For example, if the called address is an H.323 E.164 alias “01234”, the Expressway will automatically
append the configured domain name (in this case example.com) to the called address (that is,
[email protected] making it into a URI), before attempting to set up the call.
n Pre-search transforms should be used with care because they apply to all signaling messages – if they
match, they will affect the routing of Unified Communications messages, provisioning and presence
requests as well as call requests.
n Transformations can also be carried out in search rules – consider whether it is best to use a pre-search
transform or a search rule to modify the called address to be looked up.
Search rules
Search rules define how the Expressway routes calls (to destination zones, such as to Unified CM or to a
Cisco VCS) in specific call scenarios. When a search rule is matched, the destination alias can be modified
according to the conditions defined in the search rule.
The search rules described in this document are used to ensure that SIP (and H.323, if registered to a Cisco
VCS for example) endpoints can dial H.323 devices that have registered E.164 numbers or H.323 IDs
without a domain portion. The search rules first search for received destination aliases without the domain
portion of the URI, and then search with the full URI.
The routing configuration in this document searches for destination aliases that have valid SIP URIs (that is,
using a valid SIP domain, such as id@domain).
You can configure routing which enables calls to unregistered devices on an internal network (routing to the
addresses of IP of the devices) by configuring a search rule with a mode of Any IP address. However this is
not recommended (and not described in this document). The best practice is to register all devices and route
using destination aliases.
Expressway-C Expressway-E
Expressway-C Expressway-E
Expressway-C
Expressway-E
To configure the authentication credentials in the Local authentication database (which are configured in
the Expressway-E only):
1. Go to Configuration > Authentication > Devices > Local database.
2. Click New.
Expressway-C Expressway-E
Expressway-C Expressway-E
Rule name "Traversal zone search rule" for "Traversal zone search rule" for
example example
Description "Search traversal zone - EXPe" for "Search traversal zone - EXPc" for
example example
Priority 100 100
Protocol Any Any
Source Any Any
Request must be No No
authenticated
Mode Any alias Any alias
On successful match Continue Continue
Target Traversal zone Traversal zone
State Enabled Enabled
Expressway-C
Expressway-E
Expressway-C Expressway-E
Expressway-C Expressway-E
Rule name Not applicable Enter DNS zone search rule for example
Description Not applicable Enter Search DNS zone (external calling) for
example
Priority Not applicable 150
Note that the regular expression used to prevent local domains being searched via the DNS zone can be
broken down into the following components:
(.*) = match all pattern strings
(?!.*@%localdomains%.*$).* = do not match any pattern strings ending in @localdomains
In the deployment example, calls destined for @cisco.com would be searched via the DNS zone, whereas
calls destined for @example.com would not.
Expressway-C Expressway-E
3. Click Save.
Expressway-C
Expressway-E
Expressway-C Expressway-E
System checks
Zone status
Go to Status > Zones on both Expressway-C and Expressway-E to check that the traversal zone is Active.
You can also check the zone status via Configuration > Zones > Zones.
If the traversal zone is not active:
n Review the traversal zone configuration.
n Confirm that the relevant ports are enabled for outbound routing on the NAT and firewall devices located
between the Expressway-C and Expressway-E (see Appendix 3: Firewall and NAT settings [p.42]).
n Confirm that the username and password credentials are configured correctly (and match) on Expressway-
C and Expressway-E traversal zones and in the authentication database on the Expressway-E.
Call signaling
If calls do not complete:
n Review the Expressway-C search rule configuration.
n Review the Expressway-E search rule configuration.
n Check the search history page for search attempts and failures (Status > Search history).
n Check the Event Log for call connection failure reasons (Status > Logs > Event Log).
Maintenance routine
Creating a system backup
To create a backup of Expressway system data:
1. Go to Maintenance > Backup and restore.
2. Optionally, enter an Encryption password with which to encrypt the backup file.
If a password is specified, the same password will be required to restore the file.
3. Click Create system backup file.
4. After the backup file has been prepared, a pop-up window appears and prompts you to save the file (the
exact wording depends on your browser). The default name is in the format:
<software version>_<hardware serial number>_<date>_<time>_backup.tar.gz.
(The file extension is normally .tar.gz.enc if an encryption password is specified. However, if you use
Internet Explorer to create an encrypted backup file, the filename extension will be .tar.gz.gz by default.
These different filename extensions have no operational impact; you can create and restore encrypted
backup files using any supported browser.)
The preparation of the system backup file may take several minutes. Do not navigate away from this
page while the file is being prepared.
5. Save the file to a designated location.
Expressway-C Expressway-E
Expressway-C Expressway-E
Expressway-E external logging server configuration requires additional firewall / NAT configuration – See
Appendix 3: Firewall and NAT settings [p.42].
To configure a logging server:
1. Go to Maintenance > Logging.
2. Configure the fields as follows:
Expressway-C Expressway-E
Log level 2 2
Remote syslog server 1: Address Enter 10.0.0.13 Enter 10.0.0.13
Remote syslog server 1: Mode IETF syslog format IETF syslog format
3. Click Save.
Expressway-E
Two search rules are created on the Expressway-E:
n both search rules have a pattern string that matches calls directed at the ISDN gateway — in this example,
calls that are prefixed by a 9
n the first rule has a Source of All zones; this allows calls from neighbor zones to be passed through to the
traversal zone
n the second rule is similar to the first rule but has a Source of All; this means that non-registered endpoints
(which are excluded from the previous rule) are included by this rule and can be stopped by defining the
Replace string as "do-not-route-this-call"
n both rules stop any further search rules from being looked at (On successful match = Stop).
Expressway-E
Expressway-E
Protocol Any
Source All zones
Request must be authenticated No
Mode Alias pattern match
Pattern type Regex
Pattern string Enter (9\d+)(@example.com)
Pattern behavior Replace
Expressway-E
Expressway-E
Expressway-C
This example shows how to configure the Expressway-C to stop calls coming in via the gateway from being
able to route calls back out of the gateway. This is done by loading some specially constructed CPL onto the
Expressway-C and configuring its Call policy mode to use Local CPL.
The CPL file to be uploaded onto the Expressway can be created in a text editor.
Here are 2 example sets of CPL. In these examples the “GatewayZone” is the neighbour zone to the ISDN
gateway:
This example CPL excludes any checking of whether the calling party is authenticated or not:
This example CPL also ensures that the calling party is authenticated:
l If you receive an "XML invalid" message then you must correct the problems with the CPL file and
upload it again.
4. Select a Call policy mode of Local CPL.
5. Click Save.
System configuration
System name EXPc System > Administration
LAN1 IPv4 address 10.0.0.2 System > IP
IPv4 gateway 10.0.0.1 System > IP
LAN1 subnet mask 255.255.255.0 System > IP
DNS server address 1 10.0.0.11 System > DNS
DNS server address 2 10.0.0.12 System > DNS
DNS Domain name internal-domain.net System > DNS
DNS System host name expc System > DNS
NTP server 1 pool.ntp.org System > Time
Time zone GMT System > Time
Traversal zone
Zone Name TraversalZone Configuration > Zones > Zones
Zone Type Traversal client Configuration > Zones > Zones
Protocol SIP port 7001 Configuration > Zones > Zones
On successful match Continue Configuration > Dial plan > Search rules
Target TraversalZone Configuration > Dial plan > Search rules
Direct IP search rule
Rule name External IP address search rule Configuration > Dial plan > Search rules
Description Route external IP address Configuration > Dial plan > Search rules
Priority 100 Configuration > Dial plan > Search rules
Source Any Configuration > Dial plan > Search rules
Mode Any IP address Configuration > Dial plan > Search rules
On successful match Continue Configuration > Dial plan > Search rules
Target TraversalZone Configuration > Dial plan > Search rules
IP call routing
Calls to unknown IP Indirect Configuration > Dial plan > Configuration
addresses
System configuration
System name EXPe System > Administration
LAN1 IPv4 address 192.0.2.2 System > IP
IPv4 gateway 192.0.2.1 System > IP
LAN1 subnet mask 255.255.255.0 System > IP
DNS server address 1 194.72.6.57 System > DNS
DNS server address 2 194.73.82.242 System > DNS
On successful match Continue Configuration > Dial plan > Search rules
Target DNSZone Configuration > Dial plan > Search rules
IP call routing
Calls to unknown IP Direct Configuration > Dial plan > Configuration
addresses
Transform
Pattern string ([^@]*) Configuration > Dial plan > Transforms
Pattern type Regex Configuration > Dial plan > Transforms
Pattern type Regex Configuration > Dial plan > Search rules
Pattern string (.+)@example.com.* Configuration > Dial plan > Search rules
Pattern behavior Replace Configuration > Dial plan > Search rules
Replace string \1 Configuration > Dial plan > Search rules
On successful match Continue Configuration > Dial plan > Search rules
Target LocalZone Configuration > Dial plan > Search rules
Local search rule 2
Rule name Local zone – full URI Configuration > Dial plan > Search rules
Priority 50 Configuration > Dial plan > Search rules
Source Any Configuration > Dial plan > Search rules
Mode Alias pattern match Configuration > Dial plan > Search rules
Pattern type Regex Configuration > Dial plan > Search rules
Pattern string (.+)@example.com.* Configuration > Dial plan > Search rules
Pattern behavior Leave Configuration > Dial plan > Search rules
On successful match Continue Configuration > Dial plan > Search rules
Target LocalZone Configuration > Dial plan > Search rules
expe.example.com 192.0.2.2
If you have a cluster of Expressway-Es, you must set up DNS A and SRV records for each peer/host in the
cluster. See Expressway Cluster Creation and Maintenance Deployment Guide for more information.
expc.internal-domain.net 10.0.0.2
If you have a cluster of Expressway-Cs, you must set up DNS A and SRV records for each peer/host in the
cluster. See Expressway Cluster Creation and Maintenance Deployment Guide for more information.
* The default media port range is 36000 to 59999. The first 2 ports in the range are used for multiplexed traffic
only (with Large VM deployments the first 12 ports in the range – 36000 to 36011 – are used).
Traffic destined for logging or management server addresses (using specific destination ports) must be
routed to the internal network.
RTP & RTCP Endpoint EXPe Any >=1024 UDP 192.0.2.2 36002 to
59999
TURN server control Endpoint EXPe Any >=1024 UDP 192.0.2.2 3478 **
TURN server media Endpoint EXPe Any >=1024 UDP 192.0.2.2 24000 to
29999
** On Large VM server deployments you can configure a range of TURN request listening ports. The default
range is 3478 – 3483.
RTP & RTCP EXPe Endpoint 192.0.2.2 36000 to UDP Any >=1024
59999
TURN server EXPe Endpoint 192.0.2.2 24000 to UDP Any >=1024
media 29999
Other services (as required)
DNS EXPe DNS 192.0.2.2 >=1024 UDP DNS 53
server servers
NTP (time sync) EXPe NTP 192.0.2.2 123 UDP NTP 123
server servers
Prerequisites
Deploying an Expressway-E behind a NAT mandates the use of the Advanced Networking option key. It
enables the static NATing functionality of the Expressway-E as well as dual network interfaces. Although
certain call scenarios involving an Expressway-E behind NAT could potentially work with the help of
router/firewall-based ALGs, proper functionality cannot be guaranteed; you must use the Expressway to
perform the static NATing on its own interface. More background on this can be found in the Routers/firewalls
with SIP/H.323 ALG [p.49] section later in this appendix. The Advanced Networking option is available only
on the Expressway-E.
When deploying an Expressway-E behind a NAT with static NAT configuration in place on the Expressway-
E, it is highly recommended to disable SIP and H.323 ALGs (SIP / H.323 awareness) on routers/firewalls
carrying network traffic to or from the Expressway-E (experience shows that these tend to be unable to
handle video traffic properly).
Background
When deploying an Expressway-E for business to business communications, or for supporting home
workers and travelling workers, it is usually desirable to deploy the Expressway-E in a NATed DMZ rather
than having the Expressway-E configured with a publicly routable IP address.
Network Address Translation (NAT) poses a challenge with SIP and H.323 applications, as with these
protocols, IP addresses and port numbers are not only used in OSI layer 3 and 4 packet headers, but are also
referenced within the packet payload data of H.323 and SIP messages themselves.
This usually breaks SIP/H.323 call signaling and RTP media packet flows, since NAT routers/firewalls will
normally translate the IP addresses and port numbers of the headers, but leave the IP address and port
references within the SIP and H.323 message payloads unchanged.
To provide an example of this, assume you have an Expressway-E deployed behind a NAT router and two
endpoints. The Expressway-E has static NAT disabled on LAN2, but the NAT router is configured with a
static 1:1 NAT, NATing the public address 64.100.0.10 to the Expressway-E LAN2 IP address 10.0.10.2:
n NAT router with local IP address 10.0.10.1 and NAT IP address 64.100.0.10, statically NATed to 10.0.10.2
n Expressway-E LAN1 (internally-facing interface) with IP address 10.0.20.2
n Expressway-E LAN2 (externally-facing interface) with IP address 10.0.10.2 (and with static NAT disabled)
n Expressway-E default gateway set to 10.0.10.1 (inside address of NAT firewall, reachable via LAN2)
Assume that endpoint A places a SIP call towards endpoint B. The call will arrive at the Expressway-E,
which will proxy the SIP INVITE towards endpoint B. The Expressway-E to Endpoint B will then be a
traversal call, which means that the Expressway-E will take both signaling and media, and the packet
carrying the SIP INVITE message will have the following contents as it arrives at the NAT router (the actual
INVITE contents have been simplified for ease of reading):
Packet header:
Source IP: 10.0.10.2
Destination IP: 64.100.0.20
SIP payload:
INVITE sip: 64.100.0.20 SIP/2.0
Via: SIP/2.0/TLS 10.0.10.2:5061
Via: SIP/2.0/TLS 10.0.20.3:55938
Call-ID: [email protected]
CSeq: 100 INVITE
Contact: <sip:[email protected]:55938;transport=tls>
From: "Endpoint A" <sip:[email protected]>;tag=9a42af
To: <sip: 64.100.0.20>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 2825
v=0
o=tandberg 1 2 IN IP4 10.0.10.2
s=-
c=IN IP4 10.0.10.2
b=AS:2048
…
…
…
Figure 3: SIP INVITE arriving at NAT router
In the example above, the SDP (session description protocol) within the SIP payload contains a reference to
the Expressway-E IP address, marked in yellow: c=IN IP4 10.0.10.2.
Upon receiving the SIP INVITE packet, the NAT router will rewrite the layer 3 source IP address header
(marked in green: 10.0.10.2) and replace 10.0.10.2 (Expressway-E LAN2 IP address) with its own public
NAT address (64.100.0.10) and route the packet out to the Internet, so that the SIP INVITE message will
have the following contents as it arrives at endpoint B:
Packet header:
Source IP: 64.100.0.10
Destination IP: 64.100.0.20
SIP payload:
INVITE sip:64.100.0.20 SIP/2.0
Via: SIP/2.0/TLS 10.0.10.2:5061
Via: SIP/2.0/TLS 10.0.20.3:55938
Call-ID: [email protected]
CSeq: 100 INVITE
Contact: <sip:[email protected]:55938;transport=tls>
From: "Endpoint A" <sip:[email protected]>;tag=9a42af
To: <sip:64.100.0.20>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 2825
v=0
s=-
c=IN IP4 10.0.10.2
b=AS:2048
…
…
…
Figure 4: SIP INVITE arriving at Endpoint B
As can be seen from the example above, endpoint B will see that the SIP INVITE was received from IP
64.100.0.10 (NAT router), so the endpoint will know where to send its reply messages for the INVITE itself.
The c-line within the SDP of the SIP INVITE is however still set to c=IN IP4 10.0.10.2, which means that
endpoint B will attempt to send RTP media to the IP address 10.0.10.2, an address which is not routable on
the Internet.
The result in this scenario will therefore be that endpoint A will never receive media sent by endpoint B (while
endpoint B will normally receive media from endpoint A, since endpoint B is assigned with a publicly routable
IP address).
Similar behavior will be seen in H.323 calls, since H.323 uses the same principles as SIP in terms of
embedding IP address and port references within the message payload.
Solution
To ensure that call signaling and media connectivity remains functional in scenarios where the Expressway-
E is deployed behind a NAT (as in the example above), the Expressway-E will have to modify the parts of
SIP and H.323 messages which contain references to its actual LAN2 network interface IP address
(10.0.10.2) and replace these with the public NAT address of the NAT router (64.100.0.10).
This can be achieved by enabling Static NAT mode on selected network interfaces on the Expressway-E.
The Static NAT mode feature on the Expressway-E is made available with the Advanced Networking
option key.
This option key allows the use of two network interfaces (LAN1 and LAN2) and for Static NAT mode to be
enabled on one or both of these interfaces. It is not compulsory to use both interfaces; you may use only a
single interface and have Static NAT mode enabled on that.
When static NAT has been enabled on an interface, the Expressway will apply static NAT for all outbound
SIP and H.323 traffic for this interface, which means that H.323 and SIP devices have to communicate with
this interface using the static NAT address rather than the local interface address.
When the Advanced Networking key is installed on the Expressway-E, the IP configuration page (System
> IP) has additional options, allowing the user to decide whether to Use dual network interfaces, to
nominate which interface is the External LAN interface, to enable Static NAT mode on selected interfaces
and configure an IPv4 static NAT address for each interface.
Using the example deployment above, the Expressway-E would be configured as follows:
n Dual interfaces are selected and the external LAN interface is set to LAN2
n Configuration > IPv4 gateway is set to 10.0.10.1, the local IP address of the NAT router
n LAN1 > IPv4 address is set to 10.0.20.2
n LAN1 > IPv4 static NAT mode is set to Off
n LAN2 > IPv4 address is set to 10.0.10.2
n LAN2 > IPv4 static NAT mode is set to On
n LAN2 > IPv4 static NAT address is set to 64.100.0.10, the public NAT address of the NAT router
When enabling IPv4 static NAT mode on an interface (LAN2 in our example), the Expressway-E will modify
the payload of H.323 and SIP messages sent out via this interface, so that references to the LAN2 interface
address (10.0.10.2) are replaced with the IPv4 static NAT address configured for this interface (64.100.0.10).
This means that when looking at the payload of SIP and H.323 messages sent out via this interface, it will
appear as if the LAN2 interface has an IP address of 64.100.0.10.
It is important to note that the Expressway-E will not modify the layer 3 source address of outgoing H.323
and SIP packets sent out of this interface, as this will be done by the NAT router.
With this configuration in place, the SIP INVITE shown in Figure 4 will now look as follows as it arrives at
endpoint B:
Packet header:
Source IP: 64.100.0.10
Destination IP: 64.100.0.20
SIP payload:
INVITE sip: 64.100.0.20 SIP/2.0
v=0
s=-
c=IN IP4 64.100.0.10
b=AS:2048
…
…
…
Figure 5: SIP INVITE arriving at Endpoint B - Static NAT mode enabled
With static NAT enabled on LAN2 of the Expressway-E, the c-line of the SIP INVITE has now been rewritten
to c=IN IP4 64.100.0.10, and this means that when endpoint B sends outbound RTP media to endpoint A,
this will be sent to IP address 64.100.0.10, the public NAT address of the NAT router, which is 1:1 NATed to
the LAN2 IP address of the Expressway-E, 10.0.10.2. As RTP media from endpoint B arrives at the NAT
router with a destination IP address of 64.100.0.10, the NAT router will forward these packets to the
Expressway-E at 10.0.10.2 and two-way media is achieved.
As per the recommendations in the Introduction section of this appendix, it is highly recommended to disable
SIP and H.323 ALGs on routers/firewalls carrying network traffic to or from a Expressway-E, as, when
enabled this is frequently found to negatively affect the built-in firewall/NAT traversal functionality of the
Expressway-E itself. This is also mentioned in Appendix 3: Firewall and NAT settings [p.42].
Non-overlapping subnets
If the Expressway-E will be configured to use both LAN interfaces, the LAN1 and LAN2 interfaces must be
located in non-overlapping subnets to ensure that traffic is sent out the correct interface.
Clustering
When clustering Expressways that have the Advanced Networking option installed, cluster peers have to
be addressed with their LAN1 interface address. In addition, clustering must be configured on an interface
that does not have Static NAT mode enabled.
We therefore recommend that you use LAN2 as the externally facing interface, and that LAN2 is used as the
static NAT interface where applicable.
With this configuration the encryption B2BUA will be enabled on the Expressway-C only.
n Firewall A is the publicly-facing firewall; it is configured with a NAT IP (public IP) of 64.100.0.10 which is
statically NATed to 10.0.10.2 (the LAN2 interface address of the Expressway-E)
n Firewall B is the internally-facing firewall
n Expressway-E LAN1 has static NAT mode disabled
n Expressway-E LAN2 has static NAT mode enabled with Static NAT address 64.100.0.10
n Expressway-C has a traversal client zone pointing to 10.0.20.2 (LAN1 of the Expressway-E)
n Cisco TMS has Expressway-E added with IP address 10.0.20.2
With the above deployment, there is no regular routing between the 10.0.20.0/24 and 10.0.10.0/24 subnets.
The Expressway-E bridges these subnets and acts as a proxy for SIP/H.323 signaling and RTP /RTCP
media.
Static routes
With a deployment such as that shown in Figure 6, the Expressway-E should be configured with a default
gateway address of 10.0.10.1. This means that all traffic sent out via LAN2 will by default be sent to the IP
address 10.0.10.1.
If Firewall B is doing NAT for traffic sent from the 10.0.30.0 subnet to the LAN1 interface of the Expressway-
E (for example traversal client traffic from Expressway-C or management traffic from TMS), this means that
this traffic will appear as coming from the external interface of firewall B (10.0.20.1) as it reaches LAN1 of the
Expressway-E. The Expressway-E will therefore be able to reply to this traffic via its LAN1 interface, since
the apparent source of that traffic is located on the same subnet.
If firewall B is not doing NAT however, traffic sent from the Expressway-C to LAN1 of the Expressway-E will
appear as coming from 10.0.30.2. If the Expressway does not have a static route added for the 10.0.30.0/24
subnet, it will send replies for this traffic to its default gateway (10.0.10.1) out from LAN2, as it has not been
told that the 10.0.30.0/24 subnet is located behind the 10.0.20.1 firewall. Therefore, a static route needs to be
added, using the xCommand RouteAdd CLI command, which is run from an admin SSH shell on the
Expressway.
In this particular example, we want to tell the Expressway-E that it can reach the 10.0.30.0/24 subnet behind
the 10.0.20.1 firewall (router), which is reachable via the LAN1 interface. This is accomplished using the
following xCommand RouteAdd syntax:
xCommand RouteAdd Address: 10.0.30.0 PrefixLength: 24 Gateway: 10.0.20.1
Interface: LAN1
In this example, the Interface parameter could also be set to Auto as the gateway address (10.0.20.1) is
only reachable via LAN1.
If firewall B is not doing NAT and the Expressway-E needs to communicate with devices in subnets other
than 10.0.30.0 which are also located behind firewall B (for example for communicating with management
stations for HTTPS and SSH management or for reaching network services such as NTP, DNS, LDAP/AD
and syslog servers), static routes will also have to be added for these devices/subnets.
The xCommand RouteAdd command and syntax is described in full detail in Expressway Administrator
Guide.
Example deployments
The following section contains additional reference designs which depict other possible deployment
scenarios.
A static 1:1 NAT has been configured on firewall A, NATing the public address 64.100.0.10 to the LAN1
address of theExpressway-E. Static NAT mode has been enabled for LAN1 on the Expressway-E, with a
static NAT address of 64.100.0.10.
The traversal client zone on the Expressway-C needs to be configured with a peer address which matches
the static NAT address of the Expressway-E, in this case 64.100.0.10. This is because, since the
Expressway-E has static NAT mode enabled, it will request that incoming signaling and media traffic should
be sent to its static NAT address, which means that the traversal client zone has to be configured
accordingly.
This means that firewall A must allow traffic from the Expressway-C with a destination address of
64.100.0.10. This is also known as NAT reflection, and it should be noted that this is not supported
by all types of firewalls.
The Expressway-E should be configured with a default gateway of 10.0.10.1. Whether or not static routes are
needed in this scenario depends on the capabilities and settings of FW A and FW B. Expressway-C to
Expressway-E communications will be to the 64.100.0.10 address of the Expressway-E; the return traffic
from the Expressway-E to Expressway-C might have to go via the default gateway. If a static route is added
to the Expressway-E so that reply traffic goes from the Expressway-E and directly through FW B to the
10.0.30.0/24 subnet, this will mean that asymmetric routing will occur and this may or may not work,
depending on the firewall capabilities.
The Expressway-E can be added to Cisco TMS with the IP address 10.0.10.3 (or with IP address
64.100.0.10 if FW A allows this), since Cisco TMS management communications are not affected by static
NAT mode settings on the Expressway-E.
A static 1:1 NAT has been configured on firewall A, NATing the public address 64.100.0.10 to the LAN1
address of the Expressway-E. Static NAT mode has been enabled for LAN1 on the Expressway-E, with a
static NAT address of 64.100.0.10.
TheExpressway-E should be configured with a default gateway of 10.0.10.1. Since this gateway must be
used for all traffic leaving the Expressway-E, no static routes are needed in this type of deployment.
The traversal client zone on the Expressway-C needs to be configured with a peer address which matches
the static NAT address of the Expressway-E, in this case 64.100.0.10, for the same reasons as those
described in the previous example deployment, "Single subnet DMZ using single Expressway-E LAN
interface".
This means that firewall A must allow traffic from the Expressway-C with a destination address of
64.100.0.10. This is also known as NAT reflection, and it should be noted that this is not supported
by all types of firewalls.
The Expressway-E can be added to Cisco TMS with the IP address 10.0.10.2 (or with IP address
64.100.0.10 if FW A allows this), since Cisco TMS management communications are not affected by static
NAT mode settings on the Expressway-E.
l the software build number which can be found on the product user interface (if applicable)