Genesys Cloud - Main

Hi Everyone,

I know that this question was asked a couple of times throughout the years and sadly left unanswered by all the community and Genesys representatives. On one of the posts, it was answered indeed but the answer was searching for a needle in a haystack.

Let me get to the problem...

After many sales and technical meetings, a customer happily decides to buy the GenesysCloud solution and starts building their self-service IVR.
Their IVR includes sending informational SMS' on some points. They use an ITSP's Web Service Interface for sending these SMS' with their current on-prem solution. There is a Telco Security Regulation that all ITSP should define the IP Ranges of the hosts calling the "SMS Send" service. It is enforced by the law. So all they did in the past was providing the IP address of their firewall to their ITSP and they were able to use the service by adding some FW forwarding rules.

Now they are trying to achieve the same on PureCloud. They created a Custom Data Action. It is simple I agree... But, the test failed because they forgot to provide the source IP address or addresses of the GenesysCloud or the AWS. The addresses from where this service will be called. They simply can't open this service to all/all as there is a serious penalty for that.

So, checking the documentation one ends up finding the https://ip-ranges.amazonaws.com/ip-ranges.json link. The one which when you open you get 16.000 lines of a JSON text file. Wow, imagine giving this to the customer's firewall admin or their ITSP and telling them to allow them all. Imagine their reply....

OK, so the one moves forward and tries to find the region where they are hosted. He learns it's Ireland and that it's in eu-west-1 (rds.eu-west-1.amazonaws.com). Filtering the big list with eu-west-1 he narrows it down to 224 entries. So there are 224 IP ranges that he needs to send to the customer. Think about it... "All you need to do to enable sending SMS is to allow a couple of IP Addresses." -Just a couple? "Yes, 224 IP ranges."
- How about the updates? I mean how do I know if AWS adds or removes a range? "Welllll....s***".

Is it just me or do you guys also think that Genesys needs to do something about this problem?

If nothing is possible for reducing the IP ranges at least a simple app published on the GenesysCloud developer or help sites would do some help to all. An app that gives a filtered list of IP addresses based on ones login and ORG information. An app that would maybe use the following output would really be helpful to all:  Get-AWSPublicIpAddressRange -Region xxxxx

Anyway, I just wanted to say that this problem is frustrating for our customers and damaging our successful sales and partner relations.

I wonder if there are others out there who agree with me.


#Integrations

------------------------------
Thanks,
Oktay Kemal
CCR
------------------------------

Hello Oktay,

