Field Maps fails to sync on iOS devices not on VPN

03-07-2022 07:33 AM
Occasional Contributor II

Strange issue that began occurring just recently (March 3, 2022)

Field Maps users are unable to sync changes made on iOS devices only from a downloaded map package hosted on Portal - Android devices continue to work normally. The error returned in the app is "Request Forbidden". This is not specific to any one map, or even any one portal in our organization - it happens only on all iOS devices (regardless of the iOS version) and regardless of the Field Maps version, and it is happening on different portals. The error only occurs if using a downloaded offline package and making edits - there is no error when downloading the package to the device and just viewing it, everything looks normal. 

Field Maps does work correctly on all iOS devices on Portal only IF they are on VPN.

Field Maps does work correctly on all iOS devices on AGOL regardless of VPN. 

So it appears the issue may be related to a recent policy change on our internal network, rather than anything to do with Field Maps or iOS. Digging into some of the logs a bit deeper, it appears there may be an error passing the token back to Server only when trying to sync edits made to an offline package.

Tracing the error backwards, it appears it may be happening before it reaches our internal DNS - as though something in the header may no longer being passed correctly, either in the Web Application Filter (WAF) , the DMZ Load Balancer or Apache Reverse Proxy. 

Has anyone experienced similar issues? This one looks like it may be difficult to troubleshoot, so any ideas about how to proceed are appreciated.

0 Kudos
4 Replies
Occasional Contributor

Just tested our Apple and Android devices and syncing offline edits is working OK.  

0 Kudos
Occasional Contributor II

With some assistance from ESRI tech support we began digging through the IIS logs on the Portal machine to help pinpoint this issue.

It appears the the issue is may be with the Imperva WAF filtering external traffic accessing applications hosted on our cloud infrastructure.

The following POST request is not making it to our IIS server when users are not on VPN.

Example of the POST command logged in Windows IIS that is successful when a user is on VPN:

"2022-03-09 23:05:02 POST /server/rest/services/Hosted/Basic_Field_Notes/FeatureServer/uploads/upload - 443 - ArcGISRuntime-iOS/100.13+(iPadOS+15.3.1;+iPad6,4)+arcgis-fieldmaps/21.4.0+(7F99388A-C4AF-43B7-A8E7-A1DDC9643F55) - 200 0 0 513"

If the users are on VPN the POST request makes it to IIS, and the application performs as expected. If they are not on VPN this Post request never makes it to IIS and does not show up in the log. 

We suspect it's some combination of the word "upload" and/or the ArcGISRuntime-iOS headers that is causing the WAF to think this is bad traffic and filter it out.

Interestingly the notes on this web page indicate the Imperva WAF settings in existing customer accounts are being migrated to new WAF rules beginning in March 2022, so this may be related to the problem since it just started in March 2022.

We are still investigating the issue. 

0 Kudos
New Contributor II

@AdminAccount2  did you ever find a resolution for this? seeing similar issues, also going through a Imperva WAF.

0 Kudos
New Contributor III

Morning, We are experiencing something similar (Sort of)


We have organisation iPADs with both Field Maps and Collector installed. We run Mobileiron on these devices. Frequently users are getting the following error "cannot connect to GIS Portal as iPAD is not connected to the internet"

Yet the iPAD is connected to the internet as everything else is working


User can be half way through using the app, capturing data and then all of a sudden it throws that message. Beginning to get frustrating now.


I know it isnt anything on the ESRI side as I can jump on access same maps on my Samsung (with no mobile iron) or even a different iPAD with Mobileiron and it will work.


Not sure how to even start looking at what may be causing the issue on Mobile iron side of things


0 Kudos