Now you are going overboard LOL.
Ahhh... a refreshing dip in the canal
Good suggestion!
Certainly the MT device with public IP is the main central point of your wireguard in terms of a site that can be connected to.
Once connected however traffic is peer to peer (two way tunnel - either side can originate traffic into the tunnel).
Concur that the MQTT wireguard on the left side (B) is not required.
Yep, I guess so, Wireguard at the left side of my scheme is not required, actually main purpose to set it up was to test if I was capable of getting wireguard up and running.
So on the left side of your diagram we can do all wireguard connectivity with the MT device.
Right!
On the right side, I dont know what is connected to the 4G, Im assuming its a router of some type that is NOT wireguard capable and thus you are using the MQTT device which has a wireguard capability as the remote site host for wireguard.
Correct. At the right side (for correctness that is in my explanation Server B) I have a 4G USB modem with no wireguard capabilities. The device to which it is connected is an Olimex Lime2 board with debian and wireguard. It also has a USB wifi device which funtions as hotspot for some sensors (temp, humidity,pir) feeding the system with mqtt payloads. Currently the mqtt messages are communicated with server C through an ssh tunnel.
Please confirm.
The issue being you haven really detailed your wireguard requirements and thus you have implemented wireguard really without a coherent plan.
a. identify user/device, groups of users/devices on the networks and note any road warrios that will be 'on the road'
b. identify what they should be able to do and NOT be able to do.
The reasons to set up a wireguard network are:
1. it seems to be fast, hopefully faster than my current setup with ssh tunnels, which are really slow
2. simplify secure connection to the remote system, which is now being done by accessing the remote ssh tunnel which is maintained by server B
3. enable future possibilities, eg accessing webcam/security cam
The 'users' are (should be) the connected sensors (connected through the wifi hotspot) and remote access using ssh for management. The idea is to move the devices from the local IP range (192.168.10.0/24) of server B to the wireguard network.