I have seen the video about using a VPN by TKSJa (a youtube channel based on mikrotik tutorials) here is the video: https://www.youtube.com/watch?v=QWLY5vdKV4c

However this was released 5 years ago and I am just wondering if this is still the recommended way to VPN into a remote network.

The usage of VPN will be to allow remote workers to VPN into our internal LAN, where there is a file storage NAS. Pretty much the only reason we will set up the VPN is for this server to be accessible to remote workers. They have word, excel, outlook and all other phone services and everything else they need on their own PC. The only thing they can't access is the file server.

If anyone has any recommendations let me know.

For road warrior setups, i would suggest either L2TP/IPsec or Wireguard...
https://help.mikrotik.com/docs/display/ROS/IPsec
https://help.mikrotik.com/docs/display/ROS/L2TP
https://help.mikrotik.com/docs/display/ROS/WireGuard

For road warrior setups, i would suggest either L2TP/IPsec or Wireguard...
https://help.mikrotik.com/docs/display/ROS/IPsec
https://help.mikrotik.com/docs/display/ROS/L2TP
https://help.mikrotik.com/docs/display/ROS/WireGuard

Thank you I will try Wireguard

Wireguard is fairly easy and works well.

MT device act as a server and gets a wireguard address
address=10.10.10.2/24 interface=workwireguard

All clients get wireguard IP addresses within that subnet
remoteworker1 address=10.10.10.3/32
remoteworker2 address=10.10.10.4/32
etc.....
The only exception is if its a MT router or device and then it gets
mt client device address=10.10.10.5/24

The settings for the wireguard on the client assuming like a pc or desktop version of wireguard.
- need the endpoint IP address of the Office WANIP
- need the port being connected too for the initial handshake,
- need the public key spit out by the MT Wireguard server settings
- need to set a keep alive setting such as anything between 20-50 seconds seems to be fine.
- need to set allowed addresses/IPs, which means what addresses will the client be seeking to reach on the MT server,
typically we put
a. the wireguard IP subnet and
b. any LAN subnets
and thus in this case = 10.10.10.0/24, Internal LAN (where lets say that internal lan on the MT server router is 192.168.50.0/24)

+++++++++++++++++++++++++++++++++++++++++++++

The MT router side is a bit more work,
need to allow the input chain to accept incoming traffic to the port

One needs to input for each wireguard peer for the single INTERFACE, the following,
- the public key from that client
- the allowed IPs/Addresses which in this case will be.
a. the assigned wireguard IP for each device, all should be /32 (including any mt client routers)
b. the incoming assigned LAN IP on source device ( like a laptop - single user behind another router )
c. the incoming assigned subnet on source device ( like from a router client - where a bunch of users are connecting )

Basically the idea here is that the traffic will be allowed to exit the tunnel at the server side IF the source IP of the traffic matches the list you create. We ensure the wireguard IPs are included to facilitate pinging and continuity checking, and for single users on something like an IPHONE, which has no pre-ordained source IP (such apps basically, in effect, source-nat the devices assigned sourceIP (like from public WIFI) to the wireguard IP for tunnel traffic). For devices with a known source IP, laptop on a subnet behind another router, we should identify that IP or its subnet and for clients that are routers perhaps with a bunch of users, the entire subnet.

This is typically the most difficult step in the process, which is easily done if you plan well and know the requirements.
Note: If the clients were going to go out the MT Servers internet connection, then the allowed IP setting would be 0.0.0.0/0 which includes the above entries and thus they, in this scenario, would not be required (redundant).

One other consideration on the MT Server Router are firewall rules.
a. to allow admin remote access to configure the router would require an input chain rule.
b. to allow remote users to access LAN device, a forward chain rule or rules to do so.............. as discriminating as you need.
add chain=forward action=accept in-interface=workwireguard dst-address=localLANsubnet src-address=clientSourceIP or src-address-list=authorized

You may break it down further........ by stating a specific only device, dst-address=deviceIP

Finally, the last consideration is Routing..........
In this case the construction of the wireguard network is such that necessary route is created automatically by the router and covers any return traffic that needs to come back into the tunnel to the client
<DAC> dst-address=10.10.10.0/24 gwy=workwireguard table=main

+++++++++++++++++++++++++++++++++++++++++++++++++++

Where this gets tricky is if you want LAN subnets on the WIreguard Server to reach to some of the clients, this is not necessarily typical for remote warriors, but as per the example above, its very possible to have an MT CLIENT router in the mix and it may have LAN subnets that users on the MT Server router may need to reach. A discussion for another day,
but right away one gets the sense that
Allowed IPs on the MT server will need to identify that,
Firewall rules will have to allow local MT Server subnet folks to head toward the tunnel gateway unsolicited, and
One will have to add a route pointing such users to the tunnel vice somewhere else.

viewtopic.php?t=182340

TheLorc said:

Thank you I will try Wireguard

Just a note if you did not see it, WireGuard requires RouterOS version 7.

That seems like quite a lot of configuration... Did not think it would take that much config, but ill give it a go

The configuration is the easy part, the proper planning is what takes time but if done properly, its like butta!!