H.323 ALG | Junos OS - Juniper Networks

Có thể bạn quan tâm

Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Yes Maybe Later

Understanding H.323 ALG
Understanding the Avaya H.323 ALG
Example: Passing H.323 ALG Traffic to a Gatekeeper in the Private Zone
Example: Passing H.323 ALG Traffic to a Gatekeeper in the External Zone
Example: Using NAT with the H.323 ALG to Enable Incoming Calls
Example: Using NAT with the H.323 ALG to Enable Outgoing Calls
Example: Setting H.323 ALG Endpoint Registration Timeouts
Example: Setting H.323 ALG Media Source Port Ranges
Example: Configuring H.323 ALG DoS Attack Protection
Understanding H.323 ALG Known Message Types
Understanding H.323 ALG Unknown Message Types
Example: Allowing Unknown H.323 ALG Message Types

H.323 ALG

The H.323 Application Layer Gateway (ALG) consist of a suite of H.225.0 and H.245 protocols to provide audio-visual communication session on any network. The H.323 ALG provides a secure communication between terminal hosts, such as IP phones and multimedia devices.

Understanding H.323 ALG

H.323 uses the ASN.1 coding format. It sets up the dynamic links for data, video, and audio streams, following the protocols Q.931 (with port number 1720) and H.245. There are three major processes in H.323:

Gatekeeper Discovery—An endpoint finds its gatekeeper through the gatekeeper discovery process, via broadcast or unicast to a known IP and the well-known UDP port 1719. Note that Junos OS only supports unicast discovery.
Endpoint Registration, Admission, and Status—An endpoint registers to a gatekeeper and asks for its management. Before making a call, an endpoint asks its gatekeeper for permission to place the call. In both registration and admission phases, the Registration, Admission, and Status (RAS) channel is used. The Transport Service Access Point (TSAP) can utilize either the well-known UDP port (1719) or a dynamically assigned port from the discovery or registration phase and an IP address.
Call Control and Call Setup—Calls can be established within a zone or across two zones, or even across multiple zones (multipoint conference). The call setup and tear down is performed through the call signaling channel whose TSAP is the well-known TCP port (1720). The call control, including opening/closing media channels between two endpoints, is performed through the call control channel whose TSAP is dynamically assigned from the previous call signaling process. H.245 messages are used in the call control channel, and are encoded using ASN.1.
Note:
Detailed information on H.323 can be found in ITU-T Recommendation H.323.

The H.323 Application Layer Gateway (ALG) of the device lets you secure VoIP communication between terminal hosts, such as IP phones and multimedia devices. In such a telephony system, the gatekeeper device manages call registration, admission, and call status for VoIP calls. Gatekeepers can reside in the two different zones or in the same zone. (See Figure 1.)

Figure 1: H.323 ALG for VoIP Calls

Note:

The illustration uses IP phones for illustrative purposes, although it is possible to make configurations for other hosts that use VoIP, such as Microsoft NetMeeting multimedia devices.

Starting with Junos OS Release 17.4R1, the gateway-to-gateway call feature is supported on the H.323 Application Layer Gateway (ALG). This feature introduces one-to-many mapping between an H.225 control session and H.323 calls as multiple H.323 calls go through a single control session.

Starting with Junos OS Release 17.4R1, the H.323 Application Layer Gateway (ALG) supports NAT64 rules in an IPv6 network.

H.323 ALG Configuration Overview

The H.323 Application Layer Gateway (ALG) is enabled by default on the device—no action is required to enable it. However, you might choose to fine-tune H.323 ALG operations by using the following instructions:

Specify how long an endpoint registration entry remains in the Network Address Translation (NAT) table. For instructions, see Example: Setting H.323 ALG Endpoint Registration Timeouts .
Enable media traffic on a narrow or wide range of ports. For instructions, see Example: Setting H.323 ALG Media Source Port Ranges.
Protect the H.323 gatekeeper from denial-of-service (DoS) flood attacks. For instructions, see Example: Configuring H.323 ALG DoS Attack Protection.
Enable unknown messages to pass when the session is in NAT mode and route mode. For instructions, see Example: Allowing Unknown H.323 ALG Message Types.

Understanding the Avaya H.323 ALG

The H.323 standard is a legacy voice-over-IP (VoIP) protocol defined by the International Telecommunication Union (ITU-T). H.323 consists of a suite of protocols (such as H.225.0 and H.245) that are used for call signaling and call control for VoIP. The processes for configuring the H.323 standard Application Layer Gateway (ALG) and the proprietary Avaya H.323 ALG are the same.

However, Avaya H.323 ALG has some special features. To understand and configure the Avaya H.323-specific features listed here, see the Administrator Guide for Avaya Communication Manager, Avaya IP Telephony Implementation Guide, and Avaya Application Solutions IP Telephony Deployment Guide at http://support.avaya.com.

This topic contains the following sections:

Avaya H.323 ALG-Specific Features
Call Flow Details in the Avaya H.323 ALG

Avaya H.323 ALG-Specific Features

Avaya H.323-specific features are as follows:

H.323 Fast Connect
H.323 asymmetric media
Call waiting
Call forwarding
Voice mail
Call identification
Conference calling

Call Flow Details in the Avaya H.323 ALG

Connecting the Phone into the Network—Avaya performs the Q.931 Setup/Connect negotiation when the phone is wired into the network rather than when a call is being initiated.
Making a call—When a call is made, because the PBX has already stored the capabilities for each phone when the phone is connected to the network, no further Q.931 and PBX negotiations are required to set up the call. It no longer exchanges Q.931 Setup and Connect messages with the PBX. The phone and the PBX exchange H.323 Facility messages to set up the call.
Registering with a CM—When a call has been made, Avaya H.323 registers with the Avaya Communication Manager (CM). The registration process is similar to a generic H.323 standard registration process.
Note:
The direct mode and tunnel mode are not defined by Avaya H.323 ALG.

For a call to work, the CM must be deployed with Avaya Endpoints. During the call, RAS and Q.931 messages are exchanged between the CM and the Avaya Endpoints.
Note:
For Avaya H.323 with a source Network Address Translation (NAT) pool, the registration process allows only one IP address in the pool.
Setting up Real-Time Transport Protocol (RTP)/Real-Time Control Protocol (RTCP) ports—The Q.931 Setup, Facility and Information messages are used to set up RTP/RTCP ports. The hierarchy for an Avaya H.323 session is Q.931, RTP/RTCP, Parent, and then Child.
Note:
H.245 ports are not used in an Avaya call flow process.
Using Avaya H.323 counters—The counters for calls and active calls are not applicable to the Avaya H.323 ALG. The call creation and tearing down is done by Facility messages afterward. When resources are allocated for a call, all counters for calls and active calls increment. If resources are allocated for a call multiple times, messages belonging to the same call that pass the firewall multiple times will trigger multiple increments of the counters. In other words, messages that belong to the same call and pass the firewall multiple times might trigger multiple increments of the counters if the resource for a call needs to be allocated multiple times.

