Measuring latency of a long-distance SQL connection
Just to clarify some math here:


360 queries per "property"
60 properties * 360 = 21,600 queries
3 minutes in duration is about 120 queries per second


So in your best case, you're averaging 120 queries per second throughput.

After moving the SQL Server to somewhere that has a ping latency of 65ms, you're averaging 7 queries per second.

Your best bet is to 


measure wait statistics while this query is running


If you don't have a monitoring tool, a simple way to do this is running sp_BlitzFirst, an open source tool developed by Brent Ozar Unlimited.  It'll take a snapshot of your wait stats (among other things), wait 5 seconds, and then take another snapshot, and show you a summary of the biggest issues
You can also see the wait stats since the server started using a query like the one in Paul Randal's blog post: Wait statistics, or please tell me where it hurts

Once you've got those results, examine the highest wait stats, and use the SQL Skills wait stats library to dig into what they mean


Based on your description, it's likely that you'll see ASYNC_NETWORK_IO waits.  This can indicate slow network transfer.  But usually it means that the client application is doing row-by-row processing, and SQL Server is waiting to send rows (when it really wants to fire them over the network as fast as possible).

On a related note - in general, it would be far more effective to try to pull larger "groups" of data - rather than running 21,000 queries, and thus making 21,000 round trips over the (potentially slow) network.  This is called a "chatty" interface or API, and is generally considered to be an anti-pattern.  

Consider that 65ms * 21,600 queries is 1,404,000 ms, AKA over 23 minutes of overhead.  That's a big chunk of overheard that could be removed simply by limiting the number of roundtrips.