Skip to main content
About the Resource Center

FAQs: Firewall

When using a cloud security platform, should I split tunnel Genesys Cloud media traffic for work from home agents?

Yes. When using  third-party cloud a security platform, such as zScaler, Netskope, or Prisma, Genesys recommends bypassing the Genesys Cloud Media ranges and allowing media to flow directly over the Internet. This reduces latency, prevents issues caused by inspection and inspection, and eliminates a potential failure point. For more information, see the Genesys Cloud Media section of the IP addresses for the firewall allowlist article.

You should work with you cloud security platform vendor to create a compatible configuration to ensure there are no issues with Genesys Cloud media traffic. Especially, if you have internal requirements which require Genesys Cloud media to flow through your cloud infrastructure.

Does Genesys Cloud require any ports to be open for inbound access?

No. Genesys Cloud does not require any ports to be open for inbound access. The majority of the Genesys Cloud open port requirements are only for outbound access – not inbound access. More specifically, all client connections (including BYOC Premises Edges, WebRTC Clients, and hard phones for BYOC Cloud and Genesys Cloud Voice customers) to Genesys Cloud are initiated as outbound connections to Genesys Cloud’s cloud services.

The only use case in which a port would need to be open for inbound access in Genesys Cloud would be if you are using on-premises Edges on separate networks and there is a firewall between those Edges. For more information, see the Intra-Edge Group Communications section of the Ports and services for Edge devices under BYOC Premises article.

Why is the edge attempting to make WebRTC connections on a port number outside of the 16384-65535 port range?

While Genesys Cloud configures the edge to work within the 16384-65535 port range for WebRTC communications, the Genesys Cloud WebRTC clients are not restricted to this port range. More specifically, an edge uses a port in the 16384-65535 range as the source port, but the WebRTC clients can use whatever port number is available for the destination port.

This means that if the WebRTC client responds using a port number outside the supported range, the edge still attempts to establish the audio connection using the provided port number. When the port number is outside the supported range, the WebRTC connection still succeeds unless that connection is blocked.

To bypass this problem, you can configure Genesys Cloud to use the TURN Behavior feature along with the GEO-Lookup feature. That way, even if the connection is blocked, the call can still succeed using the TURN service as a Relay. This works because the TURN service will always be within the supported port range. 

However, if the latency costs associated with using a TURN service in your specific region are too great, even with GEO-Lookup, you can use an alternative solution, which involves modifying your firewall settings.

Modifying your firewall settings allows the edge to communicate on whatever destination port the WebRTC client chooses. Making this modification would mean that the source port would be open to any port that the WebRTC client chooses. The destination port is still limited to the 16384-65535 port range. For more information, contact Genesys Cloud Customer Care.

Can I configure SSL inspection on a proxy server firewall that sits between client workstation and Genesys Cloud?

Yes, but Genesys Cloud currently only supports this configuration on HTTPS over Port 443 connections to the Genesys Cloud platform. All other connections are not supported by Genesys Cloud at this time.

For more information, see About ports and services for your firewall.

Can I configure SSL inspection on a proxy server firewall that sits between an on-premises Edge and Genesys Cloud?

No. The Edge will not allow another device to intercept traffic. The Edge determines that this type of inspection is unsecure and shuts down the connection.

My firewall/security device is performing a reverse lookup of addresses already resolved by the Edge when making WebRTC calls, is this a supported configuration?

Yes. WebRTC can support this type of configuration, but it is not a practical.

To allow WebRTC to function with this type firewall/security device configuration, you would have to add all domains to your allowlist that the Edge resolves that your firewall/security device considers suspect. Doing so is problematic.

Genesys Cloud best practice specifies:

  1. Do not configure your firewall to perform reverse lookups.
  2. Do not add domain names to your allowlist.

When troubleshooting firewall issues, why do I see names like 1e100.net when doing a reverse lookup on addresses resolved from *.l.google.com?

The name 1e100.net is a valid Google domain name and identifies its servers. For more information, see Google Help.

This firewall issue can occur when an Edge resolves *.l.google.com to make a WebRTC call and then sends the request to the firewall/security device. If the firewall/security device performs a reverse lookup, it receives 1e100.net instead of *.l.google.com and the call fails.

The preferred way to avoid this issue is to disable the reverse lookup functionality on your firewall/security device.
The alternative, adding 1e100.net to your allowlist and all the records that accompany it is possible, but problematic.

Genesys Cloud best practice specifies:

  1. Do not configure your firewall to perform reverse lookups.
  2. Do not add domain names to your allowlist.

My firewall can’t do JSON updates or DNS lookups, what can I do?

You have two options. You can simply open the required ports, which are outbound only, or you can upgrade your firewall.

Why does the port range 16384-65535 (RTP media) need to be opened up for Genesys Cloud Voice/BYOC Cloud?

This port range only needs to be opened for outbound connections. Genesys Cloud needs access to all of the ports in this range to ensure that the number of possible simultaneous media streams is sufficient. If these ports are not open for outbound connections, then any media that uses RTP may be intermittent or completely unavailable.

What happens if I don’t update my firewall with new entries in the AWS JSON file? Will we lose connectivity?

Yes, you could very well lose connectivity. The problem with not updating the entries is that issues can occur if some IP destinations are blocked while others are not. This could manifest itself as either a complete loss of service or intermittent loss of service.