For example, in the two-zone case, the setup and connect message pair allocates one call resource. The active call counter is increased once. Each time the setup and connect message pair passes the firewall, a different call resource with unique interfaces and NAT is allocated. Therefore, the counter increments twice in a three-zone scenario.

Example: Passing H.323 ALG Traffic to a Gatekeeper in the Private Zone

This example shows how to set up two policies that allow H.323 traffic to pass between IP phone hosts and a gatekeeper in the private zone, and an IP phone host (2.2.2.5/32) in the public zone.

Requirements
Overview
Configuration
Verification

Requirements

Before you begin:

Understand and configure any Avaya H.323-specific features. See the Administrator Guide for Avaya Communication Manager, Avaya IP Telephony Implementation Guide, and Avaya Application Solutions IP Telephony Deployment Guide at http://support.avaya.com.
Configure security zones. See Understanding Security Zones.

Overview

This example shows how to set up two policies that allow H.323 traffic to pass between IP phone hosts and a gatekeeper in the private zone, and an IP phone host (2.2.2.5/32) in the public zone. The connection to the device can either be with or without NAT. See Figure 2.

Figure 2: H.323 Gatekeeper in the Private Zone

Configuration

Procedure

CLI Quick Configuration
Step-by-Step Procedure
Results

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

set security zones security-zone public address-book address ip_phone 2.2.2.5/32 set security zones security-zone private address-book address gateway 2.2.2.5/32 set security policies from-zone private to-zone public policy P1 match source-address any set security policies from-zone private to-zone public policy P1 match destination-address IP_Phone set security policies from-zone private to-zone public policy P1 match application junos-h323 set security policies from-zone private to-zone public policy P1 then permit set security policies from-zone public to-zone private policy P2 match source-address any set security policies from-zone public to-zone private policy P2 match destination-address gateway set security policies from-zone public to-zone private policy P2 match application junos-h323 set security policies from-zone public to-zone private policy P2 then permit

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure the device to pass H.323 ALG traffic to a gatekeeper in the private zone:

Configure two address books.
[edit] user@host# set security zones security-zone public address-book address ip_phone 2.2.2.5/32 set security zones security-zone private address-book address gateway 2.2.2.5/32
Configure policy P1 from the private zone to the public zone.
[edit] user@host# set security policies from-zone private to-zone public policy P1 match source-address any user@host# set security policies from-zone private to-zone public policy P1 match destination-address IP_Phone user@host# set security policies from-zone private to-zone public policy P1 match application junos-h323 user@host# set security policies from-zone private to-zone public policy P1 then permit
Configure policy P2 from the public zone to the private zone.
[edit] user@host# set security policies from-zone public to-zone private policy P2 match source-address any user@host# set security policies from-zone public to-zone private policy P2 match destination-address gateway user@host# set security policies from-zone public to-zone private policy P2 match application junos-h323 user@host# set security policies from-zone public to-zone private policy P2 then permit

Results

From configuration mode, confirm your configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

For brevity, this show output includes only the configuration that is relevant to this example. Any other configuration on the system has been replaced with ellipses (...).

[edit] user@host# show security policies ... from-zone trust to-zone trust { policy default-permit { match { source-address any; destination-address any; application any; } then { permit; } } } from-zone trust to-zone untrust { policy default-permit { match { source-address any; destination-address any; application any; } then { permit; } } } from-zone untrust to-zone trust { policy default-deny { match { source-address any; destination-address any; application any; } then { deny; } } } from-zone private to-zone public { policy P1 { match { source-address any; destination-address IP_Phone; application junos-h323; } then { permit; } } } from-zone public to-zone private { policy P2 { match { source-address any; destination-address gateway; application junos-h323; } then { permit; } } } ...

If you are done configuring the device, enter commit from configuration mode.

Verification

To confirm that the configuration is working properly, perform this task:

Verifying H.323 ALG Configurations

Purpose
Action

Purpose

Display information about active calls.

Note:

H.323 counters for calls and active calls in the output to this show security command do not apply to the proprietary Avaya implementation of H.323. This is because Q.931 setup and connect messages are exchanged right after the phone is powered up and call creation and tear down is done by Facility messages.

Counters for calls and active calls are increased when the resources allocated for calls are increased—that is, messages belonging to the same call and that pass the firewall multiple times increment the counters. This applies when resources for a call need to be allocated multiple times. For example, in a two-zone scenario the setup and connect message pair allocates one call resource, and the active call counter is increased by one. But in a three-zone scenario the setup and connect message pair passes the firewall twice, each time allocating different call resources. In this case, the counter is incremented.

Action

From the J-Web interface, select Monitor>ALGs>H323. Alternatively, from the CLI, enter the show security alg h323 counters command.

Counters for H.245 messages received also will not be accurate in the case of H.245 tunneling. Because H.245 messages are encapsulated in Q.931 packets, the counter for H.245 messages received will remain zero even when there are H.245 messages. The Other H245 counter will, however, reflect these packet transmissions.

[edit] user@host> show security alg h323 counters H.323 counters summary: Packets received : 0 Packets dropped : 0 RAS message received : 0 Q.931 message received : 0 H.245 message received : 0 Number of calls : 0 Number of active calls : 0 H.323 error counters: Decoding errors : 0 Message flood dropped : 0 NAT errors : 0 Resource manager errors : 0 H.323 message counters: RRQ : 0 RCF : 0 ARQ : 0 ACF : 0 URQ : 0 UCF : 0 DRQ : 0 DCF : 0 Oth RAS : 0 Setup : 0 Alert : 0 Connect : 0 CallProd : 0 Info : 0 RelCmpl : 0 Facility : 0 Empty : 0 OLC : 0 OLC-ACK : 0 Oth H245 : 0

Example: Passing H.323 ALG Traffic to a Gatekeeper in the External Zone

This example shows how to set up two policies to allow H.323 traffic to pass between IP phone hosts in the internal zone, and the IP phone at IP address 2.2.2.5/32 (and the gatekeeper) in the external zone.

Requirements
Overview
Configuration
Verification

Requirements

Before you begin:

Understand and configure any Avaya H.323-specific features. See the Administrator Guide for Avaya Communication Manager, Avaya IP Telephony Implementation Guide, and Avaya Application Solutions IP Telephony Deployment Guide at http://support.avaya.com.
Configure security zones. See Understanding Security Zones.

