Sounds great.
Yes, not having a mikrotic CHR in the cloud its a bit harder to setup but sounds like you covered the bases.
So I will explain it from a CHR perspective since the request is valid.
Problem. Cannot reach MIKROTIK device due to ISP situation ( blocks port, non public IP and unable to port forward )
Need. For users to reach servers on the MIKROTIK device.
Solution1: Use another SITE (like VM cloud or friends home) for folks to aim their plain text server requests and then send that traffic in a wireguard tunnel to the MIKROTIK.
CLoud CHR:
WIreguard Server for handshake.
Peer Clients: include MIKROTIK ROUTER and admin remote devices ( to reach and configure CHR and to reach and configure MIKROTIK while away from router )
Firewall settings:
allow wireguard port udp 15535 (input chain)
allow port forwarding (forward chain)
add address=10.10.20.1/24 interface=wireguard1 network=10.10.20.0
Wireguard settings:
peer1 /32 wg address for mikrotik,ServersubnetA,ServerSubnetB - wireguardCHR - public key
peer2 /32 wg address for admin laptop - wireguardCHR - public key
ex.
peer3 allowed-ips=10.10.20.4/32 interface=wireguardCHR public key=“----” comment=“admin smartphone”
Two possibilities for handling external requests.
a. the server needs to see the original source address from user ( or admin wants to record that at server )
b. the server does not require to see the original source address and thus we can simplify traffic to the MT. RECOMMENDED
( one can always record the initial dstnat rule connections from users on the CHR, and thus have a list of external users )
a. no change
b. we sourcenat all the traffic leaving the wireguardinterface to the wireguard IP
( /interface list members add interface=wireguard1 list=WAN
( works with default rule add chain=srcnat action=masquerade out-interface-list=WAN )
Standard Port forwarding rule
add chain=dstnat action=dst-nat dst-address=CHRaddress dst-port=xxxxx protocol=yy to-address=192.168.44.12 comment=“To server subnet A on MT”
add chain=dstnat action=dst-nat dst-address=CHRaddress dst-port=bbbbb protocol=cd to-address=192.168.12.5 comment=“To server subnet B on MT”
/ip route
add dst-address=192.168.44.0/24 gateway=wireguard1 routing-table=main
add dst-address=192.168.12.0/24 gateway=wireguard1 routing-table=main
+++++++++++++++++++++++++++++++++++++
Mikrotik
Wireguard settings
Remember the two options above, the first was the server needs to see the addresses and thus when the server returns original addresses back through wireguard they need to include all possible addresses:
a. add allowed-addresses**=0.0.0.0/0** interface=wireguardhome endpointIP=CHR endpoint-port=15535 persistent-keep-alive=25 interface=wireguardhome public-key=“----”
Otherwise if all the traffic from wireguard appears to come from the single IP address then the allowed ip changes;;;;;;;;
b. add allowed address=10.10.20.0/24 interface=wireguardhome endpointIP=CHR endpoint-port=15535 persistent-keep-alive=25 interface=wireguardhome public-key=“----”
In both cases need.
/firewall rule add action=accept chain=forward in-interface=wireguardhome dst-address=ServerList
CaseA:
Where it gets tricky IMHO, is the return traffic for case A. that is because the originating IP address is unknown.
Therefore how do we ensure that the server traffic goes back out Wireguard tunnel and not to the local internet.
We use routing rules to ensure that this happens
/routing table
add name=useWG fib
/routing rule
add min-prefix=0 action=lookup-only-in-table table=main { ensures local traffic first between local users, when interacting with the servers on the MT, is permitted )
add src-address=server1 action=lookup-only-in-table table=useWG { rest of server traffic is sent back through the tunnel }
add src-address=server2 action=lookup-only-in-table table=useWG
…
add src-address=serverN action=lookup-only-in-table table=useWG
/ip route
add dst-address=0.0.0.0/0 gateway=wireguardhome routing-table=useWG
CASE B.
The source address of the incoming traffic is known to the router (as being part of the existing wireguard subnet) and thus no special accommodations need be made.
Traffic being returned by the servers is sent back through the wireguard interface to the cloud instance.
Option2.
Forget port forwarding. Use Wireguard directly from users to SERVERS!
Requires that you know the users and they are capable of setting up wireguard at that end.
They need a public key from your MT and you need the public key their end produces.
The firewall rules at the CHR ensure that relay is possible
add chain=forward action=accept in-interface=wireguardCHR out-interface=wireguardCHR
In other words, any Peer client TO Server is handled by the first part of the rule and then Server TO different peer client is handled by the second half.
One still needs the routes for the subnets of the servers on the MT device, so that
the router knows to send the first part of the rule back out out for the second half of the rule
/ip route
add dst-address=192.168.44.0/24 gateway=wireguard1 routing-table=main
add dst-address=192.168.12.0/24 gateway=wireguard1 routing-table=main
firewall rules at the MT decide which wireguard address can go to servers on the forward chain etc…
and which ones can go to Input chain for admin acccess.
