Scaling up to tens of hundreds of IPSec tunnels and alternative methods of secure transactions

Question

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?

Answer 1

I've been on the other side of this - signing up to be one of many many partners to a big company, and we had to get an IPSec tunnel. They way it worked was :

1. I got a form to fill out detailing my network layout, including which subnets would need to access our new big partner
2. They sent a VPN device, preconfigured and totally locked down
3. I had already assigned it a public IP, so I plugged it in where it could use that
4. My company paid a small fee to Sprint to manage it

I know that the tunnel was locked down to only the port(s) required for the application.

The takeaway for you, in your position:

1. Farm this out if you can. There are companies that can handle the implementation and management for you
2. If you do this yourself, you're going to need to implement a rock-solid process for onboarding new partners
3. You should also standardize on a piece of client-side hardware

The other takeaway - FFS, just use a secured protocol. SSH/SFTP/HTTPS are all bog-standard and secure as hell - there are FIPS-compliant SFTP servers, for example.

Doing this via IPSec tunnels will either cost your team's time (which is money) or just plain money for a network management contract. If your business is not in a position to extract money in return from your new partners, just make the product/process secure to begin with.

If you're stuck with this, don't do it yourself, because you'll end up having to support every damned small shop that has a SOHO router and some dude on the inside who likes BitTorrent, and when the routers shits they'll be calling you to find out why your application is down.

Also - your specific question of dealing with overlapping private IP subnets is handled by additional complex NAT-ing, which you will also have to maintain. It's definitely not a show-stopper, it's just more work.