If the IP address is a public IP address (pingable etc) then it should be very dodable using the latest 7 firmware is recommended 7.4.1 stable.
The basic ideas,
1. Decide on a Wireguard IP address structure.
Main MT device 10.10.10.1/24
Remote user1 10.10.10.2/32
Remote user2 10.10.10.2/32
Lets say a remote Router with subnets that does not have an accessible IP - 10.10.10.3/24
2. Establish the Wireguard Interface on the router.
Name of interface "
mywireguard"
Listening port where the router will accept an incoming handshake port 13321 or something is the default. Use this for any configs you post for help but use something different on the real config like 15575 etc...
The MT generates a private key which is nobodys business but yours....
The MT generates a public key, that is to be used at all peer remote end wireguard configurations.
For each peer that will be connecting up with the MT router you then need to define
( and remember this is for EACH peer, separately):
- the name already established above just use the pulldown menu to find "
mywireguard"
- public key (
THIS IS THE PUBLIC KEY GENERATED BY THE REMOTE DEVICE )
- Endpoint and Endpoint port: Not required for a remote site that does not have a publically accessible IP and who will not host a connection
(if there is another router in the mix and its possible it may host connections originating from the MT router then put then
a. put in the static fixed wanport IP of the remote router, OR
b. if dynamic use the dyndns url/domain name and the MT router will resolve this name to IP for you)
- Allowed Addresses.
This is key, for each remote site that will coming into the MT router, put in the IP address for example in this case,
=10.10.10.2/32 peer1
=10.10.10.3/32 peer2
=10.10.10.4/32 peer3
Now if peer3 (another MT device) has a subnet that will be coming into the local MT router (192.168.10.0/24), or if you have users on your MT router that want to visit the Remote subnet, you need to also add the subnet..........
=10.10.1.4, 192.168.10.0/24
Note: Peers cannot have overlapping subnets or entries as that creates issues. If this happens consider establishing another wireguard inteface.
- Preshared key is not used
-Persistant keep alive would only be used if one was connecting to that Peer originally so possibly with peer3 you may enter in a keep alive, lets say 25 secs....
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Lets say peer1 is an IOS device.
Settings at the TOP are like the MT WIREGUARD INTERFACE settings
name = whatever name you want to give the connection on the phone, WG-IOS
Public Key = THis is the public Key generated by the IPhone app, to share with the MT router (the MT router puts that on its peer settings for this device).
Address=This is the address of the iPHONe on the wireguard conenction which is 10.10.10.2/32
DNS servers = not 100% sure but safe to put in the IP address of the Router 10.10.10.1/24
Peer Settings On IOS device
- Public Key: This is where you put the public KEY from the MT Router.......
Endpoint: This is where you put the
staticIP:portnumber OR
dyndnsname:port#
- Allowed IPs:, this is where you put the IP addresses you wish the IOS user to reach on the MT router, and this could be just the wireguard address for pinging and access to the router
10.10.10.0/24 (is the best entry here because then you can ping other devices connected to the Router via wireguard) and add any subnets you may wish to reach on the router
Lets say the LAN subnet on the MT router is 192.168.0.0/24, then on the IOS user you would have
allowed addresses= 10.10.10.0/24,192.168.0.0/24 AND lets say you wanted access to the OTHER MT devices subnet just add 192.168.10.0/24
Note: If one was going to use their IOS device to connect to the MT router for the purpose of going out the internet of the MT router then only ONE entry is required which covers all of the above possibilities as well and that is =0.0.0.0/0
+++++++++++++++++++++++++++++++++++++++++++
Firewall rules, now you have to ensure that traffic coming in remotely through the tunnel to the MT router is allowed to exit the tunnel and go where you want it to go and traffic that is originating on the MT Router that needs to enter the tunnel is allowed to go.
Routes, you have to ensure that traffic coming out of the tunnel has a return path back into the tunnel and traffic originating on the router has a route to initially enter the tunnel.
+++++++++++++++++++++++++++
More detail here:
viewtopic.php?t=182340
NOW the rest is up to you to make a solid effort to set it up and will be here for questions...........