My friends, I recently had a little run in with the Salesforce IP Whitelist range. Allow me to explain.
I have recently been putting the finishing touches on a web-service that I've been putting together as a side project. This morning, I was planning to configure the whitelist to only accept incoming calls from Salesforce. I was logged into my Microsoft IIS account working on the project, and I just had to find the Salesforce network IP addresses that I wanted to whitelist.
I did a quick search: nothing. I was a little taken aback. This was extremely useful information that was proving increasingly difficult to find. It ended up taking me over 25 minutes to sift through search results on Salesforce.com to finally find the IP whitelist range.
As most of you know, IP whitelists are phenomenal for restricting access to a select group of IP addresses for a given server. This is a great security measure to implement in any scenario where you know you want to limit the group of people that can visit your site. In my case, I knew that I would eventually be connecting this web-service to my billing account when I put it on the market, so I wanted to be sure all of the information was secure. That meant restricting access to Salesforce.com users.
I've copied out the official Salesforce.com IP Address Range to Whitelist below in order to make sure that nobody has to waste time searching for it again.
The IP address spaces are as follows:
18.104.22.168/23 East Coast Data Center (set one)
22.214.171.124/24 East Coast Data Center (set two)
126.96.36.199/22 MidWest Data Centers
188.8.131.52/22 MidWest Data Centers
184.108.40.206/23 West Coast Data Center (set one)
220.127.116.11/23 West Coast Data Center (set two)
18.104.22.168/23 Singapore Data Center
22.214.171.124/22 Japan Data Center
Need help with the CIDR subnet notation? Here is a greate website I found that explains it.
Here is the link to the official Salesforce.com IP Address Range to Whitelist. Happy whitelisting!
Over the last week I started getting emails from a client with the following error message in in the salesforce.com log:
Unable to tunnel through proxy. Proxy returns "HTTP/1.0 503 Service Unavailable"
Now, everything I read told me that this was had something to do with the firewall but I wasn't convinced (I setup the firewall, how could it be wrong?). What was more puzzling was that this just started to happen out of the blue in the last week. Why would I have not seen this before given that I had set the firewall up four months ago.
I have both a hardware firewall and the Windows firewall in place. The first place I looked was the Windows firewall. I went in and configured logging to show me both the successful and blocked attempts. What I was seeing was that the requests were making it out from the local web services over to Salesforce.com (verified this by going to Setup > Administration Setup > Manage Users > Login History). In the screenshot below, you can see the incoming requests.
If you look at the image above you can see that the inbound requests are coming in fine and are successful. What happened next though was that the inbound requests to Apex web methods triggered an outbound call to the external web-services. Those outbound calls resulted in the "unable to tunnel through proxy" error. Again, this didn't make much sense to me on the surface because I hadn't seen this before with other customers.
After an hour of digging through the firewall logs I found the issue. When I configured the hardware firewall the web interface on it accepted my subnets as I entered them but saved them differently. I went back to the Salesforce.com IP Whitelist and re-did all the IPs with a fresh set of eyes while looking at the CIDR subsets and things just started to work. The Windows firewall had been correct but the hardware firewall was not. So, the system was able to make outbound calls but it was blocking the inbound ones for certain salesforce.com customers.
So, it was in fact a firewall issue. I don't think I had hit it before because we hadn't hit any of those IP blocks that were configured wrong.