Overview

Because route mode does not require address mapping of any kind, a device configuration for a gatekeeper in the external, or public, zone is usually identical to the configuration for a gatekeeper in an internal, or private, zone. This example shows how to set up two policies to allow H.323 traffic to pass between IP phone hosts in the internal zone, and the IP phone at IP address 2.2.2.5/32 (and the gatekeeper) in the external zone. The device can be in transparent or route mode. See Figure 3.

Figure 3: H.323 Gatekeeper in the External Zone

Configuration

Procedure

CLI Quick Configuration
Step-by-Step Procedure
Results

CLI Quick Configuration

set security zones security-zone external address-book address IP_Phone 2.2.2.5/32 set security zones security-zone internal address-book address gatekeeper 2.2.2.10/32 set security policies from-zone internal to-zone external policy P1 match source-address any set security policies from-zone internal to-zone external policy P1 match destination-address IP_Phone set security policies from-zone internal to-zone external policy P1 match application junos-h323 set security policies from-zone internal to-zone external policy P1 then permit set security policies from-zone internal to-zone external policy P2 match source-address any set security policies from-zone internal to-zone external policy P2 match destination-address gatekeeper set security policies from-zone internal to-zone external policy P2 match application junos-h323 set security policies from-zone internal to-zone external policy P2 then permit set security policies from-zone external to-zone internal policy P3 match source-address IP_Phone set security policies from-zone external to-zone internal policy P3 match destination-address any set security policies from-zone external to-zone internal policy P3 match application junos-h323 set security policies from-zone external to-zone internal policy P3 then permit set security policies from-zone external to-zone internal policy P4 match source-address gatekeeper set security policies from-zone external to-zone internal policy P4 match destination-address any set security policies from-zone external to-zone internal policy P4 match application junos-h323 set security policies from-zone external to-zone internal policy P4 then permit

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure the device to pass H.323 ALG traffic to a gatekeeper in the external zone:

Configure two address books.
[edit] user@host# set security zones security-zone external address-book address IP_Phone 2.2.2.5/32 user@host# set security zones security-zone internal address-book address gatekeeper 2.2.2.10/32
Configure policy P1 from the internal zone to the external zone.
[edit] user@host# set security policies from-zone internal to-zone external policy P1 match source-address any user@host# set security policies from-zone internal to-zone external policy P1 match destination-address IP_Phone user@host# set security policies from-zone internal to-zone external policy P1 match application junos-h323 user@host# set security policies from-zone internal to-zone external policy P1 then permit
Configure policy P2 to allow traffic between the internal zone and the gatekeeper in the external zone.
[edit] user@host# set security policies from-zone internal to-zone external policy P2 match source-address any user@host# set security policies from-zone internal to-zone external policy P2 match destination-address gatekeeper user@host# set security policies from-zone internal to-zone external policy P2 match application junos-h323 user@host# set security policies from-zone internal to-zone external policy P2 then permit
Configure policy P3 to allow traffic between phones in the internal zone and the external zone.
[edit] user@host# set security policies from-zone external to-zone internal policy P3 match source-address IP_Phone user@host# set security policies from-zone external to-zone internal policy P3 match destination-address any user@host# set security policies from-zone external to-zone internal policy P3 match application junos-h323 user@host# set security policies from-zone external to-zone internal policy P3 then permit
Configure policy P4 to allow traffic between phones in the internal zone and the gatekeeper in the external zone.
[edit] user@host# set security policies from-zone external to-zone internal policy P4 match source-address gatekeeper user@host# set security policies from-zone external to-zone internal policy P4 match destination-address any user@host# set security policies from-zone external to-zone internal policy P4 match application junos-h323 user@host# set security policies from-zone external to-zone internal policy P4 then permit

Results

For brevity, this show output includes only the configuration that is relevant to this example. Any other configuration on the system has been replaced with ellipses (...).

[edit] user@host# show security policies ... from-zone internal to-zone external { policy P1 { match { source-address any; destination-address IP_Phone; application junos-h323; } then { permit; } } policy P2 { match { source-address any; destination-address gatekeeper; application junos-h323; } then { permit; } } } from-zone external to-zone internal { policy P3 { match { source-address IP_Phone; destination-address any; application junos-h323; } then { permit; } } policy P4 { match { source-address gatekeeper; destination-address any; application junos-h323; } then { permit; } } } ...

If you are done configuring the device, enter commit from configuration mode.

Verification

To confirm that the configuration is working properly, perform this task:

Verifying H.323 ALG Configurations

Purpose
Action

Purpose

Display information about active calls.

Note:

Action

From the J-Web interface, select Monitor>ALGs>H323. Alternatively, from the CLI, enter the show security alg h323 counters command.

Example: Using NAT with the H.323 ALG to Enable Incoming Calls

This example shows how to configure NAT with the H.323 ALG to enable calls from a public to a private network.

Requirements
Overview
Configuration
Verification

Requirements

Before you begin, understand H.323 ALGs. See Understanding H.323 ALG.

Overview

In a two-zone scenario with a server in the private zone, you can use NAT for incoming calls by configuring a NAT pool on the interface to the public zone.

In this example (see Figure 4), IP-Phone1 and a server called gatekeeper are in the private zone, and IP-Phone2 is in the public zone. You configure a static nat rule set and a source NAT pool to do NAT. You also create two policies, private-to-public and public-to-private, to permit ALG H.323 traffic from and to the private and public zones.

Topology

Figure 4 shows NAT with the H.323 ALG incoming calls.

Figure 4: NAT with the H.323 ALG—Incoming Calls

In this example, you configure source NAT as follows:

Create a static NAT rule set called gatekeeper with a rule called gatekeeper to match packets from the public zone with the destination address 172.16.1.25/32. For matching packets, the destination IP address is translated to the private address 10.1.1.25/32.
Define a source NAT pool called h323-nat-pool to contain the IP address range from 172.16.1.30/32 through 172.16.1.150/32.
Create a source NAT rule set called h323-nat with rule h323-r1 to match packets from the private zone to the public zone with the source IP address 10.1.1.0/24. For matching packets, the source address is translated to the IP address in h323-nat-pool.
Configure proxy ARP for the addresses 172.16.1.30/32 through 172.16.1.150/32 on interface ge-0/0/1.0. This allows the system to respond to ARP requests received on the interface for these addresses.

Configuration

Procedure

CLI Quick Configuration
Step-by-Step Procedure
Results

CLI Quick Configuration

