You're ignoring the reality that most enterprise software is a tire fire (from a security standpoint) and that it's not feasible to secure hundreds (or even dozens!) of enterprise apps.

VPN's are the enabler that ensures status quo remains.

I agree — band-aids aren't per-se a bad thing. However, a VPN isn't the ideal end state. Even if you can't modify the underlying application, the goal should be "wrap in a reverse-proxy that handles authn / some-amount-of-authz so you can minimise the risk".

VPNs handle network security, but don't protect you against an attacker able to compromise an endpoint in your corporate environment.

Can you propose an alternative solution?

Some protocols/services are designed with a local network in mind and would require modifications to work on the internet. A VPN is invisible to the apps and can easily save a lot of work in a large IT environment with numerous internal services.

You're probably alluding to things like PXE or mDNS, or some proprietary industrial control protocols? This is true but deploying a VPN to cover them is a pretty high price to pay in operational complexity and security cost. There's usually other ways to address the task at hand.

How is a local network different from the internet, presuming there is no firewall or nat between the client and the server ?

On a local network, you make the assumption that there are only authorized users.

Uh oh, that assumption is a big no no.

depends

Can you elaborate? Honestly asking.

I wouldn't recommend it with PCs, notebooks, phones, random crapware, but:

When you control¹ all the devices on the network, the network is small enough and the danger from the non-authenticated protocols isn't too high, then I would say it is reasonable to assume being present in the network is sufficient authentication. Not saying it could not be improved, but there are probably many more pressing concerns.

¹ you don't fully control anything anymore, but you're not going to fix that either.

The air gapped power plant networks I work on have unused Ethernet ports shut off and the ones in use only accept traffic from the MAC address of the device that is meant to be there. So you can’t just show up and plug in.

Thanks a lot. That gave some perspective. I'll keep that in mind.

> presuming there is no firewall or nat between the client and the server

That's one of the issues though. If you can't access a machine via its internal IP, many useful usage patterns break.

Someone complained that the issue is that services aren't secure, but there's more to it than that: good security depends on defense in depth, and firewalls are an important part of that.

Yep, using VPNs makes the organisation lazy in security. But insecure apps in a "company internal network" is still not ok IMO. In the exceptional cases that you can't fix, the way to go is separate dedicated environments for the risky apps, and disconnected from central services.