No worries, meant TLC sorry! ( tender loving care )
Local users in your config do use the local WAN for internet, there is no way for them to use wireguard based on the config, so not a concern.
a. since the wireguard interface is part of the LAN interface list and
b. you have a rule allowing LAN interface list to go out the WAN interface list, those roadwarriors will get WAN access and
c. LAN also has access to DNS on the router and thus can resolve www addresses as well in the process.
Your static IP is not the public IP of the VPS, that is the static IP of the cloud device, NOT your router. Your router has a cgnat type of IP address that is not public.
+++++++++++++++++++++++++++++++++++++++
You have two options.
a. any external user that needs access to a LAN or tigo/huwaie device, can be given a wireguard account and through firewall rules allowed to reach their proper destination.
(safest)
b. you can port forward at the VPS, through the tunnel, to the MT device.
If the VPS is a MT device..
- need input chain rule for allowing wireguard handshake
- need forward chain rule to allow port forwarding
- need input chain rule to allow admin road warrior to config vps ( or admin local IPs on MT router ) via source address list
- need forward chain rule for other road warriors to connect to vbs and relay onward to MT device ( to access subnets, or internet out starlink )
- need routes for all subnets on MT device that will be reached by any user wireguard and/or port forwarding
- need forward chain rule to allow port forwarding
- IF doing port forwarding, then recommend that all traffic leaving wireguard tunnel headed to MT be sourcenatted to wireguard IP of VPS.
In this way all source addresses will be accepted at the MT as they will all be given the IP address of the VPS wireguard.
Typical port forward rule
/ip firewall nat
add chain=dstnat action=dst-nat dst-address=publicIPofVPS dst-port=serverPort protocol=AsReq to-address=IP-MT-Server
At the MT, ensure that the wireguard traffic is allowed to the server.