set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/24 set interfaces ge-0/0/1 unit 0 family inet address 172.16.1.1/24 set security zones security-zone private address-book address IP-Phone1 10.1.1.5/32 set security zones security-zone private address-book address gatekeeper 10.1.1.25/32 set security zones security-zone private interfaces ge-0/0/0.0 set security zones security-zone public address-book address IP-Phone2 172.16.1.5/32 set security zones security-zone public interfaces ge-0/0/1.0 set security nat source pool h323-nat-pool address 172.16.1.30/32 to 172.16.1.150/32 set security nat source address-persistent set security nat source rule-set h323-nat from zone private set security nat source rule-set h323-nat to zone public set security nat source rule-set h323-nat rule h323-r1 match source-address 10.1.1.0/24 set security nat source rule-set h323-nat rule h323-r1 then source-nat pool h323-nat-pool set security nat proxy-arp interface ge-0/0/1.0 address 172.16.1.30/32 to 172.16.1.150/32 set security policies from-zone private to-zone public policy private-to-public match source-address IP-Phone1 set security policies from-zone private to-zone public policy private-to-public match source-address gatekeeper set security policies from-zone private to-zone public policy private-to-public match destination-address IP-Phone2 set security policies from-zone private to-zone public policy private-to-public match application junos-h323 set security policies from-zone private to-zone public policy private-to-public then permit set security policies from-zone public to-zone private policy public-to-private match source-address IP-Phone2 set security policies from-zone public to-zone private policy public-to-private match destination-address IP-Phone1 set security policies from-zone public to-zone private policy public-to-private match destination-address gatekeeper set security policies from-zone public to-zone private policy public-to-private match application junos-h323 set security policies from-zone public to-zone private policy public-to-private then permit

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure NAT with H.323 ALG to enable calls from a public to a private network:

Configure interfaces.
[edit] user@host# set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/24 user@host# set interfaces ge-0/0/1 unit 0 family inet address 172.16.1.1/24
Configure zones and assign addresses to them.
[edit security zones] user@host# set security-zone private interfaces ge-0/0/0.0 user@host# set security-zone private address-book address IP-Phone1 10.1.1.5/32 user@host# set security-zone private address-book address gatekeeper 10.1.1.25/32 user@host# set security-zone public interfaces ge-0/0/1.0 user@host# set security-zone public address-book address IP-Phone2 172.16.1.5/32
Create a static NAT rule set.
[edit security nat static rule-set ip-phones] user@host# set from zone public user@host# set match destination-address 172.16.1.25/32 user@host# set then static-nat prefix 10.1.1.25/32
Configure proxy ARP.
[edit security nat] user@host# set proxy-arp interface ge-0/0/1.0 address 172.16.1.25/32
Configure a source NAT rule set.
[edit security nat] set source pool h323-nat-pool address 172.16.1.30/32 to 172.16.1.150/32 set source address-persistent set source rule-set h323-nat from zone private set source rule-set h323-nat to zone public set source rule-set h323-nat rule h323-r1 match source-address 10.1.1.0/24 set source rule-set h323-nat rule h323-r1 then source-nat pool h323-nat-pool set proxy-arp interface ge-0/0/1.0 address 171.16.1.30/32 to 172.16.1.150/32
Configure policies for outgoing traffic.
[edit security policies from-zone private to-zone public policy private-to-public] user@host# set match source-address IP-Phone1 user@host# set match source-address gatekeeper user@host# set match destination-address IP-Phone2 user@host# set match application junos-h323 user@host# set then permit
Configure policies for incoming traffic.
[edit security policies from-zone public to-zone private policy public-to-private] user@host# set match source-address IP-Phone2 user@host# set match destination-address IP-Phone1 user@host# set match destination-address gatekeeper user@host# set match application junos-h323 user@host# set then permit

Results

From configuration mode, confirm your configuration by entering the show interfaces, show security zones, show security nat, and show security policies commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

[edit] user@host# show interfaces ge-0/0/0 { unit 0 { family inet { address 10.1.1.1/24; } } } ge-0/0/1 { unit 0 { family inet { address 172.16.1.1/24; } } } [edit] user@host# show security zones security-zone private { address-book { address IP-Phone1 10.1.1.5/32; address gatekeeper 10.1.1.25/32; } interfaces { ge-0/0/0.0; } } security-zone public { address-book { address IP-Phone2 172.16.1.5/32; } interfaces { ge-0/0/1.0; } } [edit] user@host# show security nat source { pool h323-nat-pool { address { 172.16.1.30/32 to 172.16.1.150/32; } } address-persistent; rule-set h323-nat { from zone private; to zone public; rule h323-r1 { match { source-address 10.1.1.0/24; } then { source-nat { pool { h323-nat-pool; } } } } } } proxy-arp { interface ge-0/0/1.0 { address { 172.16.1.30/32 to 172.16.1.150/32; } } } static { rule-set ip-phones { from zone public; rule gatekeeper { match { destination-address 172.16.1.25/32; } then { static-nat prefix 10.1.1.25/32; } } } } proxy-arp { interface ge-0/0/1.0 { address { 172.16.1.25/32; } } } [edit] user@host# show security policies from-zone private to-zone public { policy private-to-public { match { source-address [IP-Phone1 gatekeeper]; destination-address IP-Phone2; application junos-h323; } then { permit; } } } from-zone public to-zone private { policy public-to-private { match { source-address IP-Phone2; destination-address [IP-Phone1 gatekeeper]; application junos-h323; } then { permit; } } }

If you are done configuring the device, enter commit from configuration mode.

Verification

To confirm that the configuration is working properly, perform these tasks:

Verifying H.323 ALG Status
Verifying Security ALG H.323 Counters
Verifying Source NAT Rule Usage

Verifying H.323 ALG Status

Purpose
Action
Meaning

Purpose

Verify that H.323 ALG is enabled on your system.

Action

From operational mode, enter the show security alg status command.

user@host> show security alg status ALG Status : DNS : Enabled FTP : Enabled H323 : Enabled MGCP : Enabled MSRPC : Enabled PPTP : Enabled RSH : Disabled RTSP : Enabled SCCP : Enabled SIP : Enabled SQL : Enabled SUNRPC : Enabled TALK : Enabled TFTP : Enabled IKE-ESP : Disabled

Meaning

The output shows the H323 ALG status as follows:

Enabled—Shows the H323 ALG is enabled.
Disabled—Shows the H323 ALG is disabled.

Verifying Security ALG H.323 Counters

Purpose
Action
Meaning

Purpose

Verify that there is a security counters for ALG H323.

Action

From operational mode, enter the show security alg h323 counters command.

