How to organize a VPN for remote employees without routing unnecessary traffic?

Question

FreeBSD

Good afternoon!
Such situation.
There is a server with FreeBSD as a router. Behind it is a network that has a terminal server for Windows.
Until recently, FreeBSD forwarded a port to the terminal server so that employees working away from the office (at home, for example) could connect to the terminal server.
We came to the conclusion that it is not safe.
We decided to raise VPN and remove port forwarding.
They did so.
1. IKEv2 server net/strongswan was raised on FreeBSD with authorization via RADIUS.
2. Each employee has a VPN connection configured on their home computer using the built-in Windows tools (from 7 and above, since there is no support for IKEv2 below). In the connection settings, check the "use the gateway on the remote network" checkbox.
Question: how to get away from routing unnecessary traffic by the FreeBSD server without a rake?
To clarify: I want a user with a connected VPN to be able to download torrents safely through his Internet channel, bypassing a working VPN server, but at the same time access to the resources of the internal network of the enterprise (for example, to the terminal server) must be via VPN.
I understand that it is necessary to look towards routing. I know that it is possible to manually write routes on client computers, but I do not think that this is a beautiful solution. Maybe it's possible to pass routes from the server? On any OS?
Maybe we initially chose the wrong path?
Thank you.

Answer 1

IPsec has policies -- what traffic to wrap in the tunnel. Write on the server side the IP subnet in which your corporate resources are located, and this traffic will automatically be wrapped in a tunnel for clients. Everything else will go past the tunnel, directly through the client channel.
Dig towards the leftsubnet / rightsubnet parameters in the strongswan config.

Answer 2

Until recently, FreeBSD forwarded a port to the terminal server so that employees working away from the office (at home, for example) could connect to the terminal server.
We came to the conclusion that it is not safe.
We decided to raise VPN and remove port forwarding.

Why VPN to connect to a terminal server?! Read

Answer 3

They wrote to you about the jackdaw.
And then, in order to have a route to the north of the terminals on the client device
1. create a connection for them via CMAK ( https://habr.com/post/186674/ ), and configure any static routes in it.
2. Enable the RIP listener for all clients and run the rip daemon on the fryah to distribute routes.
The advantage of the second solution is that clients will not have to do anything if something has changed with you.

Answer 4

athacker wrote the right idea, but, unfortunately, Windows is Windows.
windows client for VPN (except W10, judging by the documentation) directs all (0.0.0.0/0) traffic to the tunnel by default and this can lead to some inoperable situations.
In fact, with Windows, the only guaranteed solution that works (no surprises) is to use the powershell cmdlet add-vpnconnectionroute which, when the VPN connection is up, will pick up the correct route to it.
Well, accordingly, create a VPN connection not with your hands, but with a powershell script.
More details - in the strongswan docks https://wiki.strongswan.org/projects/strongswan/wi...

Answer 5

Clients in the connection properties have a checkbox "Use the default gateway on the remote network". it must be removed. the corresponding command in netsh also seems to be available. Well, there is definitely a parameter for PS: -splittunneling.

Answer 6

And why did you check the box "use the gateway on the remote network"? If you need access to only one terminal server or a specific subnet, then it's easier to write one route rather than using a vpn gateway. On Windows, this is done as a "route add" and the syntax of the command can be read further.
I really had a problem, if you add a static route, and vpn breaks for some reason, then after the connection was restored, the route did not work. I solved it with just a scheduler. On the vpn connection event in the event log, a script was launched that deleted old routes and added new ones.
But it was a long time ago. Maybe now there is no such problem.
Some other vpn servers can push routes themselves. But I don't know how it will work with a standard Windows VPN connection. It seems that OpenVPN can do this.
PS. You can also use port knocking. If access is needed only to the terminal server.