Jim brings up a very good modern alternative to VPNs, of any kind (?), SD-WAN.
Below are 3 references, I quickly found, comparing them.
https://lightyear.ai/blogs/sd-wan-vs-vpn
https://www.fortinet.com/resources/cyberglossary/sd-wan-vs-vpn
https://digitalcarbon.io/blog/sd-wan-vs-ipsec-vpn/
I've only skimmed the above references, but I suspect, each touts SD-WAN as the next best thing; and they might be right.
However, my experience in Enterprise networks, the Enterprise, usually treats networks as a cost center. I.e. a necessary expense to carry on their business, but one of which they would like to do as inexpensively as possible (ideally zero cost). I.e. probably one of the primary reasons you'll find some Enterprise network devices, in operation, for decades.
For a SP, networking is their business, so they often do want the best so they can offer features to their customers. It's a whole different mindset, i.e. their networking is a profit center.
So SPs, and network vendors, will "push" the latest and best technology. Again, this doesn't mean what they are "pushing" is bad, just let's say their goals (i.e. increased revenue, for them) are not always best aligned with your Enterprise's "needs".
Laugh - story time (sorry if I've posted this one before - I don't recall)
Years ago, I was working a fairly good sized international software development company that, within the US, was using frame-relay. As WAN costs were an ongoing cost, and it always seemed we didn't have enough bandwidth, our major WAN provider suggested we consider moving to ATM. Why? Well, the same bandwidth link would cost about 25% less! Upper management, said, same for 25% less, do it!
Well the company very rapidly migrated frame-relay fractional and full DS-1 links to ATM, and the WAN slowed to a craw!
So, they assigned me to the determine what the problem was.
Well for a FR (frame-relay) link, having 512 Kbps of bandwidth, it might have a FR CIR of 64 Kbps. (512 and 64 Kbps - hey, I did note this was years [cough decades] ago.) This meant, frames exceeding the CIR would be marked DE (discard eligible), but in the US, at DS-1 and less bandwidth, frames were almost never discarded.
For ATM, a "like" link (I recall) was provide a PCR (peak cell rate) of 512 Kbps and SCR (sustained cell rate) of 64 Kbps. Well, with ATM, the PCR is for a very short burst time, then the SCR is enforced on the (our) network device.
So, effectively, our usual 512 Kbps links were now only carrying 64 Kbps. This explained the massive slowdown.
We asked our SP what to do. They responded, oh, no problem, just purchase a higher SCR. That, though, made these ATM links considerably more expensive than FR! From the WAN SP, "We're sorry you didn't understand how SCR is enforced, unlike FR's CIR, but nothing else we can do for you." (Not totally true, as they were quite willing to discuss other extra cost optional features that ATM supported that FR did not.)
Anyway, doing some more digging into ATM, and finding it's the router enforcing the SCR, I asked, what happens if we set the SCR to the PCR value too? "ATM cells over the SCR rate, will be marked discard eligible and may be dropped. (Basically the same as FR's CIR, and in practice, again for DS-1 and less links, they didn't drop cells.)
So, we now had with our ATM links, effectively, what we had before with FR, but at 25% less cost, right? Well, no!
ATM has 53 byte cells, 48 bytes of which is payload (of the original packet). So, you immediately have lost about 10% of your bandwidth to ATM overhead.
Oh, and ATM cell are always 53 bytes. So, the last cell for a packet, on average, is likely only carrying 24 bytes your data, i.e. about 45% of the available bandwidth.
Oh, and if the ATM circuit, does drop a cell, it nicely sends to your far end, all the other cells. Unfortunately, at the IP level, the whole packet needs to be retransmitted again! Basically the same effect as getting a CRC error on the receiving end.
Oh, and of course we needed different interface modules to use ATM.
Oh, and of course, router IPBase didn't support ATM interface modules, so we had to upgrade IOS feature set. Which also, increased the maintenance cost too.
Oh, and networking staff had to learn the ins and outs of dealing with this new WAN technology. (For the engineer, that's good, engineers like learning new technologies, and something to add to the resume. For the Enterprise, engineers are now spending time on "learning" and not on other issues.)
Bottom line, with ATM, we loss bandwidth relative to the former FR.
Did we actually save 25%? No, but no one wanted to do a full cost comparison including the other incidental costs, but I doubt there was much of a net overall cost savings, if any.
Remember, whatever someone is trying to sell you - caveat emptor!
[edit PS:]
BTW, a few years later, WAN SP comes to us and says, you really should move to L3 VPN running on top of MPLS. Same bandwidth will cost less and it has so many other features, like QoS support . . .
Well, I won't say what upper management decided, but I guess I can mention, shortly later, I got called into look into certain "new" network issues. About that same time, I learned a lot about L3 VPNs.
As an aside, middle management, did ask my opinion of moving to the L3 VPNs, but upper management had already made their decision. I noted, well there's one pitfall I could see you running into. (Oh, and a couple of years later, why someone called me in to work on a major problem just like . . .)