user@host> show security alg h323 counters H.323 counters summary: Packets received :4060 Packets dropped :24 RAS message received :3690 Q.931 message received :202 H.245 message received :145 Number of calls :25 Number of active calls :0 H.323 Error Counters: Decoding errors :24 Message flood dropped :0 NAT errors :0 Resource manager errors :0 H.323 Message Counters: RRQ : 431 RCF : 49 ARQ : 60 ACF : 33 URQ : 34 UCF : 25 DRQ : 55 DCF : 44 oth RAS : 2942 Setup : 28 Alert : 9 Connect : 25 CallPrcd : 18 Info : 0 RelCmpl : 39 Facility : 14 Progress : 0 Empty : 65 OLC : 20 OLC-ACK : 20

Meaning

The sample output gives the rundown of security ALG H.323 counters expressing that, there are security counters for ALG H323.

Verifying Source NAT Rule Usage

Purpose
Action
Meaning

Purpose

Verify that there is traffic matching the source NAT rule.

Action

From operational mode, enter the show security nat source rule all command. View the Translation hits field to check for traffic that matches the rule.

user@host> show security nat source rule all source NAT rule: h323-r1 Rule-set: h323-nat Rule-Id : 1 Rule position : 1 From zone : private To zone : public Match Source addresses : 0.0.0.0 - 255.255.255.255 Destination port : 0 - 0 Action : interface Persistent NAT type : N/A Persistent NAT mapping type : address-port-mapping Inactivity timeout : 0 Max session number : 0 Translation hits : 0 Successful sessions : 0 Failed sessions : 0 Number of sessions : 0

Meaning

The Translation hits field shows that, there is no traffic matching the source NAT rule.

Example: Using NAT with the H.323 ALG to Enable Outgoing Calls

This example shows how to configure static NAT with H.323 ALG to enable calls from a private to a public network.

Requirements
Overview
Configuration
Verification

Requirements

Before you begin, understand the H.323 ALG and its processes. See Understanding H.323 ALG.

Overview

In this example (see Figure 5), IP-Phone 1 and a server called gatekeeper are in the private zone and IP-Phone2 is in the public zone. You configure static NAT to enable IP-Phone1 and gatekeeper to call IP-Phone2 in the public zone. You then create a policy called public-to-private to allow ALG H.323 traffic from the public zone to the private zone and a policy called private-to-public to allow ALG H.323 traffic from the private zone to the public zone.

Topology

Figure 5 shows NAT with the H.323 ALG outgoing calls.

Figure 5: NAT with the H.323 ALG—Outgoing Calls

In this example, you configure static NAT as follows:

Create a static NAT rule set called ip-phones with a rule called phone1 to match packets from the public zone with the destination address 172.16.1.5/32. For matching packets, the destination IP address is translated to the private address 10.1.1.5/32.
Define a second rule called gatekeeper to match packets from the public zone with the destination address 172.16.1.25/32. For matching packets, the destination IP address is translated to the private address 10.1.1.25/32.
Create proxy ARP for the addresses 172.16.1.5/32 and 172.16.1.25/32 on interface ge-0/0/1. This allows the system to respond to ARP requests received on the specified interface for these addresses.

Configuration

Procedure

CLI Quick Configuration
Step-by-Step Procedure
Results

CLI Quick Configuration

set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/24 set interfaces ge-0/0/1 unit 0 family inet address 172.16.1.1/24 set security zones security-zone private address-book address IP-Phone1 10.1.1.5/32 set security zones security-zone private address-book address gatekeeper 10.1.1.25/32 set security zones security-zone private interfaces ge-0/0/0.0 set security zones security-zone public address-book address IP-Phone2 172.16.1.5/32 set security zones security-zone public interfaces ge-0/0/1.0 set security nat static rule-set ip-phones from zone public set security nat static rule-set ip-phones rule phone1 match destination-address 172.16.1.5/32 set security nat static rule-set ip-phones rule phone1 then static-nat prefix 10.1.1.5/32 set security nat static rule-set ip-phones rule gatekeeper match destination-address 172.16.1.25/32 set security nat static rule-set ip-phones rule gatekeeper then static-nat prefix 10.1.1.25/32 set security nat proxy-arp interface ge-0/0/1.0 address 172.16.1.5/32 set security nat proxy-arp interface ge-0/0/1.0 address 172.16.1.25/32 set security policies from-zone public to-zone private policy public-to-private match source-address IP-Phone2 set security policies from-zone public to-zone private policy public-to-private match destination-address gatekeeper set security policies from-zone public to-zone private policy public-to-private match application junos-h323 set security policies from-zone public to-zone private policy public-to-private then permit set security policies from-zone private to-zone public policy private-to-public match source-address IP-Phone1 set security policies from-zone private to-zone public policy private-to-public match source-address gatekeeper set security policies from-zone private to-zone public policy private-to-public match destination-address IP-Phone2 set security policies from-zone private to-zone public policy private-to-public match application junos-h323 set security policies from-zone private to-zone public policy private-to-public then permit

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure static NAT with the H.323 ALG to enable calls from a private to a public network:

Configure interfaces.
user@host# set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/24 user@host# set interfaces ge-0/0/1 unit 0 family inet address 172.16.1.1/24
Create zones and assign addresses to them.
[edit security zones] user@host# set security-zone private interfaces ge-0/0/0.0 user@host# set security-zone public interfaces ge-0/0/1.0 user@host# set security-zone private interfaces ge-0/0/0.0 user@host# set security-zone private address-book address IP-Phone1 10.1.1.5/32 user@host# set security-zone private address-book address gatekeeper 10.1.1.25/32 user@host# set security-zone public interfaces ge-0/0/1.0 user@host# set security-zone public address-book address IP-Phone2 172.16.1.5/32
Configure static NAT rule set with rules.
[edit security nat static rule-set ip-phones] user@host# set from zone public user@host# set rule phone1 match destination-address 172.16.1.5/32 user@host# set rule phone1 then static-nat prefix 10.1.1.5/32 user@host# set rule gatekeeper match destination-address 172.16.1.25/32 user@host# set rule gatekeeper then static-nat prefix 10.1.1.25/32
Configure proxy ARP.
[edit security nat] user@host# set proxy-arp interface ge-0/0/1 address 172.16.1.5/32 user@host# set proxy-arp interface ge-0/0/1 address 172.16.1.25/32
Configure a security policy for incoming traffic.
[edit security policies from-zone public to-zone private policy public-to-private] user@host# set match source-address IP-Phone2 user@host# set match destination-address gatekeeper user@host# set match application junos-h323 user@host# set then permit
Configure a security policy for outgoing traffic.
[edit security policies from-zone private to-zone public policy private-to-public] user@host# set match source-address IP-Phone1 user@host# set match source-address gatekeeper user@host# set match destination-address IP-Phone2 user@host# set match application junos-h323 user@host# set then permit

Results

