function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
NightFoxNightFox 

Salesforce IP Range and Domain Whitelisting

Hi All,

Salesforce IP Range and Domain Whitelisting

During an integration with a 3rd party system, I have come across the issue, "Whitelisting the Salesforce IP Ranges and Domains". 
Salesforce knowledge article says and listed out several IP Ranges (eg: 182.50.78.5 - 182.50.78.15 - one of the APNIC range) to be whitelisted.

Here is my question, if the given(by Salesforce) IP's( 182.50.78.5 - 182.50.78.15 ) are whitelisted, all the organisation(Salesforce Org) lies in AP(Salesforce Asia Pacific Server) and whichever the organisation(Salesforce Org) using the same IP range to communicate with other system can have the access to our Server as well.
Hence, there is loophole and our Server firewall is exposed for all Salesforce Org's. This will not actually work not a right approach. 

We have to make sure that the request is coming from a authorized Salesforce Org. Is there anything we can get like a specific IP for one Salesforce Organisation? Something like this is necessary to make the Integration successful.
Please suggest me a good solution. 

Is it possible to whitelist the Custom Doimain Name "<mydomain>.my.salesforce.com"?

Regards,
Saravana.
 

LBKLBK
Are you talking about whitelisting Salesforce Domain in the 3rd Party system?

Because, it salesforce you need to whitelist the 3rd Party System's IP address and URL, not the Salesforce IP Addresses and URLs.

If your 3rd party system allows custom domain URLs to be whitelisted, your "MyDomain" would be the ideal URL to whitelist (along with the IP Block of the server of course).
@GM@GM
Hi Saravana,

If its a integration then you will add your external URL in the remote site(request from that Https will be accepted) & if the login method is password/JWT/Oauth 2.0 then you will provide the security token to get the access Token. so there is no loophole in the login meachnism & accessing your API's in SFDC integration.

The whitelisting IP will avoid the rerouting to a rogue website and prevents any internet traffic intended for Salesforce but still we need to prove ourself by providing required credentials(as per your org login policy) to access the sfdc org.

For example, We have whitlisted an IP of my office network in my org so whenever i login from the office network it wont trigger code(4 digit) to email in order to prove myself but when i does same from my home network it will trigger. I need to provide my credentials in both senarios.

Regards,
GM
 
Lokesh KumarLokesh Kumar
HI Sarro,

To get rid of this you have to whitelist all the IP'S from the systems of API's for more please refer the below URL.

https://help.salesforce.com/articleView?id=000003652&type=1 

Thanks !
NightFoxNightFox
@LBK 

Yeah, Im talking about whitelisting Salesforce Domain name or IP Ranges in 3rd Party system(.Net, Java, Etc...) 

Have you ever done domain whitelisting in 3rd party system's Server?


Regards,
Saravana.
 
LBKLBK
Hi Saravana,

If this 3rd Party application is installed On-Premise within your network, your IT team should be able to help you.

For, cloud -based off-premise applications, your service providers should be able to help you out.

Can you tell me which is this 3rd Party application you are talking about?
Sameer Matale 17Sameer Matale 17
Hi Saravana,

I am facing same issue. Can you share what approach did you take to workaround whitelisting all IP addresses?

Thanks,
Sameer S. Matale
Sameer Matale 17Sameer Matale 17
Hi Saravana, were you able to whitelist on the basis of domain? what domain addresses you whitelisted?
Frans FlippoFrans Flippo
IP whitelisting is never a comprehensive security measure. It's a nice extra layer of defence, but you should always have strong authentication on your systems if they are to be secure -- with either certificates, SSH keys, or strong passwords, so that the "client" system (Salesforce in this case) can prove to the "server" system (your 3rd party system) that they are who they claim to be and the server system can verify that they are indeed allowed to be let in.

Also, don't forget that your server system needs also to prove they are who the client system thinks they are. SSL is the go-to mechanism here: the server certificate proves that the server is what their DNS name (e.g. api.mythirdpartyapi.com) says they are. Without this, the client risks giving their credentials to an untrusted party.

Additionally, you should run penetration testing on your API to make sure that there are no ways to circumvent the authentication and get access to the system without having a valid cert/key/password.

This is not unique to Salesforce, obviously; it applies whenever you integrate two systems.