Well, because there is only so much you can do to protect the VPN server itself. So I’d say only use secure protocols, encryption and authentication methods. The rest happens on the client side, so maybe only install the VPN client on company-managed and hardened client devices, where ideally the user (and potential malware) never has access to the configuration and keys/credentials, and use some sort of HW key/SmartCard as a second factor.
However, security shouldn’t stop at the perimeter, so you also need to think about the security of your infrastructure once someone has successfully connected to the VPN, and there were actually some answers to that. For example, that users only have access to what they really need, and that they still need to authenticate to the services behind the VPN. Basically the same things you should be doing with local users and client devices, but in an even more restrictive way. Things like network segmentation with restrictive firewall rules, 2FA or hardware keys for authentication to your services, jump hosts for accessing management interfaces, etc.
If you’re looking for more automation and granularity, you probably need some kind of Identity and Access Management (IAM) system. But then we quickly get into enterprise territory where we are no longer talking about a single Fortigate or pfSense box managing the entire network, including VPNs
We’re talking about 30 minutes of work, an hour at most. Most clients likely have (or should have) a hub-spoke network design, so no need to build more than one tunnel. You would have to build the routes though. But still, that is 5-10 minutes per router. An experience tech should be able to do this in under an hour with a light buzz.
I figured MSP’s were building tunnels for admin use anyway. I guess not. I guess just simple IP based FW rules, huh?
Yes, please. How is exposing a web based portal with root access into every PC and possibly server for a client not worth 1 hour of MSP’s time? Hell, make it two hours.
Also, keep in mind you are adding that exposure to said business given they likely did not have this (if they used it) exposed to the world for your convenience before they hired you. This is a significant jump in their attack surface. It doesn’t matter if you patched, it is still a massive jump in attack surface. I’d rather have you expose the pfsense login to the internet than this. Take my router over before you take over my PC or my CEO’s PC.
VPN overhead is not that taxing. But yes, a MSP should have a separate VPN server for isolation benefits. Running the vpn on a big pfsense box would be a junior admin move, but given my low confidence in MSP’s now, they probably do just that.
Clearly you have not thought this all the way through @liquidjoe which is probably because you don’t do this in large scale production environments. It’s more than just setting up the VPN it would also mean making sure that there are not any overlaps in the network routing between all of these clients, which is why it’s just not a practical solution.
We don’t need to open ports or use VPN’s on clients networks to admin them because we have other tools that allow us to do this, here is a full list of them as of September 2023:
Using OpenVPN on a pfSense box in a small business is perfectly fine imho. It doesn’t expose a web interface or anything, so the attack vector is kept to a minimum, and therefore a separte VPN server it is not inherently more secure.
In terms of exposing management interfaces and things like ScreenConnect, SaaS is going to be the solution to that whether we like it or not. Of course, there will be security issues with SaaS providers too, but then it’s easier to blame them than if you were hosting the product yourself…
Yep, I am not in the MSP biz and have only given it 1 cup of coffee worth of thought. You’re right, the VPN route would not scale well in this environment. A cheaper and simpler solution would be to just restrict access on screen connect’s FW to the client gateway IPs. Remote warriors would have to tunnel into their respective offices for this service, and that might be a pain, but having this service out there on the internet exposes a big attack surface.
I have the strong impression that most MSPs just have screen connect server sitting out on the internet. Super convenient and cost effective, but bad security design. Not sure I would feel much better about SaaS either. But clearly nobody cares about this stuff too much anyway.
What about SNAT or policy based routing via tagging?
Now I am just curious. This problem seems to have a few solutions. I am sure some people have tried the two above to solve a similar problem.?. Wish I had an excuse to play around with this stuff.
Not expecting a response on any of this. But I still think a MSP should hide their screen connect server from the world. Feel free to correct me if I am wrong, naive, and/or just incompetent. All old friends of mine.
This is something I have had to manage in a previous role. We did managed services for larger companies for specific hardware that was implemented in those company environments. There was very little overlap on what was considered acceptable remote access according to customer security teams.
Policy-based IPSec was out, because at a fundamental level it prevented failover i.e. if we had two WAN addresses, the customer then had to manage a routing conflict because our jumpbox network stub on our side was now on two policies i.e. a routing conflict. We dealt with that by essentially having two jumpboxes with different gateways, one for each WAN connection.
Route-based site to site failover with BGP was a possibility, but no customer wanted that. Honestly I spent a month liaising with a group while they tried to figure out a standard IPSec VPN setup that would talk to our racoon/openswan implementation. SDWAN is all the rage now, but back then you had to work hard to have a dynamic failover of route-based IPSec.
We also had customers that wanted to dictate our range, which we refused, because it interfered with other agreements. I think at some point I implemented source based routing through IPROUTE2 for specific customers so I could do this with ip aliases.
We had a customer that set up a jumpbox network in our environment, and we had to be physically at that console to support them (very very big telco). It was in our best interests to adhere to that requirement.
For other customers, in the end as you suggested, we used the reserved carrier NAT range for SNAT.
All this was managed on linux boxes and early pfsense implementations.
Bigger customers would have different security teams for operations and firewalling/VPN, so operations security might say yes but firewalling/VPN would refuse changes to the edge.
No customer wanted a jumpbox in their environment that we could use to get to where we needed to go, because it was more power/maintenance/rackspace and as far as they were concerned, there were software solutions, which almost brings us back to where screenconnect comes in.