[edit] user@host# show interfaces ge-0/0/0 { unit 0 { family inet { address 10.1.1.1/24; } } } ge-0/0/1 { unit 0 { family inet { address 172.16.1.1/24; } } } [edit] user@host# show security zones security-zone private { address-book { address IP-Phone1 10.1.1.5/32; address gatekeeper 10.1.1.25/32; } interfaces { ge-0/0/0.0; } } security-zone public { address-book { address IP-Phone2 172.16.1.5/32; } interfaces { ge-0/0/1.0; } } [edit] user@host# show security nat static { rule-set ip-phones { from zone public; rule phone1 { match { destination-address 172.16.1.5/32; } then { static-nat prefix 10.1.1.5/32; } } rule gatekeeper { match { destination-address 172.16.1.25/32; } then { static-nat prefix 10.1.1.25/32; } } } } proxy-arp { interface ge-0/0/1.0 { address { 172.16.1.5/32; 172.16.1.25/32; } } } [edit] user@host# show security policies from-zone public to-zone private { policy public-to-private { match { source-address IP-Phone2; destination-address gatekeeper; application junos-h323; } then { permit; } } } from-zone private to-zone public { policy private-to-public { match { source-address [ IP-Phone1 gatekeeper ]; destination-address IP-Phone2; application junos-h323; } then { permit; } } }

If you are done configuring the device, enter commit from configuration mode.

Verification

To confirm that the configuration is working properly, perform these tasks:

Verifying H.323 ALG Status
Verifying Security ALG H.323 Counters

Verifying H.323 ALG Status

Purpose
Action
Meaning

Purpose

Verify that H.323 ALG is enabled on your system.

Action

From operational mode, enter the show security alg status command.

user@host> show security alg status ALG Status : DNS : Enabled FTP : Enabled H323 : Enabled MGCP : Enabled MSRPC : Enabled PPTP : Enabled RSH : Enabled RTSP : Enabled SCCP : Enabled SIP : Enabled SQL : Enabled SUNRPC : Enabled TALK : Enabled TFTP : Enabled IKE-ESP : Disabled

Meaning

The output shows the H323 ALG status as follows:

Enabled—Shows the H323 ALG is enabled.
Disabled—Shows the H323 ALG is disabled.

Verifying Security ALG H.323 Counters

Purpose
Action
Meaning

Purpose

Verify that there is a security counters for ALG H323.

Action

From operational mode, enter the show security alg h323 counters command.

user@host> show security alg h323 counters H.323 counters summary: Packets received :4060 Packets dropped :24 RAS message received :3690Q.931 message received :202 H.245 message received :145 Number of calls :25 Number of active calls :0 H.323 Error Counters: Decoding errors :24 Message flood dropped :0 NAT errors :0 Resource manager errors :0 H.323 Message Counters: RRQ : 431 RCF : 49 ARQ : 60 ACF : 33 URQ : 34 UCF : 25 DRQ : 55 DCF : 44 oth RAS : 2942 Setup : 28 Alert : 9 Connect : 25 CallPrcd : 18 Info : 0 RelCmpl : 39 Facility : 14 Progress : 0 Empty : 65 OLC : 20 OLC-ACK : 20

Meaning

The sample output gives the synopsis of security ALG H.323 counters expressing that there are security counters for ALG H.323.

Example: Setting H.323 ALG Endpoint Registration Timeouts

This example shows how to specify the endpoint registration timeout.

Requirements
Overview
Configuration
Verification

Requirements

Before you begin, understand and configure any Avaya H.323-specific features. See the Administrator Guide for Avaya Communication Manager, Avaya IP Telephony Implementation Guide, and Avaya Application Solutions IP Telephony Deployment Guide at http://support.avaya.com.

Overview

In Network Address Translation (NAT) mode, when endpoints in the protected network behind the Juniper Networks device register with the H.323 gatekeeper, the device adds an entry to the NAT table containing a mapping of the public-to-private address for each endpoint. These entries make it possible for endpoints in the protected network to receive incoming calls.

You set an endpoint registration timeout to specify how long an endpoint registration entry remains in the NAT table. To ensure uninterrupted incoming call service, set the endpoint registration timeout to a value equal to or greater than the keepalive value the administrator configures on the gatekeeper. The range is 10 to 50,000 seconds, the default value is 3600 seconds.

Configuration

Procedure

GUI Quick Configuration
Step-by-Step Procedure

GUI Quick Configuration

Step-by-Step Procedure

To specify the H.323 ALG endpoint registration timeout:

Select Configure>Security>ALG.
Select the H323 tab.
In the Timeout for endpoints box, type 5000.
Click OK to check your configuration and save it as a candidate configuration.
If you are done configuring the device, click Commit Options>Commit.

Step-by-Step Procedure

If you are done configuring the device, commit the configuration.
[edit] user@host# commit

Verification

To verify the configuration is working properly, enter the show security alg h323 counters command.

Example: Setting H.323 ALG Media Source Port Ranges

This example shows how to enable the H.323 ALG media source port feature.

Requirements
Overview
Configuration
Verification

Requirements

Overview

The media source port feature enables you to configure the device to allow media traffic on a narrow or wide range of ports. By default, the device listens for H.323 traffic on a narrow range of ports. If your endpoint equipment allows you to specify a sending port and a listening port, you might want to narrow the range of ports the device allows media traffic on. This enhances security by opening a smaller pinhole for H.323 traffic. This example shows how to configure the device to open a wide gate for media traffic by enabling the media source port feature.

Configuration

Procedure

GUI Quick Configuration
Step-by-Step Procedure

GUI Quick Configuration

Step-by-Step Procedure

To enable the H.323 ALG media source port feature:

Select Configure>Security>ALG.
Select the H323 tab.
Select the Enable Permit media from any source port check box.
Click OK to check your configuration and save it as a candidate configuration.
If you are done configuring the device, click Commit Options>Commit.

Step-by-Step Procedure

To enable the H.323 ALG media source port feature:

Set a narrow gate for media traffic by disabling the media source port for the H.323 ALG.
[edit] user@host# delete security alg h323 media-source-port-any
If you are done configuring the device, commit the configuration.
[edit] user@host# commit

Verification

To verify the configuration is working properly, enter the show security alg h323 counters command.

Example: Configuring H.323 ALG DoS Attack Protection

This example shows how to configure the H.323 ALG DoS attack protection feature.

Requirements
Overview
Configuration
Verification

Requirements

Overview

You can protect the H.323 gatekeeper from denial-of-service (DoS) flood attacks by limiting the number of Registration, Admission, and Status (RAS) messages per second it will attempt to process. Incoming RAS request messages exceeding the threshold you specify are dropped by H.323 Application Layer Gateway (ALG). The range is 2 to 50,000 messages per second, the default value is 1000.

