Wireguard for office, server, and remote workers

[Network noob here]
A friend of mine lives in a 3rd world country and has a server in his office that needs to be accessed by 3-5 remote workers in the USA. He has a Mikrotik router.
He recently changed ISPs and no longer has a public IP address, so now his remote workers don’t have access to the server.

I’ve offered to let him to use my Wireguard VPN server in the USA (static public IP address), but I have no idea how to set it up so that his server has access to the VPN and the remote workers can gain access to the server. (The rest of his employees don’t need to use the VPN, otherwise I’d just send him a configuration script to link his MT router directly to my VPN server). I tried looking up some Wireguard peer-to-peer solutions, but they’re more about connecting entire offices to each other, and what I need is just one computer (server) behind a private IP available for remote users to connect in to.

..or maybe I’m going about this all wrong?

Any pointers welcome.

Thanks.

One (cpu expensive) option.

The remote worker wireguard tunnel is put inside another wireguard tunnel between his Mikrotik router, and your vpn server. (Has advantage of End to End encryption)

  1. Run a new (outer) wireguard tunnel from his Mikrotik to your wireguard vpn server.
    (This sort of assumes your end is also a Mikrotik)

Your end of the outer wireguard interface would be setup as WAN (ie. Untrusted)
His end of the outer wireguard interface would also be setup as WAN (ie. Untrusted)

You would then port forward one UDP port (probably the inner wireguard udp port) on your main WAN interface via the outer wireguard tunnel to the inner wireguard udp port on his Mikrotik. (Which he has allowed in his firewall rules)

client would connect to your ip on the inner wireguard udp port.

If this works ok, you could perhaps make the outer tunnel an unencrypted openvpn tunnel, which might have better performance and mtu.

eg. inner port 12333, outer port 12444

Mikrotik makes outer wireguard connection to your vpn server on port 12444

client --> wireguard to udp 12333 on your router -> dst-nat (+ optional src-nat) to Mikrotik port 12333 Via outer wireguard.

The remote Mikrotik can route back via the outer tunnel easily if you src-nat traffic going to port 12333, however the remote Mikrotik then doesn't know the original source IP. (Probably do this during initial testing)

Alternatively, the Mikrotik can use mangling or other methods to get wireguard traffic coming in via the outer wireguard tunnel to return via the outer wireguard interface/tunnel without src-nat on your vpn server. It then will know the original client IP.

(Getting wireguard return traffic to leave via a specific non default interface is a common but slightly fiddly scenario, plenty of forum topics on it)

There are several options.
One can rent a server in the cloud, for like $7 US a month to tie everyone together ( the CHR is the host for the wireguard handshake ).
THe other option as you described is to host wireguard at your location and then all link up through your router instead. I will look more at this later.

Okay, Using your router will be secure and clear for all. We ensure his connections ( your friend on the road or at thome with: laptop/smartphone/ipad , and the office workers in the US as well from their client device( they may require laptop and pc etc) , do not have any path to any devices on your Router, or to your router.

ON YOUR ROUTER
Interface wg-EXTERNAL listening port 53222

/ip address
add address=10.50.70.1/24  interface=wg-EXTERNAL network=10.50.70.0 comment="worker vpn"
add address=10.0.20.1/24  interface=wg-EXTERNAL network=10.0.20.0 comment="friend/boss vpn"

/ip firewall 
add chain=input action=accept comment="External hand shake" dst-port=53222 \
    protocol=udp
add chain=forward action=accept comment="Relay"  in-interface=wg-EXTERNAL \
   out-interface=wg-EXTERNAL

The relay rule is just an efficient firewall rule for passing through the wireguard traffic. Since wg is point to point, we have to allow for the incoming point to point connection to occur and then to go back out the tunnel to the actual destination address.

/interface wireguard peers
add allowed-addresses=10.0.20.2   interface=wg-EXTERNAL public-key="-----" \
    comment="remote laptop-friend"
add allowed-addresses=10.0.20.3   interface=wg-EXTERNAL public-key="-----" \
    comment="remote PC friend"
add allowed-addresses=10.0.20.4   interface=wg-EXTERNAL public-key="-----" \
    comment="remote smartphone/tablet friend"
add allowed address=10.50.70.2 interface=wg-EXTERNAL public-key="++++"  \
    comment="worker 1"
add allowed address=10.50.70.3 interface=wg-EXTERNAL public-key="+-+-+"  \
    comment="worker 2"
add allowed address=10.50.70.4 interface=wg-EXTERNAL public-key="*-+*-+"  \
    comment="worker 3" 
add allowed address=10.50.70.10,routersubnetA,routersubnetB,routersubnetC \
    interface=wg-EXTERNAL public-key="^^^^^" comment="To Office Router"
/ip route
add address=subnetA gateway=wg-EXTERNAL table=main
add address=subnetB gateway=wg-EXTERNAL table=main
add address=subnetC gateway=wg-EXTERNAL table=main

The routes ensure that the router knows any incoming destined for those subnets is routed through the wireguard interface.

ON REMOTE MIKROTIK ROUTER.
interface=wg-OFFICE listening port = 44789

/ip firewall
add chain=input action=accept  comment="friend/boss access to office router" \
    in-interface=wg-OFFICE src-address=10.0.20.0/24 
add chain=forward action=accept comment="workers and boss to local subnets" \
   in-interface=wg-OFFICE dst-address**={entire subnet, or specific server}

** you could use out-interface to include multiple subnets or dst-address-list for a a list of devices vice subnets etc....

/interface wireguard peers
add allowed addresses=10.0.20.0/24,10.50.70.0.24 interface=wg-OFFICE \
   public-key="~~~~~"  persistent-keep-alive=40s  comment="To Host Router"

The idea here is that we are only expecting either the friend/boss or workers to arrive over the wireguard to this router. That is the gist of the config. Ensuring no access to your router means not adding anything to allow them to do so and if you have the correct approach of drop all else rules at the end of your input and forward chains, its done.