Support Support Downloads Knowledge Base Service Request Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[ScreenOS] Why are H323 clients able to register to GK successfully but unable to establish the Q931 connection with DIP?

0

0

Article ID: KB22252 KB Last Updated: 12 Dec 2011Version: 1.0
Summary:
This article describes the issue of H323 clients being able to register to GK successfully, but unable to establish the Q931 connection with DIP.

Symptoms:
Here is an example for H323 with DIP:
                     GK 2.1.1.1
                             |
       trust e1         | untrust  e2
---------------ScreenOS------------------client 2 1.1.1.101
client 1                    untrust e3
192.168.20.100
dip ip
1.1.1.100

Client 1 is in trust zone and GK and client 2 are in untrust zone with public IP. Client 1's DIP IP is 1.1.1.100. Client 2 would like to use the DIP IP to establish H323 with client 1.

Client 1 and client 2 are able to register to GK successfully; however, Q931 between client 1 and client 2 always fails.


Cause:
GK registers client in the trust zone with dip-ip and dip-port, so the client in untrust zone initiated h.245 to client in trust zone, using dip-ip and dip-port as destination ip/port. While it is denied by the firewall, H.245 session failed to setup.

Solution:
There are 2 ways to fix the issue:

  • Use MIP for trust h.323 client.

  • Use incoming-table for the h.323 client dip config (it is up to GK to use fixed 1720 port).

When the incoming-table is enabled, ScreenOS will maintenance a static table to map the client ip/port to dip-ip/dip-port; when there is a dst-ip/port match for the entry, it will change to the client's real ip/port.

Here is the procedure with the above example, without incoming table:

  1. Client 1 registers to GK, 192.168.20.100:1720 to 2.1.1.1:1720 and DIP change to 1.1.1.100:5000 to 2.1.1.1:1720.

  2. GK registers with client 1 - 1.1.1.100:5000.

  3. Client 2 accesses GK to lookup client 1 ip - port and GK returns 1.1.1.100:5000 to client 2.

  4. Client 2 uses 1.1.1.100:5000 as dst ip/port to try to establish h.245 with client 1.

  5. There is no nat session match dst port 5000, h.245 failed.


With incoming table:

  1. Client 1 registers to GK, 192.168.20.100:1720 to 1.1.1.1:1720, DIP change to 1.1.1.100:5000 to 1.1.1.1:1720. Incoming table: 1.1.1.100:5000 to 1.1.1.1:1720 with static entry. The incoming table will be created in e1.

  2. GK registers with client1: 1.1.1.100:5000.

  3. Client 2 accesses GK to lookup client 1 ip:port and GK returns 1.1.1.100:5000 to client 2.

  4. Client 2 uses 1.1.1.100:5000 as dst ip/port to try to establish h.245 with client 1.

  5. Client 2's packet ingress to e1, matches the incoming table.

  6. ScreenOS changes the port to 1720 and client 2 establishes H.245 successfully.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Security Alerts and Vulnerabilities

Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search