Configuration

Procedure

GUI Quick Configuration
Step-by-Step Procedure

GUI Quick Configuration

Step-by-Step Procedure

To configure the H.323 ALG DoS attack protection feature:

Select Configure>Security>ALG.
Select the H323 tab.
In the Message flood gatekeeper threshold box, type 5000.
Click OK to check your configuration and save it as a candidate configuration.
If you are done configuring the device, click Commit Options>Commit.

Step-by-Step Procedure

To configure the H.323 ALG DoS attack protection feature:

Configure the gatekeeper for the H.323 ALG and set the threshold.
[edit] user@host# set security alg h323 application-screen message-flood gatekeeper threshold 5000
If you are done configuring the device, commit the configuration.
[edit] user@host# commit

Verification

To verify the configuration is working properly, enter the show security alg h323 counters command.

Understanding H.323 ALG Known Message Types

Gatekeeper Discovery—An endpoint finds its gatekeeper through the gatekeeper discovery process, through broadcast or unicast (to a known IP and the well-known UDP port 1719).
Endpoint Registration, Admission, and Status—An endpoint registers to a gatekeeper and asks for its management. Before making a call, an endpoint asks its gatekeeper for permission to place the call. In both registration and admission phases, the Registration, Admission, and Status (RAS) channel is used.
Call Control and Call Setup—Calls can be established within a zone or across two zones, or even across multiple zones (multipoint conference). The call setup and tear down is performed through the call signaling channel whose TSAP is the well-known TCP port (1720). The call control, including opening/closing media channels between two endpoints, is performed through the call control channel whose TSAP is dynamically assigned from the previous call signaling process. H.245 messages are used in the call control channel, and are encoded using ASN.1.

H.225 RAS Signaling: Gatekeepers and Gateways
H.225 Call Signaling (Q.931)
H.245 Media Control and Transport signaling

H.225 RAS Signaling: Gatekeepers and Gateways

Registration, Admission, and Status (RAS), as described in the (ITU-T) H.323 standard, is the signaling protocol used between gateways or endpoints. The gatekeepers provide address resolution and admission control services.

RAS is the process by which H.323 gateways discover their zone gatekeepers. RAS communication is carried out through a UDP datagram on port 1718 (multicast) and 1719 (unicast). Endpoints use the RAS protocol to communicate with a gatekeeper. If an H.323 endpoint does not know its gatekeeper, then it can send a Gatekeeper Request (GRQ) message to seek the gatekeeper’s response. One or more gatekeepers might answer the request with either a Gatekeeper Confirmation (GCF) message or a Gatekeeper Reject (GRJ) message. A reject message contains the reason for rejection.

Table 1 lists the supported RAS gatekeeper messages.

Table 1: Gatekeeper Messages

Message	Description
GRQ (Gatekeeper_Request)	A message sent from an endpoint to a gatekeeper to "discover" gatekeepers willing to provide service.
GCF (Gatekeeper_Confirm)	A reply from a gatekeeper to an endpoint that indicates the acceptance to communicate with the gatekeeper’s RAS channel.
GRJ (Gatekeeper_Reject)	A reply from a gatekeeper to an endpoint that rejects the endpoint request.

RAS Registration and Unregistration
RAS Admissions
RAS Location
RAS Bandwidth Control
RAS Status Information
RAS Disengage Information

RAS Registration and Unregistration

Registration is the process by which the gateways, terminals, and multipoint control units (MCUs) join a zone and inform the gatekeeper of their IP and alias addresses. Every gateway can register only one active gatekeeper.

The registration takes place after the endpoint determines and confirms the gatekeeper to communicate, by sending a Registration Request (RRQ) message. The gatekeeper then responds with a Registration Confirm (RCF) message, thereby making the endpoint known to the network.

Table 2 lists the supported RAS registration and unregistration messages.

Table 2: Registration and Unregistration Messages

Message	Description
RRQ (Registration_Request)	A message sent from an endpoint to a gatekeeper. Registration requests are predefined in the system’s administrative setup.
RCF (Registration_Confirm)	A reply from a gatekeeper that confirms an endpoint’s registration in response to an RRQ message.
RRJ (Registration_Reject)	A reply from a gatekeeper that rejects an endpoint’s registration.
URQ (Unregister_Request)	A message sent from an endpoint or a gatekeeper requesting to cancel a registration.
UCF (Unregister_Confirm)	A reply sent from an endpoint or a gatekeeper to confirm that the registration is canceled.
URJ (Unregister_Reject)	A message that indicates that the endpoint is not preregistered with the gatekeeper.

RAS Admissions

Admission messages between endpoints and gatekeepers provide the basis for call admissions and bandwidth control. The gatekeeper then resolves the address either with confirmation or rejection of an admission request.

Table 3 lists the supported RAS admission messages.

Table 3: Call Admission Messages

Message	Description
ARQ (Admission_Request)	An attempt by an endpoint to initiate a call.
ACF (Admission_Confirm)	A positive response from a gatekeeper that authorizes an endpoint to participate in a call.
ARJ (Admission_Reject)	A message sent from a gatekeeper rejecting the ARQ message that initiates a call.

RAS Location

Location Request (LRQ) messages are sent by either an endpoint or a gatekeeper to an interzone gatekeeper to get the IP addresses of different zone endpoints.

Table 4 lists the supported RAS location request messages.

Table 4: Location Request Messages

Message	Description
LRQ (Location_Request)	A message sent to request a gatekeeper for contact information of one or more addresses.
LCF (Location_Confirm)	A response sent by a gatekeeper that contains call signaling channel or RAS channel addresses.
LRJ (Location_Reject)	A response sent by gatekeepers that received an LRQ for which the requested endpoint is not registered.

RAS Bandwidth Control

Bandwidth control is invoked to set up the call, and is initially managed through the admission messages (ARQ/ACF/ARJ) sequence.

Table 5 lists the supported RAS bandwidth control messages.

Table 5: Bandwidth Control Messages

Message	Description
BRQ (Bandwidth_Request)	A request sent by an endpoint to a gatekeeper to increase or decrease call bandwidth.
BCF (Bandwidth_Confirm)	A response sent by a gatekeeper to confirm the acceptance of a bandwidth change request.
BRJ (Bandwidth_Reject)	A response sent by a gatekeeper to reject a bandwidth change request.

RAS Status Information

A gatekeeper uses an Information Request (IRQ) message to determine the status of an endpoint. The RAS protocol is used to determine whether the endpoints are online or offline.

Table 6 lists the supported RAS status information messages.

Table 6: Status Information Messages

