I may have a need to add (to start) 10 IPSec tunnels in a hub-spoke design, whereas communication is one-way (spokes -> hub only) for the purpose of collecting data in a central database server. Each transaction is small, perhaps 10Kb in XML data, and with each spoke initiating maybe 10-20 transactions an hour. Also I should note that I don't have control over the the spoke networks; all spokes have a static, publicly-routeable IP address; all spokes are really just a host behind a NAT firewall that needs to send data to the central database. The central database is behind a NAT firewall and for purpose of discussion, is on a 192.168.0.0/24 subnet.
My initial thought was that IPSec tunnels were overhead/overkill as I'd have to think about each spoke's network topology (which I don't control) as far as routes go not to mention the hardware required to sustain all these IPSec tunnels (especially if it scales up to hundreds).
However, I'm being "urged" to go with IPSec tunnels because they're the most "secure," but in my opinion, I feel like IPSec works great for a big trusted network or even mostly trusted LAN-to-LAN communications between branch offices, especially where you have complete control over the network topology, but not so much for a very narrow purpose and one that (I think) could be achieved with something like SSH tunnels or SFTP batch jobs (or possibly on-demand/mobile VPN?).
If I have to go with IPSec, how do I handle routes? I mean, if my central database is on a 192.168.0.0/24 subnet, and spoke A happens to have the same (or perhaps another tunnel somewhere else with that), how would I be able to resolve that? Static routes on each "sending" host might work, but what if that host needs to access that same subnet somewhere else?
If not IPSec, what would you recommend for securing transactions from peers to the central host?