This was going to be a huge issue for me as well, luckily, right around the time I needed it - this popped up under the Domains and IP Addresses / IP Addresses section (from https://help.mypurecloud.com/articles/purecloud-ports-services):

"PureCloud also uses certain IP addresses for outbound data action traffic to customer endpoints. You can whitelist these IP addresses to prevent unauthorized access to your API resources. To retrieve a list of these IP addresses, call GET /api/v2/ipranges."

For me in US-West, it meant the vendor that we were integrating with had to only whitelist 6 IP addresses. I hope this helps!

------------------------------
Altaf Gosla
Telecom Systems Engineer
------------------------------

Original Message:
Sent: 04-13-2020 12:23
From: Oktay Kemal
Subject: AWS IP Pool and Our Angry Customers

Hi Everyone,

I know that this question was asked a couple of times throughout the years and sadly left unanswered by all the community and Genesys representatives. On one of the posts, it was answered indeed but the answer was searching for a needle in a haystack.

Let me get to the problem...

After many sales and technical meetings, a customer happily decides to buy the GenesysCloud solution and starts building their self-service IVR.
Their IVR includes sending informational SMS' on some points. They use an ITSP's Web Service Interface for sending these SMS' with their current on-prem solution. There is a Telco Security Regulation that all ITSP should define the IP Ranges of the hosts calling the "SMS Send" service. It is enforced by the law. So all they did in the past was providing the IP address of their firewall to their ITSP and they were able to use the service by adding some FW forwarding rules.

Now they are trying to achieve the same on PureCloud. They created a Custom Data Action. It is simple I agree... But, the test failed because they forgot to provide the source IP address or addresses of the GenesysCloud or the AWS. The addresses from where this service will be called. They simply can't open this service to all/all as there is a serious penalty for that.

So, checking the documentation one ends up finding the https://ip-ranges.amazonaws.com/ip-ranges.json link. The one which when you open you get 16.000 lines of a JSON text file. Wow, imagine giving this to the customer's firewall admin or their ITSP and telling them to allow them all. Imagine their reply....

OK, so the one moves forward and tries to find the region where they are hosted. He learns it's Ireland and that it's in eu-west-1 (rds.eu-west-1.amazonaws.com). Filtering the big list with eu-west-1 he narrows it down to 224 entries. So there are 224 IP ranges that he needs to send to the customer. Think about it... "All you need to do to enable sending SMS is to allow a couple of IP Addresses." -Just a couple? "Yes, 224 IP ranges."
- How about the updates? I mean how do I know if AWS adds or removes a range? "Welllll....s***".

Is it just me or do you guys also think that Genesys needs to do something about this problem?

If nothing is possible for reducing the IP ranges at least a simple app published on the GenesysCloud developer or help sites would do some help to all. An app that gives a filtered list of IP addresses based on ones login and ORG information. An app that would maybe use the following output would really be helpful to all:  Get-AWSPublicIpAddressRange -Region xxxxx

Anyway, I just wanted to say that this problem is frustrating for our customers and damaging our successful sales and partner relations.

I wonder if there are others out there who agree with me.


#Integrations

------------------------------
Thanks,
Oktay Kemal
CCR
------------------------------

Hi,

I have the same pain before with the customer to whitelist IP addresses given in this URL. https://ip-ranges.amazonaws.com/ip-ranges.json

May someone confirm if Australia customers only need to whitelist 3 sets of IP addresses given by GET /api/v2/ipranges? 

Regards,

Johnson

------------------------------
Johnson Lu
MFE International Pte Ltd.
------------------------------

Original Message:
Sent: 04-13-2020 19:11
From: Altaf Gosla
Subject: AWS IP Pool and Our Angry Customers

Hello Oktay,

This was going to be a huge issue for me as well, luckily, right around the time I needed it - this popped up (from https://help.mypurecloud.com/articles/byoc-cloud-public-sip-ip-addresses/):

"PureCloud also uses certain IP addresses for outbound data action traffic to customer endpoints. You can whitelist these IP addresses to prevent unauthorized access to your API resources. To retrieve a list of these IP addresses, call GET /api/v2/ipranges."

For me in US-West, it meant the vendor that we were integrating with had to only whitelist 6 IP addresses. I hope this helps!

------------------------------
Altaf Gosla
Telecom Systems Engineer

Original Message:
Sent: 04-13-2020 12:23
From: Oktay Kemal
Subject: AWS IP Pool and Our Angry Customers

Hi Everyone,

I know that this question was asked a couple of times throughout the years and sadly left unanswered by all the community and Genesys representatives. On one of the posts, it was answered indeed but the answer was searching for a needle in a haystack.

Let me get to the problem...

After many sales and technical meetings, a customer happily decides to buy the GenesysCloud solution and starts building their self-service IVR.
Their IVR includes sending informational SMS' on some points. They use an ITSP's Web Service Interface for sending these SMS' with their current on-prem solution. There is a Telco Security Regulation that all ITSP should define the IP Ranges of the hosts calling the "SMS Send" service. It is enforced by the law. So all they did in the past was providing the IP address of their firewall to their ITSP and they were able to use the service by adding some FW forwarding rules.

Now they are trying to achieve the same on PureCloud. They created a Custom Data Action. It is simple I agree... But, the test failed because they forgot to provide the source IP address or addresses of the GenesysCloud or the AWS. The addresses from where this service will be called. They simply can't open this service to all/all as there is a serious penalty for that.

So, checking the documentation one ends up finding the https://ip-ranges.amazonaws.com/ip-ranges.json link. The one which when you open you get 16.000 lines of a JSON text file. Wow, imagine giving this to the customer's firewall admin or their ITSP and telling them to allow them all. Imagine their reply....

OK, so the one moves forward and tries to find the region where they are hosted. He learns it's Ireland and that it's in eu-west-1 (rds.eu-west-1.amazonaws.com). Filtering the big list with eu-west-1 he narrows it down to 224 entries. So there are 224 IP ranges that he needs to send to the customer. Think about it... "All you need to do to enable sending SMS is to allow a couple of IP Addresses." -Just a couple? "Yes, 224 IP ranges."
- How about the updates? I mean how do I know if AWS adds or removes a range? "Welllll....s***".

Is it just me or do you guys also think that Genesys needs to do something about this problem?

If nothing is possible for reducing the IP ranges at least a simple app published on the GenesysCloud developer or help sites would do some help to all. An app that gives a filtered list of IP addresses based on ones login and ORG information. An app that would maybe use the following output would really be helpful to all:  Get-AWSPublicIpAddressRange -Region xxxxx

Anyway, I just wanted to say that this problem is frustrating for our customers and damaging our successful sales and partner relations.

I wonder if there are others out there who agree with me.


#Integrations

------------------------------
Thanks,
Oktay Kemal
CCR
------------------------------

Hi Altaf,

Thanks, but unfortunately these are SIP IP Addresses used for voice routing. The ones you need to inform your carrier.

So we need exactly the same or something similar and simplified as this for Integrations in the Admin section of GenesysCloud.
The place we create integrations with third-party apps and web services.


------------------------------
Thanks,
Oktay Kemal
CCR
------------------------------

Original Message:
Sent: 04-13-2020 19:11
From: Altaf Gosla
Subject: AWS IP Pool and Our Angry Customers

Hello Oktay,

This was going to be a huge issue for me as well, luckily, right around the time I needed it - this popped up (from https://help.mypurecloud.com/articles/byoc-cloud-public-sip-ip-addresses/):

"PureCloud also uses certain IP addresses for outbound data action traffic to customer endpoints. You can whitelist these IP addresses to prevent unauthorized access to your API resources. To retrieve a list of these IP addresses, call GET /api/v2/ipranges."

For me in US-West, it meant the vendor that we were integrating with had to only whitelist 6 IP addresses. I hope this helps!

------------------------------
Altaf Gosla
Telecom Systems Engineer

Original Message:
Sent: 04-13-2020 12:23
From: Oktay Kemal
Subject: AWS IP Pool and Our Angry Customers

Hi Everyone,

I know that this question was asked a couple of times throughout the years and sadly left unanswered by all the community and Genesys representatives. On one of the posts, it was answered indeed but the answer was searching for a needle in a haystack.

Let me get to the problem...

After many sales and technical meetings, a customer happily decides to buy the GenesysCloud solution and starts building their self-service IVR.
Their IVR includes sending informational SMS' on some points. They use an ITSP's Web Service Interface for sending these SMS' with their current on-prem solution. There is a Telco Security Regulation that all ITSP should define the IP Ranges of the hosts calling the "SMS Send" service. It is enforced by the law. So all they did in the past was providing the IP address of their firewall to their ITSP and they were able to use the service by adding some FW forwarding rules.

Now they are trying to achieve the same on PureCloud. They created a Custom Data Action. It is simple I agree... But, the test failed because they forgot to provide the source IP address or addresses of the GenesysCloud or the AWS. The addresses from where this service will be called. They simply can't open this service to all/all as there is a serious penalty for that.

So, checking the documentation one ends up finding the https://ip-ranges.amazonaws.com/ip-ranges.json link. The one which when you open you get 16.000 lines of a JSON text file. Wow, imagine giving this to the customer's firewall admin or their ITSP and telling them to allow them all. Imagine their reply....

OK, so the one moves forward and tries to find the region where they are hosted. He learns it's Ireland and that it's in eu-west-1 (rds.eu-west-1.amazonaws.com). Filtering the big list with eu-west-1 he narrows it down to 224 entries. So there are 224 IP ranges that he needs to send to the customer. Think about it... "All you need to do to enable sending SMS is to allow a couple of IP Addresses." -Just a couple? "Yes, 224 IP ranges."
- How about the updates? I mean how do I know if AWS adds or removes a range? "Welllll....s***".

Is it just me or do you guys also think that Genesys needs to do something about this problem?

If nothing is possible for reducing the IP ranges at least a simple app published on the GenesysCloud developer or help sites would do some help to all. An app that gives a filtered list of IP addresses based on ones login and ORG information. An app that would maybe use the following output would really be helpful to all:  Get-AWSPublicIpAddressRange -Region xxxxx

Anyway, I just wanted to say that this problem is frustrating for our customers and damaging our successful sales and partner relations.

I wonder if there are others out there who agree with me.


#Integrations

------------------------------
Thanks,
Oktay Kemal
CCR
------------------------------

@OKTAY KEMAL
My apologies - I pasted the wrong link - I have corrected it now. We are using the 6 IP addresses provided by the API (for our region) to integrate with a third party web service.

@Johnson Lu
That should be all you need - hopefully others can chime in here as well.

Thanks!
​​

------------------------------
Altaf Gosla
Telecom Systems Engineer
------------------------------

Original Message:
Sent: 04-14-2020 04:41
From: Oktay Kemal
Subject: AWS IP Pool and Our Angry Customers

Hi Altaf,

Thanks, but unfortunately these are SIP IP Addresses used for voice routing. The ones you need to inform your carrier.

So we need exactly the same or something similar and simplified as this for Integrations in the Admin section of GenesysCloud.
The place we create integrations with third-party apps and web services.


------------------------------
Thanks,
Oktay Kemal
CCR

Original Message:
Sent: 04-13-2020 19:11
From: Altaf Gosla
Subject: AWS IP Pool and Our Angry Customers

Hello Oktay,

This was going to be a huge issue for me as well, luckily, right around the time I needed it - this popped up (from https://help.mypurecloud.com/articles/byoc-cloud-public-sip-ip-addresses/):

"PureCloud also uses certain IP addresses for outbound data action traffic to customer endpoints. You can whitelist these IP addresses to prevent unauthorized access to your API resources. To retrieve a list of these IP addresses, call GET /api/v2/ipranges."

For me in US-West, it meant the vendor that we were integrating with had to only whitelist 6 IP addresses. I hope this helps!

------------------------------
Altaf Gosla
Telecom Systems Engineer

Original Message:
Sent: 04-13-2020 12:23
From: Oktay Kemal
Subject: AWS IP Pool and Our Angry Customers

Hi Everyone,

I know that this question was asked a couple of times throughout the years and sadly left unanswered by all the community and Genesys representatives. On one of the posts, it was answered indeed but the answer was searching for a needle in a haystack.

Let me get to the problem...

After many sales and technical meetings, a customer happily decides to buy the GenesysCloud solution and starts building their self-service IVR.
Their IVR includes sending informational SMS' on some points. They use an ITSP's Web Service Interface for sending these SMS' with their current on-prem solution. There is a Telco Security Regulation that all ITSP should define the IP Ranges of the hosts calling the "SMS Send" service. It is enforced by the law. So all they did in the past was providing the IP address of their firewall to their ITSP and they were able to use the service by adding some FW forwarding rules.

Now they are trying to achieve the same on PureCloud. They created a Custom Data Action. It is simple I agree... But, the test failed because they forgot to provide the source IP address or addresses of the GenesysCloud or the AWS. The addresses from where this service will be called. They simply can't open this service to all/all as there is a serious penalty for that.

So, checking the documentation one ends up finding the https://ip-ranges.amazonaws.com/ip-ranges.json link. The one which when you open you get 16.000 lines of a JSON text file. Wow, imagine giving this to the customer's firewall admin or their ITSP and telling them to allow them all. Imagine their reply....

OK, so the one moves forward and tries to find the region where they are hosted. He learns it's Ireland and that it's in eu-west-1 (rds.eu-west-1.amazonaws.com). Filtering the big list with eu-west-1 he narrows it down to 224 entries. So there are 224 IP ranges that he needs to send to the customer. Think about it... "All you need to do to enable sending SMS is to allow a couple of IP Addresses." -Just a couple? "Yes, 224 IP ranges."
- How about the updates? I mean how do I know if AWS adds or removes a range? "Welllll....s***".

Is it just me or do you guys also think that Genesys needs to do something about this problem?

If nothing is possible for reducing the IP ranges at least a simple app published on the GenesysCloud developer or help sites would do some help to all. An app that gives a filtered list of IP addresses based on ones login and ORG information. An app that would maybe use the following output would really be helpful to all:  Get-AWSPublicIpAddressRange -Region xxxxx

Anyway, I just wanted to say that this problem is frustrating for our customers and damaging our successful sales and partner relations.

I wonder if there are others out there who agree with me.


#Integrations

------------------------------
Thanks,
Oktay Kemal
CCR
------------------------------

Hello Oktay,

I see the problem just as you do. We are in the AWS Germany region and had only whitelisted the IPs, but for telephony or provisioning of the Polycom phones, you also have to activate IP addresses from US and EU West . The Genesys IP construct is really not the best one.

------------------------------
Christoph Otto
------------------------------

Original Message:
Sent: 04-13-2020 12:23
From: Oktay Kemal
Subject: AWS IP Pool and Our Angry Customers

Hi Everyone,

I know that this question was asked a couple of times throughout the years and sadly left unanswered by all the community and Genesys representatives. On one of the posts, it was answered indeed but the answer was searching for a needle in a haystack.

Let me get to the problem...

After many sales and technical meetings, a customer happily decides to buy the GenesysCloud solution and starts building their self-service IVR.
Their IVR includes sending informational SMS' on some points. They use an ITSP's Web Service Interface for sending these SMS' with their current on-prem solution. There is a Telco Security Regulation that all ITSP should define the IP Ranges of the hosts calling the "SMS Send" service. It is enforced by the law. So all they did in the past was providing the IP address of their firewall to their ITSP and they were able to use the service by adding some FW forwarding rules.

Now they are trying to achieve the same on PureCloud. They created a Custom Data Action. It is simple I agree... But, the test failed because they forgot to provide the source IP address or addresses of the GenesysCloud or the AWS. The addresses from where this service will be called. They simply can't open this service to all/all as there is a serious penalty for that.

So, checking the documentation one ends up finding the https://ip-ranges.amazonaws.com/ip-ranges.json link. The one which when you open you get 16.000 lines of a JSON text file. Wow, imagine giving this to the customer's firewall admin or their ITSP and telling them to allow them all. Imagine their reply....

OK, so the one moves forward and tries to find the region where they are hosted. He learns it's Ireland and that it's in eu-west-1 (rds.eu-west-1.amazonaws.com). Filtering the big list with eu-west-1 he narrows it down to 224 entries. So there are 224 IP ranges that he needs to send to the customer. Think about it... "All you need to do to enable sending SMS is to allow a couple of IP Addresses." -Just a couple? "Yes, 224 IP ranges."
- How about the updates? I mean how do I know if AWS adds or removes a range? "Welllll....s***".

Is it just me or do you guys also think that Genesys needs to do something about this problem?

If nothing is possible for reducing the IP ranges at least a simple app published on the GenesysCloud developer or help sites would do some help to all. An app that gives a filtered list of IP addresses based on ones login and ORG information. An app that would maybe use the following output would really be helpful to all:  Get-AWSPublicIpAddressRange -Region xxxxx

Anyway, I just wanted to say that this problem is frustrating for our customers and damaging our successful sales and partner relations.

I wonder if there are others out there who agree with me.


#Integrations

------------------------------
Thanks,
Oktay Kemal
CCR
------------------------------

It's worth clarifying that the IP Addresses presented by that endpoint represent the NAT gateways that the Data Action Service will use to communicate with external API routes (i.e. these are the IP addresses that would attempt to access servers on your premise if you have a data action configured to do so).  

Additionally, you need to consider the ip addresses for SIP functionality for BYOC (if applicable to your org), documented here: https://help.mypurecloud.com/articles/byoc-cloud-public-sip-ip-addresses/

------------------------------
Richard Schott
Genesys - Employees
------------------------------

Original Message:
Sent: 04-15-2020 03:52
From: Christoph Otto
Subject: AWS IP Pool and Our Angry Customers

Hello Oktay,

I see the problem just as you do. We are in the AWS Germany region and had only whitelisted the IPs, but for telephony or provisioning of the Polycom phones, you also have to activate IP addresses from US and EU West . The Genesys IP construct is really not the best one.

------------------------------
Christoph Otto

Original Message:
Sent: 04-13-2020 12:23
From: Oktay Kemal
Subject: AWS IP Pool and Our Angry Customers

Hi Everyone,

I know that this question was asked a couple of times throughout the years and sadly left unanswered by all the community and Genesys representatives. On one of the posts, it was answered indeed but the answer was searching for a needle in a haystack.

Let me get to the problem...

After many sales and technical meetings, a customer happily decides to buy the GenesysCloud solution and starts building their self-service IVR.
Their IVR includes sending informational SMS' on some points. They use an ITSP's Web Service Interface for sending these SMS' with their current on-prem solution. There is a Telco Security Regulation that all ITSP should define the IP Ranges of the hosts calling the "SMS Send" service. It is enforced by the law. So all they did in the past was providing the IP address of their firewall to their ITSP and they were able to use the service by adding some FW forwarding rules.

Now they are trying to achieve the same on PureCloud. They created a Custom Data Action. It is simple I agree... But, the test failed because they forgot to provide the source IP address or addresses of the GenesysCloud or the AWS. The addresses from where this service will be called. They simply can't open this service to all/all as there is a serious penalty for that.

So, checking the documentation one ends up finding the https://ip-ranges.amazonaws.com/ip-ranges.json link. The one which when you open you get 16.000 lines of a JSON text file. Wow, imagine giving this to the customer's firewall admin or their ITSP and telling them to allow them all. Imagine their reply....

OK, so the one moves forward and tries to find the region where they are hosted. He learns it's Ireland and that it's in eu-west-1 (rds.eu-west-1.amazonaws.com). Filtering the big list with eu-west-1 he narrows it down to 224 entries. So there are 224 IP ranges that he needs to send to the customer. Think about it... "All you need to do to enable sending SMS is to allow a couple of IP Addresses." -Just a couple? "Yes, 224 IP ranges."
- How about the updates? I mean how do I know if AWS adds or removes a range? "Welllll....s***".

Is it just me or do you guys also think that Genesys needs to do something about this problem?

If nothing is possible for reducing the IP ranges at least a simple app published on the GenesysCloud developer or help sites would do some help to all. An app that gives a filtered list of IP addresses based on ones login and ORG information. An app that would maybe use the following output would really be helpful to all:  Get-AWSPublicIpAddressRange -Region xxxxx

Anyway, I just wanted to say that this problem is frustrating for our customers and damaging our successful sales and partner relations.

I wonder if there are others out there who agree with me.


#Integrations

------------------------------
Thanks,
Oktay Kemal
CCR
------------------------------

Hello OKTAY KEMAL, 

Here I am after 5 years,How was the problem solved? We are facing the same issue with our client who is refusing to add/open all IP addresses on the firewall.

------------------------------
Mohammad Saad
Tech Engineer
------------------------------

Original Message:
Sent: 04-13-2020 12:23
From: OKTAY KEMAL
Subject: AWS IP Pool and Our Angry Customers

Hi Everyone,

I know that this question was asked a couple of times throughout the years and sadly left unanswered by all the community and Genesys representatives. On one of the posts, it was answered indeed but the answer was searching for a needle in a haystack.

Let me get to the problem...

After many sales and technical meetings, a customer happily decides to buy the GenesysCloud solution and starts building their self-service IVR.
Their IVR includes sending informational SMS' on some points. They use an ITSP's Web Service Interface for sending these SMS' with their current on-prem solution. There is a Telco Security Regulation that all ITSP should define the IP Ranges of the hosts calling the "SMS Send" service. It is enforced by the law. So all they did in the past was providing the IP address of their firewall to their ITSP and they were able to use the service by adding some FW forwarding rules.

Now they are trying to achieve the same on PureCloud. They created a Custom Data Action. It is simple I agree... But, the test failed because they forgot to provide the source IP address or addresses of the GenesysCloud or the AWS. The addresses from where this service will be called. They simply can't open this service to all/all as there is a serious penalty for that.

So, checking the documentation one ends up finding the https://ip-ranges.amazonaws.com/ip-ranges.json link. The one which when you open you get 16.000 lines of a JSON text file. Wow, imagine giving this to the customer's firewall admin or their ITSP and telling them to allow them all. Imagine their reply....

OK, so the one moves forward and tries to find the region where they are hosted. He learns it's Ireland and that it's in eu-west-1 (rds.eu-west-1.amazonaws.com). Filtering the big list with eu-west-1 he narrows it down to 224 entries. So there are 224 IP ranges that he needs to send to the customer. Think about it... "All you need to do to enable sending SMS is to allow a couple of IP Addresses." -Just a couple? "Yes, 224 IP ranges."
- How about the updates? I mean how do I know if AWS adds or removes a range? "Welllll....s***".

Is it just me or do you guys also think that Genesys needs to do something about this problem?

If nothing is possible for reducing the IP ranges at least a simple app published on the GenesysCloud developer or help sites would do some help to all. An app that gives a filtered list of IP addresses based on ones login and ORG information. An app that would maybe use the following output would really be helpful to all:  Get-AWSPublicIpAddressRange -Region xxxxx

Anyway, I just wanted to say that this problem is frustrating for our customers and damaging our successful sales and partner relations.

I wonder if there are others out there who agree with me.


#API/Integrations

------------------------------
Thanks,
Oktay Kemal
CCR
------------------------------

Assuming the request is regarding Data Actions, then that is generally solved by calling our API route that describes the specific IP addresses utilized via the NAT Gateways that handle the egress of those data action invocations (note that this doesn't apply to Functions, but does apply to all other data action requests): https://developer.genesys.cloud/organization/utilities-apis#get-api-v2-ipranges.  This API request also describes the IP addresses used by another of other services/features in Genesys Cloud.  Here's the example response for the US East region:

{
  "entities": [
    {
      "cidr": "52.200.222.10/32",
      "service": "data-actions",
      "region": "us-east-1"
    },
    {
      "cidr": "52.200.222.10/32",
      "service": "smtp",
      "region": "us-east-1"
    },
    {
      "cidr": "52.200.222.10/32",
      "service": "imap",
      "region": "us-east-1"
    },
    {
      "cidr": "52.200.222.10/32",
      "service": "graphapi",
      "region": "us-east-1"
    },
    {
      "cidr": "52.200.222.10/32",
      "service": "open-messaging",
      "region": "us-east-1"
    },
    {
      "cidr": "52.200.222.10/32",
      "service": "audiohook",
      "region": "us-east-1"
    },
    {
      "cidr": "52.200.222.10/32",
      "service": "bot-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.10.219/32",
      "service": "data-actions",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.10.219/32",
      "service": "smtp",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.10.219/32",
      "service": "imap",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.10.219/32",
      "service": "graphapi",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.10.219/32",
      "service": "open-messaging",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.10.219/32",
      "service": "audiohook",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.10.219/32",
      "service": "bot-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "18.211.239.119/32",
      "service": "data-actions",
      "region": "us-east-1"
    },
    {
      "cidr": "18.211.239.119/32",
      "service": "smtp",
      "region": "us-east-1"
    },
    {
      "cidr": "18.211.239.119/32",
      "service": "imap",
      "region": "us-east-1"
    },
    {
      "cidr": "18.211.239.119/32",
      "service": "graphapi",
      "region": "us-east-1"
    },
    {
      "cidr": "18.211.239.119/32",
      "service": "open-messaging",
      "region": "us-east-1"
    },
    {
      "cidr": "18.211.239.119/32",
      "service": "audiohook",
      "region": "us-east-1"
    },
    {
      "cidr": "18.211.239.119/32",
      "service": "bot-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.21.52/32",
      "service": "data-actions",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.21.52/32",
      "service": "smtp",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.21.52/32",
      "service": "imap",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.21.52/32",
      "service": "graphapi",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.21.52/32",
      "service": "open-messaging",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.21.52/32",
      "service": "audiohook",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.21.52/32",
      "service": "bot-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.48.52/32",
      "service": "data-actions",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.48.52/32",
      "service": "smtp",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.48.52/32",
      "service": "imap",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.48.52/32",
      "service": "graphapi",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.48.52/32",
      "service": "open-messaging",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.48.52/32",
      "service": "audiohook",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.48.52/32",
      "service": "bot-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.192.194/32",
      "service": "data-actions",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.192.194/32",
      "service": "smtp",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.192.194/32",
      "service": "imap",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.192.194/32",
      "service": "graphapi",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.192.194/32",
      "service": "open-messaging",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.192.194/32",
      "service": "audiohook",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.192.194/32",
      "service": "bot-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.192.168/32",
      "service": "audio-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.192.168/32",
      "service": "byot-stt",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.192.168/32",
      "service": "tts-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "52.200.215.52/32",
      "service": "audio-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "52.200.215.52/32",
      "service": "byot-stt",
      "region": "us-east-1"
    },
    {
      "cidr": "52.200.215.52/32",
      "service": "tts-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.86.78/32",
      "service": "audio-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.86.78/32",
      "service": "byot-stt",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.86.78/32",
      "service": "tts-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "23.20.152.234/32",
      "service": "audio-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "23.20.152.234/32",
      "service": "byot-stt",
      "region": "us-east-1"
    },
    {
      "cidr": "23.20.152.234/32",
      "service": "tts-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.62.251/32",
      "service": "audio-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.62.251/32",
      "service": "byot-stt",
      "region": "us-east-1"
    },
    {
      "cidr": "52.201.62.251/32",
      "service": "tts-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.38.108/32",
      "service": "audio-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.38.108/32",
      "service": "byot-stt",
      "region": "us-east-1"
    },
    {
      "cidr": "18.214.38.108/32",
      "service": "tts-connector",
      "region": "us-east-1"
    },
    {
      "cidr": "169.150.110.10/32",
      "service": "api",
      "region": "us-east-1"
    },
    {
      "cidr": "169.150.111.10/32",
      "service": "api",
      "region": "us-east-1"
    }
  ]
}

------------------------------
Richard Schott
Product Manager
------------------------------

Original Message:
Sent: 05-20-2025 01:32
From: Mohammad Saad
Subject: AWS IP Pool and Our Angry Customers

Hello OKTAY KEMAL, 

Here I am after 5 years,How was the problem solved? We are facing the same issue with our client who is refusing to add/open all IP addresses on the firewall.

------------------------------
Mohammad Saad
Tech Engineer

Original Message:
Sent: 04-13-2020 12:23
From: OKTAY KEMAL
Subject: AWS IP Pool and Our Angry Customers

Hi Everyone,

I know that this question was asked a couple of times throughout the years and sadly left unanswered by all the community and Genesys representatives. On one of the posts, it was answered indeed but the answer was searching for a needle in a haystack.

Let me get to the problem...

After many sales and technical meetings, a customer happily decides to buy the GenesysCloud solution and starts building their self-service IVR.
Their IVR includes sending informational SMS' on some points. They use an ITSP's Web Service Interface for sending these SMS' with their current on-prem solution. There is a Telco Security Regulation that all ITSP should define the IP Ranges of the hosts calling the "SMS Send" service. It is enforced by the law. So all they did in the past was providing the IP address of their firewall to their ITSP and they were able to use the service by adding some FW forwarding rules.

Now they are trying to achieve the same on PureCloud. They created a Custom Data Action. It is simple I agree... But, the test failed because they forgot to provide the source IP address or addresses of the GenesysCloud or the AWS. The addresses from where this service will be called. They simply can't open this service to all/all as there is a serious penalty for that.

So, checking the documentation one ends up finding the https://ip-ranges.amazonaws.com/ip-ranges.json link. The one which when you open you get 16.000 lines of a JSON text file. Wow, imagine giving this to the customer's firewall admin or their ITSP and telling them to allow them all. Imagine their reply....

OK, so the one moves forward and tries to find the region where they are hosted. He learns it's Ireland and that it's in eu-west-1 (rds.eu-west-1.amazonaws.com). Filtering the big list with eu-west-1 he narrows it down to 224 entries. So there are 224 IP ranges that he needs to send to the customer. Think about it... "All you need to do to enable sending SMS is to allow a couple of IP Addresses." -Just a couple? "Yes, 224 IP ranges."
- How about the updates? I mean how do I know if AWS adds or removes a range? "Welllll....s***".

Is it just me or do you guys also think that Genesys needs to do something about this problem?

If nothing is possible for reducing the IP ranges at least a simple app published on the GenesysCloud developer or help sites would do some help to all. An app that gives a filtered list of IP addresses based on ones login and ORG information. An app that would maybe use the following output would really be helpful to all:  Get-AWSPublicIpAddressRange -Region xxxxx

Anyway, I just wanted to say that this problem is frustrating for our customers and damaging our successful sales and partner relations.

I wonder if there are others out there who agree with me.


#API/Integrations

------------------------------
Thanks,
Oktay Kemal
CCR
------------------------------

Hi Mohammad,

Well, they've decided to move to an on-prem Engage solution. So far, they are happy.

Some others who did not grant all access had to add the IP addresses manually. It was a painful job.... 

Best Regards,

Oktay

 

------------------------------
Thanks,
OKTAY KEMAL
CCR
------------------------------

Original Message:
Sent: 05-20-2025 01:32
From: Mohammad Saad
Subject: AWS IP Pool and Our Angry Customers

Hello OKTAY KEMAL, 

Here I am after 5 years,How was the problem solved? We are facing the same issue with our client who is refusing to add/open all IP addresses on the firewall.

------------------------------
Mohammad Saad
Tech Engineer

Original Message:
Sent: 04-13-2020 12:23
From: OKTAY KEMAL
Subject: AWS IP Pool and Our Angry Customers

Hi Everyone,

I know that this question was asked a couple of times throughout the years and sadly left unanswered by all the community and Genesys representatives. On one of the posts, it was answered indeed but the answer was searching for a needle in a haystack.

Let me get to the problem...

After many sales and technical meetings, a customer happily decides to buy the GenesysCloud solution and starts building their self-service IVR.
Their IVR includes sending informational SMS' on some points. They use an ITSP's Web Service Interface for sending these SMS' with their current on-prem solution. There is a Telco Security Regulation that all ITSP should define the IP Ranges of the hosts calling the "SMS Send" service. It is enforced by the law. So all they did in the past was providing the IP address of their firewall to their ITSP and they were able to use the service by adding some FW forwarding rules.

Now they are trying to achieve the same on PureCloud. They created a Custom Data Action. It is simple I agree... But, the test failed because they forgot to provide the source IP address or addresses of the GenesysCloud or the AWS. The addresses from where this service will be called. They simply can't open this service to all/all as there is a serious penalty for that.

So, checking the documentation one ends up finding the https://ip-ranges.amazonaws.com/ip-ranges.json link. The one which when you open you get 16.000 lines of a JSON text file. Wow, imagine giving this to the customer's firewall admin or their ITSP and telling them to allow them all. Imagine their reply....

OK, so the one moves forward and tries to find the region where they are hosted. He learns it's Ireland and that it's in eu-west-1 (rds.eu-west-1.amazonaws.com). Filtering the big list with eu-west-1 he narrows it down to 224 entries. So there are 224 IP ranges that he needs to send to the customer. Think about it... "All you need to do to enable sending SMS is to allow a couple of IP Addresses." -Just a couple? "Yes, 224 IP ranges."
- How about the updates? I mean how do I know if AWS adds or removes a range? "Welllll....s***".

Is it just me or do you guys also think that Genesys needs to do something about this problem?

If nothing is possible for reducing the IP ranges at least a simple app published on the GenesysCloud developer or help sites would do some help to all. An app that gives a filtered list of IP addresses based on ones login and ORG information. An app that would maybe use the following output would really be helpful to all:  Get-AWSPublicIpAddressRange -Region xxxxx

Anyway, I just wanted to say that this problem is frustrating for our customers and damaging our successful sales and partner relations.

I wonder if there are others out there who agree with me.


#API/Integrations

------------------------------
Thanks,
Oktay Kemal
CCR
------------------------------

------------------------------
Mohammad Saad
Senior Technical Support Specialist
Abu Sharif Brothers Company LLC
------------------------------

Original Message:
Sent: 05-20-2025 13:29
From: OKTAY KEMAL
Subject: AWS IP Pool and Our Angry Customers

Hi Mohammad,

Well, they've decided to move to an on-prem Engage solution. So far, they are happy.

Some others who did not grant all access had to add the IP addresses manually. It was a painful job.... 

Best Regards,

Oktay

 

------------------------------
Thanks,
OKTAY KEMAL
CCR

Original Message:
Sent: 05-20-2025 01:32
From: Mohammad Saad
Subject: AWS IP Pool and Our Angry Customers

Hello OKTAY KEMAL, 

Here I am after 5 years,How was the problem solved? We are facing the same issue with our client who is refusing to add/open all IP addresses on the firewall.

------------------------------
Mohammad Saad
Tech Engineer

Original Message:
Sent: 04-13-2020 12:23
From: OKTAY KEMAL
Subject: AWS IP Pool and Our Angry Customers

Hi Everyone,

I know that this question was asked a couple of times throughout the years and sadly left unanswered by all the community and Genesys representatives. On one of the posts, it was answered indeed but the answer was searching for a needle in a haystack.

Let me get to the problem...

After many sales and technical meetings, a customer happily decides to buy the GenesysCloud solution and starts building their self-service IVR.
Their IVR includes sending informational SMS' on some points. They use an ITSP's Web Service Interface for sending these SMS' with their current on-prem solution. There is a Telco Security Regulation that all ITSP should define the IP Ranges of the hosts calling the "SMS Send" service. It is enforced by the law. So all they did in the past was providing the IP address of their firewall to their ITSP and they were able to use the service by adding some FW forwarding rules.

Now they are trying to achieve the same on PureCloud. They created a Custom Data Action. It is simple I agree... But, the test failed because they forgot to provide the source IP address or addresses of the GenesysCloud or the AWS. The addresses from where this service will be called. They simply can't open this service to all/all as there is a serious penalty for that.

So, checking the documentation one ends up finding the https://ip-ranges.amazonaws.com/ip-ranges.json link. The one which when you open you get 16.000 lines of a JSON text file. Wow, imagine giving this to the customer's firewall admin or their ITSP and telling them to allow them all. Imagine their reply....

OK, so the one moves forward and tries to find the region where they are hosted. He learns it's Ireland and that it's in eu-west-1 (rds.eu-west-1.amazonaws.com). Filtering the big list with eu-west-1 he narrows it down to 224 entries. So there are 224 IP ranges that he needs to send to the customer. Think about it... "All you need to do to enable sending SMS is to allow a couple of IP Addresses." -Just a couple? "Yes, 224 IP ranges."
- How about the updates? I mean how do I know if AWS adds or removes a range? "Welllll....s***".

Is it just me or do you guys also think that Genesys needs to do something about this problem?

If nothing is possible for reducing the IP ranges at least a simple app published on the GenesysCloud developer or help sites would do some help to all. An app that gives a filtered list of IP addresses based on ones login and ORG information. An app that would maybe use the following output would really be helpful to all:  Get-AWSPublicIpAddressRange -Region xxxxx

Anyway, I just wanted to say that this problem is frustrating for our customers and damaging our successful sales and partner relations.

I wonder if there are others out there who agree with me.


#API/Integrations

------------------------------
Thanks,
Oktay Kemal
CCR
------------------------------

Generally the information you're looking for is on this page: https://help.mypurecloud.com/articles/ip-addresses-for-the-firewall-allowlist/

Depending on the specifics of your request, it may indeed be possible to limit access to your resources based on IP address (see the section just above the table discussing Data Actions, Open Messaging, SMTP, etc.)

------------------------------
Richard Schott
Product Manager
------------------------------

Original Message:
Sent: 05-21-2025 01:37
From: Mohammad Saad
Subject: AWS IP Pool and Our Angry Customers

Hi Octane,

Do you mean we don't have a way to narrow down the IP list or specify an IP for a specific region?

 

And the customer must manually add IP addresses to the firewall.

 

I think this is a huge and unacceptable obstacle.

regards,
Mohammad Sa'ad

------------------------------
Mohammad Saad
Senior Technical Support Specialist
Abu Sharif Brothers Company LLC

Original Message:
Sent: 05-20-2025 13:29
From: OKTAY KEMAL
Subject: AWS IP Pool and Our Angry Customers

Hi Mohammad,

Well, they've decided to move to an on-prem Engage solution. So far, they are happy.

Some others who did not grant all access had to add the IP addresses manually. It was a painful job.... 

Best Regards,

Oktay

 

------------------------------
Thanks,
OKTAY KEMAL
CCR

Original Message:
Sent: 05-20-2025 01:32
From: Mohammad Saad
Subject: AWS IP Pool and Our Angry Customers

Hello OKTAY KEMAL, 

Here I am after 5 years,How was the problem solved? We are facing the same issue with our client who is refusing to add/open all IP addresses on the firewall.

------------------------------
Mohammad Saad
Tech Engineer

Original Message:
Sent: 04-13-2020 12:23
From: OKTAY KEMAL
Subject: AWS IP Pool and Our Angry Customers

Hi Everyone,

I know that this question was asked a couple of times throughout the years and sadly left unanswered by all the community and Genesys representatives. On one of the posts, it was answered indeed but the answer was searching for a needle in a haystack.

Let me get to the problem...

After many sales and technical meetings, a customer happily decides to buy the GenesysCloud solution and starts building their self-service IVR.
Their IVR includes sending informational SMS' on some points. They use an ITSP's Web Service Interface for sending these SMS' with their current on-prem solution. There is a Telco Security Regulation that all ITSP should define the IP Ranges of the hosts calling the "SMS Send" service. It is enforced by the law. So all they did in the past was providing the IP address of their firewall to their ITSP and they were able to use the service by adding some FW forwarding rules.

Now they are trying to achieve the same on PureCloud. They created a Custom Data Action. It is simple I agree... But, the test failed because they forgot to provide the source IP address or addresses of the GenesysCloud or the AWS. The addresses from where this service will be called. They simply can't open this service to all/all as there is a serious penalty for that.

So, checking the documentation one ends up finding the https://ip-ranges.amazonaws.com/ip-ranges.json link. The one which when you open you get 16.000 lines of a JSON text file. Wow, imagine giving this to the customer's firewall admin or their ITSP and telling them to allow them all. Imagine their reply....

OK, so the one moves forward and tries to find the region where they are hosted. He learns it's Ireland and that it's in eu-west-1 (rds.eu-west-1.amazonaws.com). Filtering the big list with eu-west-1 he narrows it down to 224 entries. So there are 224 IP ranges that he needs to send to the customer. Think about it... "All you need to do to enable sending SMS is to allow a couple of IP Addresses." -Just a couple? "Yes, 224 IP ranges."
- How about the updates? I mean how do I know if AWS adds or removes a range? "Welllll....s***".

Is it just me or do you guys also think that Genesys needs to do something about this problem?

If nothing is possible for reducing the IP ranges at least a simple app published on the GenesysCloud developer or help sites would do some help to all. An app that gives a filtered list of IP addresses based on ones login and ORG information. An app that would maybe use the following output would really be helpful to all:  Get-AWSPublicIpAddressRange -Region xxxxx

Anyway, I just wanted to say that this problem is frustrating for our customers and damaging our successful sales and partner relations.

I wonder if there are others out there who agree with me.


#API/Integrations

------------------------------
Thanks,
Oktay Kemal
CCR
------------------------------