Message	Description
IRQ (Information_Request)	A message sent from a gatekeeper to request status information of its recipient endpoints.
IRR (Information_Request_Response)	A response sent by endpoint to a gatekeeper in response to an IRQ message. It determines whether the endpoints are online or offline.
IACK (Info_Request_Acknowledge)	A message sent by a gatekeeper to acknowledge the receipt of an IRR message from an endpoint.
INACK (Info_Request_Neg_Acknowledge)	A message sent a gatekeeper if an information request message is not understood.

RAS Disengage Information

An endpoint sends a Disengage Request (DRQ) message to a gatekeeper in the event of a call drop.

Table 7 lists the supported RAS disengage messages.

Table 7: Disengage Request Messages

Message	Description
DRQ (Disengage_Request)	A status request sent from an endpoint to a gatekeeper when a call ends.
DCF (Disengage_Confirm)	A message sent by a gatekeeper to confirm receipt of the DRQ message from an endpoint.
DRJ (Disengage_Reject)	A message sent by a gatekeeper that rejects a disengage confirmation request from an endpoint.

H.225 Call Signaling (Q.931)

H.225 is used to set up connections between H.323 endpoints. The (ITU-T) H.225 recommendation specifies the use and support of Q.931 messages.

H.225 call signaling supports the following messages:

Setup and Setup Acknowledge
Call Proceeding
Connect
Alerting
User Information
Release Complete
Facility
Progress
Status and Status Inquiry
Notify

H.245 Media Control and Transport signaling

H.245 handles end-to-end control messages between H.323 endpoints. This control channel protocol establishes the logical channels for transmission of audio, video, data, and control channel information.

H.245 supports the following messages:

Request
Response
Command
Indication

Understanding H.323 ALG Unknown Message Types

Unknown H.323 message type feature enables you to specify how unidentified H.323 messages are handled by the device. The default is to drop unknown (unsupported) messages.

You can protect the H.323 gatekeeper from denial-of-service (DoS) flood attacks by limiting the number of Registration, Admission, and Status (RAS) messages per second it will attempt to process. Incoming RAS request messages exceeding the threshold you specify are dropped by the H.323 Application Layer Gateway (ALG). The range is 2 to 50,000 messages per second, the default value is 1000.

We do not recommend permitting unknown messages because they can compromise security. However, in a secure test or production environment, unknown H.323 message type command can be useful for resolving interoperability issues with disparate vendor equipment. Permitting unknown H.323 messages can help you get your network operational, so that you can analyze your voice-over-IP (VoIP) traffic to determine why some messages were being dropped. The unknown H.323 message type feature enables you to configure the device to accept H.323 traffic containing unknown message types in both Network Address Translation (NAT) mode and route mode.

Note:

Unknown H.323 message type option applies only to received packets identified as supported VoIP packets. If a packet cannot be identified, it is always dropped. If a packet is identified as a supported protocol and you have configured the device to permit unknown message types, the message is forwarded without processing.

Example: Allowing Unknown H.323 ALG Message Types

This example shows how to configure the device to allow unknown H.323 message types in both route and NAT modes.

Requirements
Overview
Configuration
Verification

Requirements

Overview

This feature enables you to specify how unidentified H.323 messages are handled by the device. The default is to drop unknown (unsupported) messages. The Enable Permit NAT applied option and the permit-nat-applied configuration statement specify that unknown messages be allowed to pass if the session is in NAT mode. The Enable Permit routed option and the permit-routed configuration statement specify that unknown messages be allowed to pass if the session is in route mode. (Sessions in transparent mode are treated as route mode.)

Configuration

Procedure

GUI Quick Configuration
Step-by-Step Procedure

GUI Quick Configuration

Step-by-Step Procedure

To configure the device to allow unknown H.323 message types in both route and NAT modes:

Select Configure>Security>ALG.
Select the H323 tab.
Select the Enable Permit NAT applied check box.
Select the Enable Permit routed check box.
Click OK to check your configuration and save it as a candidate configuration.
If you are done configuring the device, click Commit Options>Commit.

Step-by-Step Procedure

To configure the device to allow unknown H.323 message types in both route and NAT modes:

Specify that unknown messages be allowed to pass if the session is in NAT mode.
[edit] user@host# set security alg h323 application-screen unknown-message permit-nat-applied
Specify that unknown messages be allowed to pass if the session is in route mode.
[edit] user@host# set security alg h323 application-screen unknown-message permit-routed
If you are done configuring the device, commit the configuration.
[edit] user@host# commit

Verification

To verify the configuration is working properly, enter the show security alg h323 command and the show security alg h323 counters command.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

ReleaseDescription17.4R1Starting with Junos OS Release 17.4R1, the gateway-to-gateway call feature is supported on the H.323 Application Layer Gateway (ALG).17.4R1Starting with Junos OS Release 17.4R1, the H.323 Application Layer Gateway (ALG) supports NAT64 rules in an IPv6 network.

Từ khóa » H323

ON THIS PAGE

Understanding H.323 ALG

H.323 ALG Configuration Overview

Understanding the Avaya H.323 ALG

Avaya H.323 ALG-Specific Features

Call Flow Details in the Avaya H.323 ALG

Example: Passing H.323 ALG Traffic to a Gatekeeper in the Private Zone

Requirements

Overview

Configuration

Procedure

CLI Quick Configuration

Step-by-Step Procedure

Results

Verification

Verifying H.323 ALG Configurations

Purpose

Action

Example: Passing H.323 ALG Traffic to a Gatekeeper in the External Zone

Requirements

Overview

Configuration

Procedure

CLI Quick Configuration

Step-by-Step Procedure

Results

Verification

Verifying H.323 ALG Configurations

Purpose

Action

Example: Using NAT with the H.323 ALG to Enable Incoming Calls

Requirements

Overview

Topology

Configuration

Procedure

CLI Quick Configuration

Step-by-Step Procedure

Results

Verification

Verifying H.323 ALG Status

Purpose

Action

Meaning

Verifying Security ALG H.323 Counters

Purpose

Action

Meaning

Verifying Source NAT Rule Usage

Purpose

Action

Meaning

Example: Using NAT with the H.323 ALG to Enable Outgoing Calls

Requirements

Overview

Topology

Configuration

Procedure

CLI Quick Configuration

Step-by-Step Procedure

Results

Verification

Verifying H.323 ALG Status

Purpose

Action

Meaning

Verifying Security ALG H.323 Counters

Purpose

Action

Meaning

Example: Setting H.323 ALG Endpoint Registration Timeouts

Requirements

Overview

Configuration

Procedure

GUI Quick Configuration

Step-by-Step Procedure

Step-by-Step Procedure

Verification

Example: Setting H.323 ALG Media Source Port Ranges