{ linked from New User Pathway To Success Config Success - viewtopic.php?t=182373 }

A thorough, organized plan for your specific WG connectivity will go a long way to establishing a working config.
- INTRO
(1) Generic Settings for WG Devices
(2) Overlapping Peers
(3) Configuring IP Routes
(4) Using IP address for WG Interfaces
(5) Configuring Firewall Rules
(6) My NETNAME or any DYNDNS URL
(7) Third Party VPN & Source-NAT
(8) Behind Another Router & Source-NAT
(9) Other Considerations: A. No Public IP, B. Firewall & Mangling, C. Crypto Key Routing Explained, D. MTU-MSS Issues

IF YOU ARE NOT NEW TO WIREGUARD GO STRAIGHT TO THE TOPIC ABOVE THAT INTERESTS YOU!!

=================================================================================================

Common Reasons to use VPN-Wireguard

1. Accessing the Internet from another location.
example - remote site to local site OR reverse (one tunnel) ------> mobile iphone or subnet on a remote device, to the internet through a local Wireguard connected device.
example - remote siteA -- to local site -- to remote siteB (two tunnels) ----> mobile iphone to local Wireguard Device and then enters second tunnel to third party providers internet.

2. Accessing Servers/Subnets at another location
example - remote site to local site or reverse (one tunnel) ---> users on remote subnet need to access local wireguard device's subnets
example - remote siteA -- to local site -- to remote siteB (two tunnels) ---->mobile iphone to local Wireguard Device and then enters second tunnel to a remote router's LAN server

3. Bundling Accessing Internet and Subnets -combination of the above!

4. Config Router by Admin any combination of tunnels as outlined above.

INTRO: If you have reached this article, you are probably starting on your first Wireguard setup for one of the reasons above. Its fun and not as complex as many other types of VPN. This article will help explain the various bits and pieces that work together to ensure traffic flows the way you want it too. If nothing else, get a piece of paper (or open word doc) and go through the exercise of filling in the information considered in Steps1-6 and the PLAN 1-5. . All the work after that will make much more sense and will lead to a successful configuration experience!

[Gather Information/Requirements]
Step1: Identify all the connecting devices involved - the ones with Wireguard configuration settings
Step2: Identify all the users, either individuals (like a smart phone or road warrior/laptop), or groups of users (aka a subnet of users).
Step3: Identify which user(s) need access to internet through WG (and thus not from their local ISP)
Step4: Identify which user(s) need access to the subnet at the other end of the tunnel (could be on an MT device or another router up or down from the MT device).
Step5: Identify as you the admin, which MT devices you wish to manage/Config from your local MT end of the WG tunnel.
Step6: Identify between applicable pairs of WG devices, WHICH device, for the initial connection, will be acting as SERVER (listening port active) and which will be CLIENT (sends original request).

[Planning Steps]
1. Plan Traffic Flows - from where to where for all use cases! (Dont forget Admin to Devices for configuration if required)
2. Plan Initial Tunnel Connection - which site will start the tunnel request (client).
3. Plan coordinated Wireguard IP address Subnet - for all Peer Wireguard Interfaces. ( see - (4) USING IP ADDRESS FOR WG INTERFACE )
4. Plan Routing of Traffic - how to get the traffic routed properly
5. Plan Firewall Rules - how to get the traffic, entering and exiting the wg interface, to where it needs to go.

[Start Configuring Devices - on paper first]
6. Configure Wireguard Interfaces based upon the complete set of requirements/gathered information.
7. Configure Router settings. Applicable for MT devices as additional router settings such as IP Routes and Firewall Rules are normally required.

[The INITIAL CONNECTION DILEMMA]
i. To establish a WG connection, at least one end of the WG tunnel should have a WG Device with a reachable public IP. If the reachable Public IP resides with an ISP Router or a different device prior to the WG device, (aka internet---->Generic Router/Modem--->WG Device) this could still be considered a USABLE connection, if one can PORT FORWARD from the ISP connected Router/Modem to the listening port on the WG capable device. Such a device can be considered for the SERVER role in the initial connection between wireguard devices.

ii. If one end of the tunnel does not have a WG device with a reachable public IP and one has no control over the ISP connected Router, then this un-configurable end of theWG tunnel is NOT ABLE to act as a Server for the initial connection. Examples of such instances are smart phones or road warriors with laptops.

iii. The WG device that cannot 'host' a connection (not reachable by public IP), must be considered as the Client in the Server/Client relationship when first establishing the tunnel, and if possible should make use of its keep alive setting (in Peer Settings).

iv. After initial connection is established the relationship is no longer Server/Client, the tunnel is now open to two way traffic.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ONCE YOU HAVE COMPLETED STEPS 1-6 & PLAN 1-5 ABOVE, YOU ARE READY TO START THE CONFIG 6-7
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

As discussed above the very basic concepts/steps for setting up any Mikrotik Device are highlighted below as we start to go into the details.....
1. The initial connection configuration ---> one device has to act as client and the other as server.
2. Coordinate an IP address subnet, that includes all the peers, so that each wireguard interface has an associated IP address. For mobile devices (single IP/32) this is the address assigned in the wireguard parameters under Interface Settings.
3. Allowed IPs at each device found in PEER Settings. It should include all destination address of local users - outbound that will enter the tunnel AND it should include all source addresses of incoming (remote) users - inbound and will exit tunnel. Additionally, It should also include the IP addresses of all other associated peer wireguard interfaces.
4. Ensuring IP routes are created manually. Not required for Mobile Devices
5. IP routes will be created dynamically (DAC) for the Allowed IPs that detail the Wireguard Interface IP addresses.
6. On Mikrotik devices, FIREWALL RULES are key to ensuring that traffic exiting the tunnel is allowed to go where it needs to go, or the right traffic is allowed to travel to the tunnel.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

(1) GENERIC SETTINGS FOR WG DEVICES

Wireguard Interface Settings (not mobile)
Add name=WG-X Any name of your choosing.
Add listen port=xxxxx. Essential/required only for any Device acting as Server for the initial connection. It is normal practice for 'client' devices to simply put the same port as entered for the Server Device (the Listening Port).
Created public key= public key generated by the local device that needs to be provided to the Remote Device (for entry in its associated Peer settings).

Wireguard PEER Settings (not mobile)
Select Interface Name entered above
Endpoint IP address - the PUBLIC IP or associated DYNDNS name of the Server side of the tunnel (not normally required on WG Server device).
Endpoint Port - the listening port entered on the Server Device (not normally required on WG Server device).
Allowed IPs (addresses) per peer.
Persistent Keepalive Normally used for the client device only and can be set at the Admins discretion, common practice is anywhere between 25-45 seconds.

Important Discussion of Allowed IPs
Think of 'Allowed IPs', in the sense of IP addresses being identified on the OTHER END DEVICE, when identifying the TWO local distinct traffic flows of INBOUND and OUTBOUND Plus we normally add the wireguard interface IP addresses of all peers that may be used for pinging and troubleshooting connectivity.

A. OUTBOUND: In the case of outbound traffic from the local device to the remote device (From SOURCE) , the destination addresses are used by the local WG Device in a SELECTOR (matching) function, to be determine if any of the local users' destination addresses, being executed at any time, line-up with those IP addresses identified on the one or more PEER settings on the local Wireguard settings. More specifically, the Device will first determine if a Route exists for that traffic(destination address) and then if the IP Route associated Gateway points to the Wireguard Interface, the Router will then check the Allowed Addresses, starting with the first Peer for that Wireguard interface and then any remaining peers. The Peer selected (first match) will determine the tunnel selected (destination IP and Port). A WG interface can have multiple peers and each peer can have multiple addresses. Be careful of overlapping or duplicating such Peer Allowed IPs/destination IP addresses as that will cause issues and is a CONFIG ERROR on your part. ( see - (2) )

Normally such OUTBOUND "Allowed IPs (addresses)" consist of two types:
(i) accessing the internet on the other end of the tunnel and thus use address 0.0.0.0/0 (all possible internet addresses)
(ii) accessing specific IP addresses (subnets, server, users, Wireguard Interface IP addresses, etc.) at the other end of the tunnel and thus use applicable IP address(es) as required.
Note1: The dst-address 0.0.0.0/0 also includes subnets at the other end and thus one would only require the insertion of the internet address nomenclature to cover both needs.
Note2: The IP address or subnet to be accessed may not even exist at the other end of the tunnel but that will clearly require further config at the far end MT device to make it work. A typical example could be a Server that exists on another remote Router, where both the local user device and server on that remote devices connect to an intermediary WG Server Device (hosting both tunnels).

B. INBOUND: In the case of inbound traffic from the remote device to the local device (At RECIPIENT), the IP addresses are used by the Recipient device (local device) as a FILTER function, which will only allow traffic with source IPs that are defined on the local Peer Allowed IPs lists. If no such IPs are defined, the traffic will not be be permitted to exit the WG interface and thus not gain access to the LAN or internet etc.

FUN FACT: What you will discover with experience is that there is OFTEN duplication of inbound and outbound flows. Put simply, it is not uncommon for the destination IPs of local users (outbound) to be the same as the source address of inbound remote users (bidirectional traffic). Thus a single "Allowed IP" entry may cover both inbound and outbound traffic. The extreme case being Alllowed IPs=0.0.0.0/0 which allows all traffic (but in this case watch out for overlapping peers).

Wireguard Interface Settings (typical mobile)
Add name=WG-X Any name of your choosing.
Created public key= public key that needs to be provided to the Server Device (in its Peer settings).
Addresses= The IP address that will identify the Mobile Device on the Wireguard network. Consider this entry to be the Wireguard IP address for the mobile device. With that in mind, ensure it is planned so that it is included in the coordinated subnet plan for all the Peer Wireguard IP addresses.
MTU=Default value 1420. Normally only changed if partial connectivity issues occur. Try changing this first before mangling and other solutions.
DNS Servers= Anything can be entered here. Typically I put the same external DNS servers that my Server Router also has such as 1.1.1.1,9.9.9.9

Wireguard PEER Settings (typical mobile)
Public Key: Provided by Remote Server Device.
Endpoint address - the PUBLIC IP or associated DYNDNS name of the Server side of the tunnel and the associated port, typically either as two separate line entries or in the following format:
publicIP:port or mynetname:port etc...
Allowed IPs= Covered previously but in most cases this is the internet setting of 0.0.0.0/0 which also covers any subnet access at the remote device or the IP Wireguard interface address of the remote device. If internet is not the destination, then ensure the correct addresses are included.
On Demand: This ensures the mobile device remains connected to the Wireguard network when switching providers (aka hotel wifi to cellular).

-----> Allowed IPs Calculator: https://www.procustodibus.com/blog/2021 ... alculator/

(2) OVERLAPPING PEERS

CAUTION OVERLAPPING PEERS CAUTION: One should not have the same IP addresses identified on two or more peers of ANY SINGLE Wiregard Interface. If you find yourself in this situation, create another WG interface to separate the duplication.

Reason. The local WG device, as stated previously, when receiving a destination address from a user first locates a working route for that traffic and then attempts to match the destination address to the ALLOWED IPs lists entered into the peers of that particular interface (in our case a Wireguard interface), and if it finds a match, selects that peer and sends the traffic accordingly. It has no way of knowing which peer to send that traffic too and only matches the first available peer IP address. This issue is more frequently seen when sending out users through a remote site for internet and have several peers for this purpose, as both have the same destination address of 0.0.0.0/0. The peers do not need to be active for this error to be experienced.

(3) CONFIGURING THE IP ROUTES

When configuring IP routes at the local device, one has to consider two traffic flows. One is the traffic originating or considered to be 'starting' at the local device. This could be local users OR for example traffic that has come through and exited the wg interface (and now at the WG Server Device) and is to be relayed through either the same WG interface or a different interface (second tunnel) onwards to another device ( eg.another client MT device or a 3rd party VPN.) The other traffic to direct is any returning traffic that originated at a Remote Client, has exited the tunnel and now needs to return to that same Client. This return traffic could be coming from the internet or perhaps a server at the Local WG Server Device. In the more complex relay example noted above, the Return Traffic, lets say return internet traffic from the 3rd party VPN (via wireguard) that has exited from the Wireguard Interface, onto the Relay Device, and now needs to be directed back through the applicable wireguard interface to the originating user.

(i) Route for Subnet / Single IP - LOCAL TRAFFIC (starting traffic). At the local device, to ensure local user(s)/subnet(s) are sent through the tunnel when attempting to reach destination IP addresses at remote devices, a fairly standard IP Route directing those local users to the wireguard interface gateway is created:
/ip route
dst-address=IPsubnet/24 (or IP address/32) gwy=WG-interface table=main (where the dst address basically matches an allowed IP address entry - destination address of local users).

(ii) Route for Subnet / Single IP - REMOTE TRAFFIC (returning traffic). At the local device, to ensure remote user(s)/subnet(s) RETURN Traffic (after reaching the internet or local device servers for example) is directed BACK through the tunnel again a fairly standard IP Route is created:.
/ip route
dst-address=IPsubnet/24 (or IP address/32) gwy=WG-interface table=main (where the dst address basically matches an allowed IP address entry - source IPs of remote users).

FUN FACT: What you will discover with experience is that OFTEN, just as in 'Allowed IPs" and due to bidirectional traffic, one IP Route covers both local 'originated' traffic AND remote returning traffic. Consider the case where the local traffic needs to reach the remote subnet 192.168.50.0/24 and that same remote subnet needs to reach a server on the local device. At the Local device, the "Allowed IP" of 192.168.50.0/24 covers both outbound (destination addresses) and inbound (remote source IPs) considerations. Similarly, one only needs one IP route to ensure that local users get sent out the wireguard interface with destination address of 192.168.50.X and the remote users (with their source addresses) are directed back into the tunnel after hitting the local server.
/ip route
dst-address=192.168.50.0/24 gwy=wg-local table=main { Is a single valid IP Route for BOTH CASES! }

Note1: For Mobile Devices with fixed single IPs, that are already included in the coordinated IP wireguard interface schema, a dynamic IP routing (DAC) will already exist and thus a manually created route will not be needed.
Note2: Each Peer will require such routes and multiple IP addresses within each peer should need such routes.
Note3: Manual Routes will not be required for traffic to/fro Wireguard Interface Addresses.
Note3: It may be necessary to source-nat packets entering a tunnel so that they more easily handled at the other end (special cases).

(iii) Route for Internet Traffic . Internet traffic is a special case in terms of IP Routes for Wireguard Interfaces. Mainly because we have to identify this by stating ALL possible IP addresses/subnets - 0.0.0.0/0! As above we will consider the two cases of Return Traffic and Starting Traffic at the local device. Return is straightforward but Starting requires further work:

a. RETURN (REMOTE) TRAFFIC: Remote users are exiting the local device wireguard tunnel and using the local device WAN connection for internet. How do we deal with Traffic returning from the WWW, with source address of remote users. We have to direct that traffic back through the tunnel. It is fairly straightforward:
/ip route
dst-address=IPsubnet/24 (or IP address/32) gwy=WG-interface table=main (where the dst address basically matches an allowed IP address entry - source address of remote users).

Note: One should see that this matches the configuration for the INBOUND return traffic from local subnet/servers, example above (ii)

b. ORIGINAL (LOCAL) TRAFFIC: One or more local users (or even remote users that came in on a WG tunnel and now considered local) need to ENTER a tunnel to use the Internet at a Remote Device. However, often, there are either multiple subnets on the local Router or only a single user/device has the requirement to go elsewhere for internet. (Many possible combinations) Why is this difficult? We have to recognize and accommodate for the fact that INTERNET access at the local Router already exists for all other users/devices on the Router.

Thus if we already have an IP route dst-address=0.0.0.0/0 gwy=wanIPgateway table=main we will need to deconflict for internet access!!
Q1 - How do we take only one subnet out of two or three on the local device and point it to the tunnel
Q2 - How dow we take one device and point it to the tunnel.

Solution: We create a new table (other than main) and we point the selected traffic to that table in a routing rule. No mangling required. We "FORCE" the traffic into the tunnel so that it is not captured by the already existing route to the internet through the WANIP.
/routing table fib add name=use-WG
/routing rule src-address=IP address action=lookup-only-in-table table=use-WG
/ip route
dst-address=0.0.0.0/0 gwy=wg-interface-name table=use-WG

Note: If the admin wants the users to be able to access internet locally if WG is down then use ACTION=Lookup { akin to fail over }

(4) USING IP ADDRESS FOR WG INTERFACE

The right plan is to create a coordinated subnet to connect all the Peer Wireguard Interface IP addresses.

IP ADDRESS - INDEPENDENT
Ensure the subnet you create is independent of any subnets existing on any of the devices (excluding mobile devices). This process also ensures proper device to device communications and also aids in troubleshooting(pinging). One should include mobile devices ( where its single IP Address is assigned within the Wireguard settings), that unlike MT devices do not have separate IP address functionality and do not have subnets within the device.

Using en example of three peers and one main router, each peer device and the main router are given an IP address within the same subnet.
Looking at the table below, If the admin wants to check ping from one device to another (local to remote), the admin has to make sure that on the local device the remote WG address is included in the peer IP "allowed IPs" addresses (viable destination address for pinging).

WIREGUARD INTERFACE ADDRESSES.
/ip address
add address=10.10.5.5/24 interface=wg-local {at Local Router} SERVER FOR INITIAL CONNECTION!!
add address=10.10.5.4/24 interface=wg-peer3 {at remote device 3 - Hex}

For mobile devices the wireguard interface address is the ADDRESS you give to the wireguard connection WITHIN the wireguard settings:
Address=10.10.5.2/32 = {at remote device 1 - iphone}
Address=10.10.5.3/32 = {at remote device 2 - laptop}

PEER ALLOWED IPs
(only considering Wireguard interface IP addresses, for actual traffic add to this base/minimum setting)
Iphone (Peer=Local Router), Allowed IPs=10.10.5.0/24 (done) [note: not required if for internet access as 0.0.0.0/0 includes all addresses.]
Laptop (Peer=Local Router), Allowed IPs=10.10.5.0/24 (done) [note: not required if for internet access as 0.0.0.0/0 includes all addresses.]
Hex (Peer=Local Router), Allowed IPs=10.10.5.0/24 + any other traffic required = outbound (remote destination addresses at local) + inbound (remote source addresses from local)
Local Router : SERVER FOR CONNECTIONS
Peer1 AllowedIPs=10.10.5.2/32 (done)
Peer2 AllowedIPs=10.10.5.3/32 (done)
Peer3 AllowedIPs=10.10.5.4/32 + any other traffic required = outbound (remote destination addresses at hex) + inbound (remote source addresses from hex)

IP ROUTES
Iphone & Laptop not applicable - Mobile Devices (dependent upon the particular architecture of smart phone OS or Laptop OS apps etc.....) They can ping directly as the routing is applied internally.
Hex (created dynamically)
(dac) dst-address=10.10.10.0/24 gwy=wg-peer3 table=main (routes hex pings to Router (dest addr) and/or routes remote Router return traffic after pinging hex)
Local Router (created dynamically)
dst-address=10.10.10.0/24 gwy=wg-local table=main routes Router pings (dest addr) to all peer devices and routes remote Peer return traffic after pinging Router)

NOTE: Firewall Rules still need to be reviewed to ensure any pinging traffic is permitted (LAN/ROUTER to WG -- or -- WG to LAN/ROUTER)

(5) CONFIGURING FIREWALL RULES

If you use the default rules, there is basically nothing stopping most LAN level traffic and without realizing it, wireguard traffic will be allowed both to the router itself and the other LAN entities. It is for this reason, it is recommended that putting DROP all rules at the end of your input and forward chains is done, so that such traffic is under your control, and not automatically allowed.

Assuming one uses a drop all rule at the end of the input and forward chains, one recognizes that we have to create "allow" rules for wireguard traffic. In any Mikrotik device (client or server) and more accurately (local or remote) there are two cases that may occur.
The first is local outbound traffic from an admin, or user or subnet of users to be permitted to enter the tunnel.
The second case is to allow remote inbound traffic from remote users, to access a local server, an entire subnet, the internet, or the MT device for configuration purposes.
The following rules demonstrate the possibilities that exist at both ends of the tunnel:
add action=accept chain=input in-interface=wg-interface-name dst-port=winboxport protocol=tcp src-address=Admin_IP { allows admin to config local router remotely }
add action=accept chain=forward src-address=Subnet out-interface=wg-interface-name { to allow local subnet to enter the wireguard interface }
add action=accept chain=forward in-interface=wg-interface-name dst-address=IPofServer { to allow remote users access to local server } ***
add action=accept chain=forward in-interface=wg-interface-name out-interface-list=WAN { to allow remote users access to local WANIP (internet) } ***

Note1: In the last two examples *** use src-address or src-address-list to refine access to specific users, which may be required for multiple addresses from a peer and multiple peers.
Note2: Ensure Peer Devices software firewalls ( ex. Windows PC ) do not block WG traffic including ICMP.

(6) MYNETNAME or DYNDNS URL - SPECIAL CONSIDERATION FOR ENDPOINT (reresolve DNS)

A known issue with Wireguard occurs when the Endpoint address is DYNAMIC and has been entered via DYNDNS type name. If the wireguard tunnel is initiated before DNS has resolved the DYNDNS URL, the wireguard client will stop and will NOT restart. One has to manually disable and enable the peer to kick-start the tunnel. This can happen if the endpoint actual WANIP changes or a router is rebooted etc. In other words, there are multiple reasons why a wireguard server device is temporarily unavailable (it is rebooted or perhaps the public facing router is rebooted, changes IP address or suffers a power outage)

Sol/n 1 - CHECK LOCAL_IP NAME THROUGH TUNNEL - Use the script (courtesy of gdanov) on the Remote (originating) end of the tunnel to detect when the endpoint device is available by checking local IPs through the tunnel. In other words 'when down'. The Local_IP refers to the server end of the connection and is any local IP reachable through the tunnel. If that IP is reachable through the tunnel then the tunnel is working! If not, then disable the wireguard peer and enable it after 60 seconds. Run this as a scheduled script perhaps every 2 minutes.
... ...

Sol/n 2 - BASIC NETWATCH - Easier method! (unknown author) Using the Netwatch Tool, using the "DOWN" tab, and the HOST IP is the Local IP ( Reachable subnet or IP address through the tunnel - best to use Wireguard Interface IP address of Server). However, this has been found not to work if the Server side is down for an extended length of time. Suggest if the Server is problematic, try a different script or perhaps extend the delay to 75 seconds. The problem occurs when the Server is still down after the time delay as Netwatch does not trigger/function again (no UP achieved) as its still down.
... ...............


Sol/n 2 - ADVANCED NETWATCH VARIATION on the EASY METHOD - Here a script is used to toggle the Wireguard interface (not netwatch), but netwatch is used to enable or disable the scheduler for the script! Define script to toggle WG peer settings:
.......................
...........................

FOR ADVANCED USERS -------
It takes all enabled peers with endpoint-address ending with letter (which means it's non-empty and not numeric address) and last handshake older than 5 minutes ("5m" on second line), takes current hostname and sets it again as endpoint-address, which makes RouterOS resolve it again. It should be safe to run it unconditionally from scheduler. In addition, this script will will trigger the endpoint-address reset for blank last-handshake as well.
{ meaning it addresses the following: If the peer has never connected (or if the peer is disabled and re-enabled while the endpoint is down), then the last-handshake is blank and the > 5m condition is false. }
.......................................

VARIATION of ADVANCED (courtesy of msatter!)
>>>>>>>>>>>>>>>>>>>>>>>
.............................................................


(7) THIRD PARTY VPN ---> WHY SOURCE-NAT

Often, MT users want to use a third party VPN for all their internet traffic. The considerations are very much standard except for one big difference. VPN providers give you a SINGLE IP address for your WG settings. This makes sense for something like an iphone, or laptop, but creates issues if applying the VPN on an MT device. This is important because the third party VPN will be expecting all traffic to be coming from this IP address as SOURCE IP! In wireguard vernacular, that means the PEER SETTINGS at the 3rd Party VPN server to describe and filter incoming traffic from your MT device for ALLOWED IPs will be set to the single IP address they gave you. Since we have LAN users from potentially multiple subnets going over the wireguard tunnel we have to change their private IPs to that of the assigned WG address. Hence we have to have a way to take all the traffic entering the tunnel locally to appear as if they are coming from that one IP address ---> - answer is SRC-NAT! (see example).

Understanding source-nat and masquerade is an important point for the beginner! SRCNAT Masquerade basically replaces the outgoing source IP address of traffic with the IP of the outgoing interface, be it the local WANIP, OR the IP address of the wireguard interface. The router will un-SRCNAT the return traffic as required.

For this example, we are assuming the 3rd Party VPN provider has assigned you an IP address=10.10.10.2/32, supplied the endpoint IP and port and you have exchanged public keys etc. Thus most of the settings are complete. Lets also assume your MT local LANIP subnet to use the tunnel is 192.168.20.0/24

MT WIREGUARD PEER SETTINGS:
1. MT Allowed IPs = 0.0.0.0/0 ( also set keep alive to something like 40 seconds)

MT RoS SETTINGS:
2. IP address - Add address=10.10.10.2/24 interface=wireguard1

3. Firewall rules -You need to ensure your subnet or subnets are allowed to enter the tunnel. (as applicable)
add chain=forward action=accept src-address=192.168.20.0/24 out-interface=wireguard1 (single subnet)
add chain=forward action=accept in-interface-list=LAN out-interface=wireguard1 (all subnets)

4. IP Route - To force all users out Wireguard for internet vice local ISP. You should have the default route already in place, either automatically because in IP DHCP Client you have YES selected for use ISP as default route, OR you should have created one manually.
add dst-address=0.0.0.0/0 gwy=ISP gateway-IP table=main.

THREE STEPS:
Add table
/routing table add name=useWG fib

Add routing rule (use as many route rules as you have subnets, use route rules for any individual exceptions on a subnet that should not go out the wireguard interface for internet)
/routing rule add src-address=192.168.20.0/24 action=lookup table=useWG

Add additional route
dst-address=0.0.0.0/0 gwy=wireguard1 table=useWG

Note: lookup means use the table indicated for traffic but if the table is not available, look for another routing (which means check table=main to see if any alive routes exist and use that one).
If you had selected lookup-only-in-table, then the router would not look else where if the wg tunnel was not available and traffic would be dropped.

5. SOURCE-NAT - Two options:

Option 1: (add wireguard interface to WAN LIST) ..........................
OR if you dont add the wireguard interface to the WAN interface list
Option 2:
................................

(8) BEHIND ANOTHER ROUTER ---> WHY SOURCE-NAT

The Problem: Remote users are exiting the tunnel locally at your MT Server for the purpose of accessing your ISP connection to the local internet. The remote traffic exits the tunnel on your MT device and by firewall rules and routing exits the MT Wan port and then gets sent out the FIrst/Main Router's WAN port to the internet. The return traffic, from remote users, hits the First/Main router and the router looks at the source address of the traffic, ( the subnet IPs of the remote users that came into the tunnel ) and does not recognize the traffic as being valid for any of the First/Main router's own subnets. Nothing is 'routable' from the router's perspective and the traffic is dropped (never reaches the MT device).

The Solution: SOURCE NAT the incoming remote traffic, exiting the wireguard tunnel, to the WANIP of the 'natted" MT device!!
Now the returning traffic from the internet will hit the First/Main router and the router will look at the source address and say, Oh yeah I recognize that, I have a subnet for that traffic that is 'routable' and thus I will send it to the MT Devices WANPORT!! The MT router detects the source-natting on this arriving traffic and then UN-SRC-NATS the traffic back to the applicable remote users IP addresses, which the MT Device further recognizes is valid return traffic and 'routable' (due to existing IP routes for remote user subnet(s)) and sends the traffic to the wireguard interface.

CASE1: MT Device is behind an MT ROUTER. This is the best case scenario as we have full flexibility to create static routes for return traffic on the First/Main router, if we choose do so. Source-NAT is also a viable option. It is assumed that one has the capacity to port forward the wireguard port via destination NAT, from the MT Router to the MT device.
CASE2: MT Device is behind ANOTHER ROUTER. Some routers allow both static routes and port forwarding and thus the solution will be predicated upon the First/Main Routers capabilities.

(Note: if the First/Main Other Router is incapable of forwarding ports see Para 9. (A).)

(1) Static Route - on ISP Router: If the ISP router is capable of static routes then the following equivalent could be be constructed:
dst=address=subnet_of_users gwy=WANIP of second router table=main

(2) Source NAT - on Server Router: With only the ability to forward ports on the ISP router, the preferred solution is to SRC NAT the remote traffic, that will exit the tunnel, to the WANIP of the Mikrotik Server device.
add chain=src-nat action=masquerade out-interface-list=WAN src-address='subnet_of_remote-users'

(3) Source NAT to a PI WG Server behind a REMOTE SERVER Router - from an MT Client Device: If you have a PI server behind an ISP router (with PI WG parameter interface IP Address = 10.6.0.5/24) and want to use your MT device as a client, with user subnet 192.168.20.0/24, to reach the remote ISP internet connection one will need to consider a route back for return traffic at the PI server. If the PI server (OR ISP Router) cannot create a static route and the PI Server cannot do source nat, for 192.168.20.0/24, all the return traffic packets to go back through the tunnel, will be dropped. Consider using source-nat at the MT Client device.
/ip firewall nat add chain=srcnat action=src-nat src-address=192.168.20.0/24 out-interface=Wireguard to-addresses=10.6.0.254

This is the problem, the PI server has no way to route the return traffic from the remote subnet (your MT Device users). Remember the ISP router the PI server is on, has no knowledge of the subnets on your MT device and there is no way for you to add any routes on the remote ISP router. Thus, if you source-nat all your local client IPs to WITHIN the wireguard structure of the wireguard pi server, then the router will assume the return traffic needs to go back to the PI Server which will then route the traffic out the PI wireguard tunnel.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

(9) OTHER CONSIDERATIONS

A. UH OH - BOTH MY DEVICES DON'T HAVE A PUBLIC IP
In some rare cases you will have a situation where both Mikrotik devices are behind ISP routers that provide a public IP and worse, they are not able to be accessed to port forward the all important listening port!! Please check out this thread for ideas on how to acquire a usable Public IP - viewtopic.php?t=183427

B. USING FIREWALL ADDRESSES & MANGLING

When one needs to IDENTIFY or force traffic for a group of IPs, and not a single source address, or destination address, or interface, or subnet, the only option left to identify such a grouping is by Firewall Address List. However, this entity is not definable as a destination address on an IP route, nor is it definable on the Routing Rule.
There are TWO OPTIONS:

1- Make as many Route Rules as there are single IPs (if less than a subnet or a mix of IPs from various subnets) and use source address (no mangling)!

2-Make a single Route Rule but with mangling and USE ROUTE MARK as the entry argument in the Route rule!

BASIC EXAMPLE. MIxed bag of IP addresses go through tunnel, but too many for option1!
a. capture the traffic via marks in pre-routing
b. capture the marks via route marking in pre-routing
c. apply the route mark in the applicable Routing Rule
d. disable fast track.

ADVANCED EXAMPLE - All traffic must go through the tunnel, all IPs, subnets etc.......
In this case we want ALL SUBNET Traffic to go out the tunnel using Table=MAIN

How to ensure that the initial handshake that should go out the normal ISP WAN pathway is taken if there is no IP route for this.
Solution: Make use of Mangle and output chain (no effect on fastrack!!). The trick is to use the route-mark name as also the routing table name.

Step1: Identify the firewall address for our config
/ip/firewall/address-list add list=WG-Server-Router address= sn.mynetname.net (address=fqdn-of-remote-peer)
Step2: Create the mangle rule........
/ip firewall mangle
add action=mark-routing chain=output dst-address-list=Wireguard_Server-Router new-routing-mark=useWAN passthrough=yes
Step3: Create the Routing Table
/routing table add name=useWAN fib
Step4: Create the IP route
/ip route
dst-address=0.0.0.0/0 gwy=ISP gateway table=useWAN

C. UNDERSTANDING THE CRYPTO KEY ROUTING PROCESS (CKRP)

If you want to know when and how encryption is applied and used during Wireguard transactions this article is probably the clearest to be found. https://www.wireguard.com/#cryptokey-routing

Suffice to say Mikrotik IP routing and Wireguard Crypto Key Routing work together to ensure authorized traffic flows to where it needs to be. In a very general sense, IP Routing brings the traffic to the Wireguard Protocol or takes traffic output by the Wireguard Protocol for dissemination while the Wireguard Protocol does its internal Routing as required. A routing sandwich if you will where CKRP is the meat between the bread of IP ROUTING.

To help understand the above article this explanation may be helpful.
What the new person, beginner, should focus on is that Crypto Key Routing Process (CKRP) runs in the background and has to do mainly with two processes. However, for crypto routing to occur, it is the responsibility of the admin, to first accurately state the Allowed IPs for each peer (key word being peer=remote site). More specifically the admin should, at any local device, consider the Allowed IPs as they relate to the remote end for two distinct populations of addresses, a. the destination addresses at the remote end, for local users heading outbound and entering the tunnel, and b. the source addresses for users at the remote end, heading inbound and will be exiting the tunnel.

Now that the Allowed IPs are correctly established by the admin, Crypto Routing can carry out its two integrated processes, and the really core bit MAPPING KEYS TO PEERS, uses the admin Allowed IPs to ensure the right peers and right keys are matched to the local traffic entering the tunnel so that the right destination information is added and subsequently at the other again compare Keys and peers and then allowed IPs to ensure authorized traffic is allowed to exit the tunnel. The other process which occurs is the encryption and decryption (not as exciting). That is enough detail for the new beginner at the start of their journey.

In order to provide a bit more detail for the beginner this explanation may be useful.

For LOCAL OUTBOUND TRAFFIC.
User Traffic (payload) ---> Destination address ----> MT device -----> IP Routes
IP Routes ---- > gwy=wireguard interface ---> Crypto Key Routing Process

Wireguard Protocol ( CKRP) - think of Wireguard as a Mini Router
CKRP attemps to find a match of destination address with Allowed IP in the list of Peers starting at Peer1 (order is important!)
Match found ----> Peer Selection ----> encrypt payload (right public key) ----> add associated destination address and destination port for that peer --->create transport packet
Transport packet ----> Exit CKRP --->IP Routes
IP Routes ----> gwy= ISP gateway IP table=main ---> WWW.

FOR LOCAL INBOUND TRAFFIC,
Incoming Transport packet ---> Microtik Device ----> Incoming destination port exists on device ------> IP routing
IP Routing ---> Due to destination port on transport packet ------>Wireguard Mini Router ---> CRKP
CKRP ---> based on dest port, CRKP attempts to authenticate with available associated public keys until successful,
CKRP ---> the public key is used to decrypt transport packet into payload and reveals Source IP address
---> Compare source IP to Peer Allowed IPs from the Peer used for decryption of payload
---> Source IP exists ----->Exit CKRP---> send payload to IP Routes
IP Routes---> Route to correct interface via destination address and firewall rules.

D. MTU-MSS ISSUES

1 - Ensure ICMP is not blocked, this affects PMTUD, which apparently is some function that manages MTU and MSS settings. When I find out what they all do I will add it here.

(8) NETWORK DIAGRAM
Use a network diagram to fully describe your plan and it will be intuitively easy to understand the requirements when posting on the forum.

================================================================================================
TOC:
Scenario 1 - (HARD) Traversing Two Wireguard Interfaces on one Router and Third Party VPN
Scenario 2 - (MEDIUM) Initiating a Wireguard tunnel from Both Sites
Scenario 3 - (EASY) Initiating a Tunnel From One Site to Allow Traffic in the Opposite Direction.
Scenario 4 - (MEDIUM) Peer to Peer tunnelling with one Wireguard interface & Use of IP addresses for Wireguard interfaces.

================================================================================================

SCENARIO-1:

I have two sets of users coming from the internet through my Local MT Router. One is a subnet from a Remote MT Router 10.1.10.0/24 and the other is an IPHONE user, which we will assign an IP of 172.16.1.2/32. The remote subnet should be able to access my Local MT Router for internet access only. The Iphone user should be able to access my subnet 192.168.50.0/24 but also use an existing vpn connection through 3rd Party Wireguard provider called BiteMe for internet. I want one of my subnets on my Local MT Router 192.168.20.0/24 to go out the third party provider for internet as well. I want to be able to config the Remote Router from my admin PC, 192.168.10.15/32 and the winbox port on the Remote Router is 6969
As an aside, to access the Remote MT router by winbox, via wireguard, one needs to use any Remote Router local Ip address and thus I like to choose the IP address of one of the subnets (a trusted subnet for example). Lets say the trusted subnet of the home-lan at the remote site is 10.1.50.0/24.
..... .....
LOCAL ROUTER WIREGUARD INTERFACE1 (Server for establishing tunnel with Remote Router)
Wireguard Settings
name=WG-Local
listening port=15555
public key generated= xxx (to be used on both iphone and Remote Router peer addresses)

Peer Settings - Applicable for Remote Router
allowed IPs (addresses)=10.1.10.0/24, 10.1.50.1/24 ( the first address is for filtering traffic EXITING the tunnel, the second is the Remote Routers local IP address I am going to use as my destination address for winbox and is entered here to be used for selection to ENTER the tunnel)
public key=yyy (from Remote Router)

Peer Settings - Applicable for Iphone
allowed IPs (addresses)=172.16.1.2/32 ( traffic from this IP will be allowed to exit the tunnel at the Local Router )
public key=iii (from iphone)

---------------------------------------------------------------------------

LOCAL ROUTER WIREGUARD INTERFACE 2 (Client for establishing tunnel to third party)
Wireguard Settings
name=WG-BiteMe
listening port=n/r
public key generated= ccc (to be given to BiteMe)

Peer Settings
allowed IPs (addresses)=0.0.0.0/0 ( this will match and select all internet bound traffic, that should go through the vpn provider, to enter the tunnel )
endpoint address= publicIP address provided by BiteMe
endpoint port=port provided by BiteMe
public key=ddd ( public key provided by BiteMe )
persistent keep alive= 40 secs

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

REMOTE ROUTER
Wireguard Settings
name=WG-Remote
listening port=15555
public key generated= yyy

Peer Settings
allowed IPs=0.0.0.0/0 (this will match and select all internet bound traffic, that should go through the Local Router, to enter the tunnel, and in addition includes and thus will filter (accept) the Admin IP inbound traffic from the Local router to exit the tunnel )
public key=xxx (From Local Router)
persistent keep alive=30 secs

IPHONE
Wireguard Settings
name=mywg
address=172.16.12.2/32
public key generated=iii
DNS Servers= 1.1.1.2, 9.9.9.9

Peer Settings
allowed IPs=0.0.0.0/0 (to eventually access the BiteMe wireguard tunnel, and allows subnet access on the Server Router)
public key=xxx (From router)

===================================================================================================
ROUTER SETTINGS - ROUTES

LOCAL ROUTER (Server)
IP Address - not required for the wg interface.

IP Routes
dst=10.1.10.0/24 gwy=WG-Local table=main { ensures return traffic (replies) gets routed back to the subnet user(s) via the tunnel }
dst=172.16.1.2/32 gwy=WG-Local table=main { ensures return traffic (replies) gets routed back to the iphone user via the tunnel }
dst=10.1.50.1/24 gwy=WG-Local table=main { admin on Local Router will use winbox IP:Port of 10.1.50.1:6969 to access Remote Router }
dst=0.0.0.0/0 gwy=BiteMe table=useBM

/routing rule (order is important)
add action=lookup-only-in-table src-address=192.168.20.0/24 table=useBM { ensures local subnet users enter tunnel for 3rd party VPN provider internet }
add action=lookup-only-in-table dst-address=192.168.50.0/24 table=main { ensures iphone traffic for subnet is captured prior to third rule }
add action=lookup-only-in-table src-address=172.16.1.2/32 table=useBM

/routing table add name=useBM fib

REMOTE ROUTER
IP Address - not required for the wg interface.

IP Routes
dst-address=192.168.10.15/32 gwy=WG-Remote table=main
dst-address=0.0.0.0/0 gwy=WG-Remote table=useWG
/routing rule
add action=lookup-only-in-table src-address=10.0.1.0/24 table=useWG
/routing table add name=useWG fib

ROUTER SETTING - FIREWALL RULES

LOCAL ROUTER(server)
/input chain
add chain=input action=accept dst-port=15555 protocol=udp { if applicable assumes ISP router is port forwarding 15555 to the WANIP of the MT Router }
...
add chain=input action=drop
/forward chain
add chain=forward action=accept in-interface=WG-Local src-address=172.16.1.2/32 dst-address=192.168.50.0/24
add chain=forward action=accept in-interface=WG-Local out-interface=WG-BiteMe src-address=172.16.1.2/32
add chain=forward action=accept in-interface=WG-Local src-address=10.0.1.0/24 out-interface-list=WAN
add chain=forward action=accept src-address=192.168.20.0/24 out-interface=WG-BiteMe
...
add chain=forward action=drop

REMOTE ROUTER
/input chain
add chain=input action=accept in-interface=WG-Remote scr-address=192.168.10.15/32
...
add chain=input action=drop

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

SCENARIO-2: - https://www.procustodibus.com/blog/2020 ... -wireguard

This is a simpler scenario, WHERE USER 1A, needs to wireguard tunnel to an HTTP SERVER 1B .
This scenario also demonstrates a situation where both MT devices have either a public reachable IP address or private IP where one can port forward from the ISP modem/router. This approach will support any situation where the tunnels are not operating for some reason and either side can initiate the tunnel for their needs. I have thus added to the linked scenario, a reverse requirement where a USER (2B) on Router B, needs to access an HTTPS server (2A) on Router A.
..... .....

ROUTER A -------------------------------------------------------- ROUTER B
1A- 192.168.1.11 USER on subnet 192.168.1.0/24 ... 1B- 192.168.200.22 Server on subnet 192.168.200.0/24
2A- 192.168.5.3 Server on subnet 192.168.5.0/24 ..... 2B- 192.168.60.7 User on subnet 192.168.60.0/24

ROUTER A CONFIG

INTERFACE
Interface Name = WG-A
ListenPort = 51821
Public Key Generated --> To be entered on peer settings Router B

PEERS
PublicKey ---> to be entered is from Router B
Endpoint = 203.0.113.2: ( we need endpoint information from Router B here if router A needs to originate the tunnel )
Endpoint port = 51822
Allowed IPs (to match and select local user destination IPs, to enter tunnel outbound) = 192.168.200.22/32 (SOURCE FLOW)
Allowed IPs (to filter remote user source IPs to exit the tunnel inbound) = 192.168.60.7/32 (RECEIVED FLOW)
Thus Allowed IPs=192.168.200.22,192.168.60.7
keep alive=25 seconds ( needed if originating the tunnel )

IP FIREWALL RULES - ( need to allow user 2B to access server 2A )
add chain=input action=accept dst=port=51821 protocol=udp
add chain=forward action=accept in-interface=WG-A src-address=192.168.60.7 dst-address=192.168.5.3 dst-port=443
Other rules will accomplish same with less precision...... but depending may be necessary.
add chain=forward action=accept in-interface=WG-A dst-address=192.168.5.0/24
add chain=forward action=accept src-address=192.168.60.0/24 dst-address=192.168.5.0/24

IP ROUTES
dst-address=192.168.60.7/22 gwy=WG-A table=main ( ensures replies from Server 2A go back through the tunnel to user 2B )
dst-address=192.168.200.22/32 gwy=WG-A table=main ( ensures local user get sent out tunnel to Router B )

Note: The wireguard interface WG-A and also on the other router WG-B, can be identified/selected on interface list members but cannot be added to a bridge!

ROUTER B CONFIG

INTERFACE
Interface Name = WG-B
ListenPort = 51822
Public Key Generated--> To be entered on peer settings Router A

PEERS
PublicKey ---> to be entered is from Router A
Endpoint = mynetname-Router_A: ( Router A has a private IP and a dyndns name is required for example )
Endpoint port = 51821
Allowed IPs (to match and select local user destination IPs, to enter tunnel outbound) = 192.168.5.3/32 (SOURCE FLOW)
Allowed IPs (to filter remote user source IPs to exit the tunnel inbound) = 192.168.1.11/32 (RECEIVED FLOW)
Thus Allowed IPs=192.168.5.3/32,192.168.1.11/32
keep alive=30 secs

IP FIREWALL RULES - ( need to allow user 1A to access server 1B )
add chain=input action=accept dst=port=51822 protocol=udp
add chain=forward action=accept in-interface=WG-B src-address=192.168.1.11 dst-address=192.168.200.22 dst-port=80
Other rules will accomplish same with less precision.......and may be necessary depending.....
add chain=forward action=accept in-interface=WG-B dst-address=192.168.200.0/24
add chain=forward action=accept src-address=192.168.1.0/24 dst-address=192.168.200.0/24

IP ROUTES
dst-address=192.168.1.11/32 gwy=WG-B table=main ( ensures replies from Server 1B go back through the tunnel to user 1A )
dst-address=192.168.5.3/32 gwy=WG-B table=main ( ensures local user gets sent through the tunnel to Router A)

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

SCENARIO-3:

This is a basic scenario where Site B has an MT Map behind an ISP router, with no access to the ISP Router. The admin, located at Site A, needs to accomplish two functions at Site B: a. to access a certain device on the Map LAN subnet and b. to be able to configure the Map remotely. To accomplish this we are going to have to establish the tunnel with the Map at Site B being the initiating Client device and the MT Router at Site A to be the receiving Server device. In other words we are establishing the tunnel in one direction but all the data traffic will originate at Site A and thus flow in the opposite direction. To make it slightly more interesting, the Site A MT Router (wireguard server) is also behind an ISP router. We are limited by this but we can port forward the listening port to the MT Router. The Map is also interesting. In this example it has no LAN subnet, it bridges the LANIP subnet from the ISP router to ether 2 and other ports.
..... .....
ROUTER A CONFIG

INTERFACE
Interface Name = WG-A
ListenPort = 80901
Public Key Generated --> To be entered on peer settings Router B

PEERS
PublicKey ---> to be entered is from Router B
Allowed IPs (to match and select local user destination IPs, to enter tunnel outbound) = 192.168.0.0/24 (Outbound Flow)
Allowed IPs (to filter remote user source IPs to exit the tunnel inbound) = none on this config (Inbound Flow)
Thus Allowed IPs=192.168.0.0/24

IP FIREWALL RULES
add chain=input action=accept dst=port=8090 protocol=udp { for initial connection from Router B }
add chain=forward action=accept src-address=192.168.0.0/24 out-interface=WG-A { to allow admin and various users to Router B }

IP ROUTES
dst-address=172.18.1.1/0/24 gwy=WG-A table=main { traffic heading for Router B will get pushed into the tunnel }

ROUTER B CONFIG

INTERFACE
Interface Name = WG-B
ListenPort = 80902 { not really required }
Public Key Generated--> To be entered on peer settings Router A

PEERS
PublicKey ---> to be entered is from Router A
Endpoint = mynetname-Router_A: ( Router A has a private IP and a dyndns name is required for example )
Endpoint port = 80901
Allowed IPs (to match and select local user destination IPs, to enter tunnel outbound) = none ( Outbound Flow)
Allowed IPs (to filter remote user source IPs to exit the tunnel inbound) = 192.168.0.0/24 (Inbound Flow)
Thus Allowed IPs=192.168.0.0/24
keep alive=30 secs

IP FIREWALL RULES - { need to allow users to access device and admin to access router }
add chain=input action=accept in-interface=WG-B src-address-list=siteA dst-port='winboxport'
add chain=forward action=accept in-interface=WG-B src-address=192.168.0.0/24 dst-address=172.18.1.22/32

IP ROUTES
dst-address=192.168.0.0/242 gwy=WG-B table=main { ensures replies from SiteB go back through the tunnel to Site A users }

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

SCENARIO-4:

This is an interesting scenario where the admin can access Site A but cannot access Site B. The admin does not work from either site and must use a laptop/smartphone to connect to the Routers. The admin wants to be able to config both Routers and he wants to be able to reach a Server at Site B. The users at Site B also need to use Site A for all internet traffic.
This is the only Scenario where use of IP addresses for Wireguard Interfaces is explicitly applied.

Admin Requirements:
Needs access to site A, in order to config Router A (which has a public IP and is thus reachable).
Needs access to site B, in order to config Router B and reach a Server on Router B (which is not reachable, not a public IP and has no control/access to ISP router),
Hence, the configs must allow the admin to reach Router B FROM Router A.

User Requirements:
Users at site B must use Site A for all internet.
.... .....
ROUTER A CONFIG

INTERFACE
Interface Name = wireguardM
ListenPort = 6868
Public Key Generated --> To be entered on peer settings Router B

PEERS
PublicKey ---> to be entered is from Router B
Allowed IPs (to match and select local user destination IPs, to enter tunnel outbound) = 10.0.1.0/24 (Outbound Flow, to Router B and Server)
Allowed IPs (to filter remote user source IPs to exit the tunnel inbound) = 10.0.1.0/24, 172.16.0.0/30 (Inbound Flow) (from Router B subnet and admin devices)
Thus Allowed IPs=10.0.1.0.0/24,172.16.0.0./30

IP FIREWALL RULES
add chain=input action=accept dst=port=6868 protocol=udp { for initial connection by admin devices and Router B }
add chain=input action=accept dst-port=WINBOXPORT in-interface=wireguardM src-address=172.16.0.0/3 { access by admin to config Router A }
add chain=forward action=accept in-interface=wireguardM out-interface-list=WAN src-address=10.0.1.0/24 { allows Remote site users to access internet through Main router }
add chain=forward action=accept src-address=172.16.0.0/30 dst-address=10.0.1.0/24 { allows admin to access both Remote router for config and any device on its LAN subnet including server! }

IP ROUTES - NOT Required!!
Note: Since you have IP addresses assigned to the Wireguard Interface (see below) covering both the site B subnet and Road warriors, the router will automatically route any LAN traffic traffic or internet traffic automatically to or back through the wireguard interface and peers as required.

IP ADDRESSES
/ip address
add address=172.16.0.254/24 interface=wireguardM network=172.16.0.0
add address=10.0.1.254/24 interface=wireguardM network=10.0.1.0

ROUTER B CONFIG

INTERFACE
Interface Name = wireguardR
ListenPort = 6868 (not really required }
Public Key Generated--> To be entered on peer settings Router A

PEERS
PublicKey ---> to be entered is from Router A
Endpoint = mynetname-Router_A: ( Router A has a public dynamic IP )
Endpoint port = 6868
Allowed IPs (to match and select local user destination IPs, to enter tunnel outbound) = 0.0.0.0/0 ( Outbound Flow - internet traffic for Router B subnet )
Allowed IPs (to filter remote user source IPs to exit the tunnel inbound) = 172.168.0.0/30 (Inbound Flow - admin inbound traffic )
Thus Allowed IPs=0.0.0.0/0 ( the admin IPs are contained with the 0.0.0.0/0 )
keep alive=30 secs

IP FIREWALL RULES - { need to allow admin to access Router and Server on Router B }
add chain=input action=accept in-interface=wireguardR src-address=172.16.0.0/30 dst-port=winboxport
add chain=forward action=accept in-interface=wireguardR src-address=172.168.0.0/30 dst-address=IPofServer
Note: If the admin wanted access to the whole LAN subnet - dst-address=10.0.1.0/24.

IP ROUTES
dst-address=0.0.0.0/0 gwy=wireguardR table=useWG { required to force Router B LAN users to go out wireguard tunnel vice own ISP WAN }
/routing table add fib name=useWG
/routing rule add action=lookup-only-in-table src-address=10.0.1.0/24 table=useWG

Note: No other routes are required as the IP address (see below) for the wireguard interface will automatically route replies from the admin back through the tunnel.

IP ADDRESSES
/ip address
add address=172.16.0.254/24 interface=wireg

You should make it clearer that the whole business with another routing table is only needed (unless you're doing something special) when you want to use the tunnel to access internet (i.e. with 0.0.0.0/0). If it's simple site to site, LAN to LAN, route in main routing table to remote LAN is enough.

.....................

For connecting to a VPN provider that supports WireGuard you can find here two scripts I wrote. It uses the config files generated or provided by the VPN providers and it will create the WireGuard lines, routing, NAT. You have then decide yourself which traffic can use the VPN by marking the routing in Mangle.

The dynamic script (first one) needs a bit of TLC and on the WG lines itself. As soon I have some more time I will adapt that. That skript is for high-jacking a current WG connection created by a external client connection on a other device.

Link to my posting: viewtopic.php?p=906167

.......................

Very Nice work @anav --- many will enjoy it 4 certain ....

BUT but But .... there is ABSOLUTLY no Client/Server relationships using WireGuard .... there is only Peer to Peer and YES each PEER can act like a HUB where other Peers can have orgasmic relationships .... and that is called a sexy MESH .... I do understand that many will want to remain in the Client/Server world because of habitual habits gained from many years of slavery to that concept. So dump the slavery and become FREE to enjoy a true PEER to PEER joining much like men and women do in privacy .... and not like an an orgy clients being served by a Server ...

.....................

............................

Nice, but you should include configuration examples...

For connecting to a VPN provider that supports WireGuard you can find here two scripts I wrote. It uses the config files generated or provided by the VPN providers and it will create the WireGuard lines,

…… …….

IMO mixing VPN providers with your private WireGuard establishment is not a good idea … it may be convenient but a bad security practice.
one can create multiple WireGuard Interfaces … each can be dedicated to the Purpose intended …
wg_ipvanish
wg_home
etc..

.... there is ABSOLUTLY no Client/Server relationships using WireGuard ....

Of course there is, not on protocol level, but for example all these "browse internet through us" VPNs are clearly functioning in client/server mode, you as client are connecting to their server, not the other way.

@anav
Thank you for the post, I enjoyed reading this.

@Sob
So you want to be picky "eh" and diverge into the client/server model where content served is king "eh"

Not going to cut it with me because Peer's are bidirectional unlike C/S ... however you can choose to look at it in your distinct way. Certainly a Peer has access to content in many forms on a Peer to Peer basis and a Peer can be served by a server residing within the Peer's domain.

What’s the difference between peer-to-peer (P2P) networks and client-server? A good read

@anav

Wow that's really nice post, lots of effort is put into it, I hope this will help a lot of people who also want to setup WG. I can help with practical section, testing various configurations and so on as I have quite a lot mikrotik's routers.

@mozerd: I'm just saying that even though Wireguard as protocol is peer to peer, it's not always used that way. You know those VPNs I mentioned, right? Every single client is connecting to their server, no two clients are connecting to each other, because they don't need it, they don't want to communicate with each other. Same for "access to my home NAS" scenario, I may want to do it for multiple devices, but if those devices all need to access only NAS and don't need to communicate with each other, it's again simple client/server. There's no need for any p2p mesh, it would be completely useless, because those devices simply don't need to communicate with each other.

...........................

Keep alive: Set it to something between 20-45 secs for example..

@anav can you elaborate more on this ... ?

...........................

.........................

If routerOS can reconnect to the other side, the keep-alive can be long not needing the connection open all the time.

I have a VPN provider that gives only one-connect-privatekey. If the connection closes due reboot or connection loss, a new private key has to be obtained. For this connection, I use a short keep-alive so that it stays open till the connection is lost or ended by either side.

I rather use reconnect so that when not needed it can be disconnected and reconnected when needed. Takes few seconds or less to do that.

It depends on what timeouts other routers with stateful firewalls, that will be in the way, have. If you going to have site to site config with both peers having either public address, or at least forwarded port, you don't need keepalive, because each can contact the other one at any time. But if one peer is going to be behind NAT, with no incoming connections possible, then you want keepalive, to keep the tunnel working even when nothing uses it for a while. The peer behind NAT (client) can always contact server, but from other side it's not possible, so any communication initiated from server's side would have to wait until client connects.

RouterOS has this as default:

udp-timeout (time; Default: 10s) - Specifies the timeout for udp connections that has seen packets in one direction
udp-stream-timeout (time; Default: 3m) - Specifies the timeout of udp connections that has seen packets in both directions

But important is what other routers have, I don't know if there's any standard for it.

@sob the manual indicates that 25s ok keep alive time for a host behind NAT would benefit the connection...
So am not sure if that relates to the 10s UDP time out...

By the way yesterday i was configuring a wireguard server that is behind a Main Router, so the wireguard port was dst nated to the wireguard server from the main router and ofcorse accepted on input chain on the later... i was keep getting that the handshake for peer did not complete again and again although it was successfully completed if i was connecting to the wireguard server through another VPN just for testing, so it was not a matter of keys or anything... after trying almost everything i just changed the default UDP port of wireguard and to my surprise it worked, the handshake completed... I can only guess the default port was blocked somewhere along the way...

10s is for "connections" (udp don't really have any) that have packets only in one direction (so no responses). WG will have some packets in both directions, so the timeout will be 3m. And then even packets in one direction should be enough to keep it open. But these are just ROS defaults, other routers may have shorter timeouts.

ok @sob, good to know that...

But if one peer is going to be behind NAT, with no incoming connections possible, then you want keepalive, to keep the tunnel working even when nothing uses it for a while

So an example of needing keepalive would be road warriors ?

Not sob but Yes.
Or e.g. LTE devices behind cgnat.

ok...

In case of site to site WG connections, if you don't define the endpoint on both peers but only on one, then is it still true that each peer can reach the other one or not ( in order to keep the tunnel up ) ? How does the peer with no endpoint defined knows who is the peer to contact ?
So, would we still need keepalive in such case ?

........................

My understanding is that the peer keep alive initiated by the client side should keep the tunnel open for two way traffic.

ok, but what if the client for some reason delays to reach the server, then the tunnel will drop.

My understanding is that the peer keep alive initiated by the client side should keep the tunnel open for two way traffic.

Once understood no further info is required as per the following:
https://www.wireguard.com/quickstart/

NAT and Firewall Traversal Persistence
By default, WireGuard tries to be as silent as possible when not being used; it is not a chatty protocol. For the most part, it only transmits data when a peer wishes to send packets. When it's not being asked to send packets, it stops sending packets until it is asked again. In the majority of configurations, this works well.

However, when a peer is behind NAT or a firewall, it might wish to be able to receive incoming packets even when it is not sending any packets. Because NAT and stateful firewalls keep track of "connections", if a peer behind NAT or a firewall wishes to receive incoming packets, he must keep the NAT/firewall mapping valid, by periodically sending keepalive packets.

This is called persistent keepalives. When this option is enabled, a keepalive packet is sent to the server endpoint once every interval seconds. A sensible interval that works with a wide variety of firewalls is 25 seconds. Setting it to 0 turns the feature off, which is the default, since most users will not need this, and it makes WireGuard slightly more chatty. This feature may be specified by adding the PersistentKeepalive = field to a peer in the configuration file, or setting persistent-keepalive at the command line. If you don't need this feature, don't enable it. But if you're behind NAT or a firewall and you want to receive incoming connections long after network traffic has gone silent, this option will keep the "connection" open in the eyes of NAT.

@mozerd thanks...
But then to my understanding it has to do with site to site connections as well...

But then to my understanding it has to do with site to site connections as well...

Regardless of network topology it’s ALL Peer to Peer, so the key aspects to consider is if NAT and/or Stateful Firewall where connection tracking is used the PersistentKeepalive = should be used ….. I use 25 seconds and that works well for me.

Ideal site to site is between two static public addresses (both stay the same and accept incoming connections). If you have that, there's no need for keepalive. Otherwise you probably want it. If one side is behind NAT and can't accept incoming connections, then for sure. And even if it can, but has dynamic address, it's useful, because instead of waiting until some hostname updates to new address, keepalive will notify the other side about changed address earlier.

@sob i agree...
But since it only transmits data when a peer wants to send a packet, that remains the same whether it is a site to site connection or not...
On a site to site connection you still have a connection tracking table, so i guess the connections will timeout unless keepalive is being set... since nor the client nor the server endpoints will try to reach each other unless data are being requested...

Hence the name " keepalive", no ?

I'll make @mozerd happy, there's nothing special about site to site or road warrior, it's always connection between two peers (and then there can be other connections between more peers, but that's not the point here). If peer has behind it just single address, subnet, multiple subnets, it doesn't matter. The only difference is whether both peers are at any time reachable from the other one. That's the case when both have static public addresses and accept incoming connections. Then it doesn't matter if connection times out, because any of them can always open new one.

.......................

Right now I can tell you one thing, it desperately needs an image, diagram showing what is where. There's too many unfamiliar subnets at once, it's too easy to get lost in that.

And if it was me, I'd start with something much simpler, site to site as one config, road warriors as another, connection to "browse internet through us" VPN (is there any short commonly used term for that?), show the basic principles without having too many different things at the same time, and only then I'd put all that together. Because target group is mainly beginners who don't know much about it, and will often need only one of those configs. If you're familiar with routing, you don't need a guide like this, it's all pretty much obvious.

Has anyone else noticed that every 2 minutes that the handshake takes place, the old keypairs are destroyed and new ones are created ?
I 've looked at it and they keys are actually rotated ( rotating keys ), so the old ones are destroyed and new session keypairs are created...
https://www.wireguard.com/protocol/

Anyone else noticed that ?

............................

...and yet some drawings would indeed make it a lot more clear

...................

Say what ? Huh ?

Problems with SCENARIO-4:

- no admin's client in image
- no 172.16.0.x addresses in image
- not clear enough description that Router A has two WG peers; it looks like there's one with two allowed subnets, but it's two with one subnet each (and for admin it should be just single address)
- 10.0.1.254/24 on Router A doesn't make sense when it's Router B's subnet
- mixed masks 172.16.0.254/24 / 172.16.0.0/30

.........................

You can assign as many addresses as you need, that's ok. But if 10.0.1.0/24 is Router B's LAN, what is 10.0.1.254/24 doing on Router A? Yes, it will provide working route from Router A to this remote subnet, but also useless address that won't be reachable from any other 10.0.1.x connected behind Router B (unless you enable proxy ARP on Router B's LAN interface). So why not just add simple non-confusing route to 10.0.1.0/24?

About masks, example has one peer, so why /30 with four addresses? Yes, it will work, but is it supposed to be somehow better with /30 than just with admin's one 172.16.0.x/32? And what address and allowed addresses will admin as client have? If 172.16.0.254/24 should be reachable, then allowed addresses will have to include either that one address or whole 172.16.0.0/24. There's no place for /30 there either, so only thing it does is to confuse reader.

.....................

Hence, it makes sense to limit firewall rules and allowed IPs to just that smaller set.

100% agree ...

................

The 10.0.1.254/24 is an IP address for the WIREGUARD INTERFACE, and it WORKS.

It depends on how you define "works". I agree that it sort of does, but only accidentally, such config is still nonsense. Once more, in different words, this is what Router B has, including addresses shown only in image:
Do you see the 10.0.1.1/24 on LAN? Then how can 10.0.1.254/24 from same subnet be on Router A? It "works" because Router A needs route to 10.0.1.0/24 pointing to WG interface and this address creates it. When connecting from 192.168.50.x (device in LAN A) to 10.0.1.x (device in LAN B), if it was allowed, it would work fine. Same for admin's access to LAN B. But if you try to access 10.0.1.x in LAN B from Router A itself, it won't work, because it will use 10.0.1.254 as source, so packet will reach target, but there won't be any response. Device in LAN B will see 10.0.1.254 as local reachable address, will send ARP request for it, but won't get any response, because that address is not in LAN B. And I was wrong before, proxy ARP wouldn't help either, because not even Router B has any idea that 10.0.1.254 is at Router A.

The /30 expresses the fact that the admin has at least 3 devices laptop, desktop, smartphone that they may wish to use at any time to connect to the Router.

Nothing against that, but it should be explicitly mentioned that admin needs multiple simultaneously connected devices. Otherwise you'll have people wondering why there's /30 for one device.

......................

....................

Listen, @anav's brother, it's not difficult.

Router A needs route to LAN B (10.0.1.0/24). That can be either simple route with interface as gateway (/ip route add dst-address=10.0.1.0/24 gateway=wireguardM). But since @anav finally decided to try addresses, gateway can be the address on Router B's WG interface (/ip route add dst-address=10.0.1.0/24 gateway=172.16.0.X). Except (another mistate I noticed now) it can't, because he has same 172.16.0.254/24 on both routers. He could use e.g. 172.16.0.1/24 on Router A and then it would work with .254 on Router B (/ip route add dst-address=10.0.1.0/24 gateway=172.16.0.254).

As for your questions, I'm not sure what exactly you mean, and you're inventing addresses not used in example.

Listen, @anav's brother, it's not difficult.

Twin Brother ---

And don't even start to think anything about "network" parameter of IP address. Ignore it and never ever set it manually, except in single special case with point to point /32 addresses.

..............................

It's not exercise to exclusively use only IP addresses or only routes. You can have both, they won't bite each other.

If you enter IP address 10.0.1.254/24, then network address is 10.0.1.0/24, and in RouterOS you'll see it as network 10.0.1.0. But you should not worry about this parameter at all, it's computed automatically, you don't need to (and shouldn't) touch it. In fact, it should not be editable at all, only reason for that is that it's also (mis)used for point to point addresses.

Just because something works doesn't mean that it's correct. You can get rid od mice in your house using dynamite, and it will work, there won't be no mice after. But is it the best choice? Nah. What you do here with 10.0.1.254 on Router A won't have such big impact, but it's still wrong.

I wouldn't use /30 here. Except maybe in firewall rules, if I need to match four addresses covered by /30. But not as mask for assigned addresses. If they are private ones, then just use /24, it's simple to understand (subnet contains addresses with any last number) and there's plenty of private addreses, so you don't need to save any.

......................

No, it's not that 10.0.1.254/24 would be wrong. It's perfectly fine, only it's in wrong place.

It's like if you put hat in your pants instead of on your head. It doesn't make the hat wrong, it's just that it doesn't belong there (even though, I guess, it can still do something useful there; I didn't think about it too much ).

@404Network
So you wanted to loose your Guru status and decided that 404Error condition would allow you much more leeway ?… very appropriate

........................

.......................

The big round thing with eyes and ears is the head I meant, and yes, it did cross my mind that further clarification will be needed for you.

But back to networking stuff, if I simplify your example a little:
and tell you that the link between routers is not WG tunnel, but plain old ethernet cable connecting dedicated ports on routers, would you use 10.0.1.254/24 as <address X>? You wouldn't, because it's clearly wrong. As you quickly find out if you don't believe me and try it. It's one of basic rules that you don't have same subnets on different interfaces, I'm sure you heard about that. So why you suddenly want to do this different thing with WG? Where it happens to work, but only partially, as I already explained to you twice.

No without warning they decided to tell me they didnt like me recommending something else for a wireless solution by removing access to my login.

So did they really tell you that, or is it your assumption that it was this one of your crimes that was the reason? Not something else like your quest against addresses, or something? But yeah, this being MikroTik forum, some voices saying "MikroTik is shit, go buy something else" are perhaps a bit too loud, I wouldn't blame them for not liking it.

........................

You already had 172.16.0.x/24, but ok, let's scrap that and put 192.168.88.1/24 on Router A's WG interface and 192.168.88.2/24 on Router B's WG interface:
If it was ethernet and not WG, then Router A would have:
And Router B would have:
And now if it actually is WG, here comes the magic, wait for it, you can have exactly the same thing! And that's why all tutorials for beginners use it, because it's exactly the same as with ethernet, you don't need to remember anything new.

Then How would the Router know to return Internet traffic from 10.0.1.0/24 back to the tunnel.

Same way it does in your example, because there's routing rule saying that anything from 10.0.1.0/24 should look up route in table useWG (which contains exactly one default route pointing to Router A).

The router does not check allowed IPs for traffic returning from the normal ISP WAN.

I have no idea what you mean. WG's allowed IPs have nothing to do with routing, it's different level. Yes, they need to match, because if you route something to tunnel, but it's not allowed for (any) peer, it won't work. But it's something that happens only after routing decision, routing itself doesn't care about that.

....................

I have no idea what you mean. WG's allowed IPs have nothing to do with routing, it's different level. Yes, they need to match, because if you route something to tunnel, but it's not allowed for (any) peer, it won't work. But it's something that happens only after routing decision, routing itself doesn't care about that.

@Sob ... I have to disagree with your comment that WG allowed IPs have nothing to do with routing ....
For the sake of keeping it simple taking the KISS approach:

Lets use the following Site to Site example:
We can see that for the peer mox2.mydomain.rocks the AllowedIPs field is set to 10.90.99.2/32, 192.168.100.0/24.

AllowedIPs does two things:
1. It adds a route to the given networks, i.e. packets addressed to 10.90.99.2/32 or to 192.168.100.0/24 will be routed through the WireGuard interface to that peer
2. It will allow packets with the source IPs 10.90.99.2/32 or 192.168.100.0/24 to be routed from the given peer on the WireGuard interface
As to point 2 --- any packet from the given peer with a source IP address which is not listed in AllowedIPs will be discarded! While this does not replace a firewall, it serves a an integral part of Wireguard’s security model.

IMO, this discussion between you and 404 [anav's twin] is making it far to complicated for the new user. By keeping the model simple to START and the model gets expanded due to added complexity further "routes" can be added. Because 404error condition is a networking study in progress small steps are much better that GIANT steps

For a very GOOD READ on Allowed IPs Justin Ludwig from PRO CUSTODIBUS put a lot of effort in the following article ... highly recommended by me

.............................

@404Network: If you insist on either your:

a) less common but not too wrong method without addresses
b) completely messed up method with address on wrong interface and wrong router

Then please stick with a). It may confuse few beginners who will wonder why pretty much every other tutorial has addresses and yours doesn't, but let's be optimistic and assume that it will stimulate them to think about it, and will lead to better understanding of the thing (my usual opinion is that optimists should be shot, but maybe this one time it can work). Option b) could work as curiosity, or as some kind of quiz for advanced users, but it's harmful for beginners.

..... dont care about wireguard docs that dont pertain to MT setup and their unique wireguard parameter setup ....

I do not happen to agree with your position nor do I like your undisciplined approach towards networking in general ... Sob is trying hard to teach YOU but your stubbornness is inhibiting any progress on your part ........ I was just making a specific comment made by Sob .... RouterOS foundation is Linux as is WireGuard and as such the valuable information I linked to certainly pertains to RouterOS because its LINUX ..... once you inwardly digest the content ESPEICALLY when to add "Routes" and some other revelations of interest.
===============
===============
BACKGROUND

You use the AllowedIPs setting of WireGuard to configure which blocks of IP addresses should be routed through which remote WireGuard peers. If you want to access everything through a peer, configure its AllowedIPs setting to the following:

AllowedIPs = 0.0.0.0/0, ::/0
This indicates to WireGuard that all IPv4 addresses (0.0.0.0/0) and all IPv6 addresses (::/0) should be routed through the peer. Note that you can specify multiple blocks of addresses on the same line, separated by commas, like above; or you can specify them individually on separate lines, like below:

AllowedIPs = 0.0.0.0/0
AllowedIPs = ::/0
If you want to access just a single block of IP addresses through a WireGuard peer, like say a block of IP addresses at a remote site that range from 192.168.100.0 to 192.168.100.255, you’d set the AllowedIPs for it to the following:

AllowedIPs = 192.168.100.0/24
But what if you want the inverse, where you want everything except a single block (or two or three specific blocks) to be routed through a WireGuard peer? In many cases, you have subtract the exceptions from the block of allowed addresses, and set AllowedIPs to the resulting (often long) list of blocks.

For example, say you want to route all Internet traffic through a WireGuard peer, except that you don’t want to route the traffic of your internal networks through it, which use various subnets within the private-use 10.0.0.0/8 block. To make that happen with the AllowedIPs setting, you’d have to configure the peer with the following AllowedIPs:

AllowedIPs = 0.0.0.0/5, 8.0.0.0/7, 11.0.0.0/8, 12.0.0.0/6, 16.0.0.0/4, 32.0.0.0/3, 64.0.0.0/2, 128.0.0.0/1
That’s the list of blocks you get when you subtract 10.0.0.0/8 from 0.0.0.0/0 — conceptually you might express it like the following:

AllowedIPs = +0.0.0.0/0, -10.0.0.0/8
Or another way of expressing it might be:

AllowedIPs = 0.0.0.0/0
DisallowedIPs = 10.0.0.0/8

======================
======================
A BETTER ALTERNATIVE

As you can see, subtracting one block of IP address from another block can result in a painfully long list of blocks to add to the AllowedIPs setting. On some platforms, like mobile phones, you don’t have any other options — but on Linux, you have some powerful routing tools available that can simplify the situation.

In most cases, you can simply add a route to your main routing table to “subtract” a block of IP addresses from those routed via the WireGuard tunnel. And you may even find that the necessary route already exists — in which case you don’t have to do anything at all.

For example, say you want to route everything in the 10.0.0.0/8 block to a WireGuard peer, except for 10.0.1.0/24. Instead of subtracting 10.0.1.0/24 from 10.0.0.0/8 with the above calculator, and setting the peer’s AllowedIPs to the result, just set the peer’s AllowedIPs to the full 10.0.0.0/8 block. Outside of WireGuard, add an explicit route for 10.0.1.0/24 to your main routing table. Because 10.0.1.0/24 has a longer prefix length than 10.0.0.0/8 (/24 vs /8), the Linux routing engine will automatically use the route for 10.0.1.0/24 over the route for 10.0.0.0/8.

In fact, you may find that you have the necessary route for the exceptional block already set up — run the command ip route show table main (or just ip route, which by default lists the routes of your main routing table) on the host to see what (IPv4) routes you have already:

$ ip route show table main
default via 192.168.1.1 dev eth0 proto dhcp metric 1000
10.0.0.0/8 dev wg0 scope link
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.123 metric 100
If do you see a route listed for your exceptional block (10.0.1.0/24 in our example), you won’t have to add anything. If you don’t see it listed, however, you’ll have to add the route yourself. Fortunately, this easy — you just need to know the IP address of the gateway for the block, and the network interface to get there. Often, this will be the same as your default gateway (the line beginning with default in the above listing).

The simplest way to do this is to add the following ip route add and ip route del commands to the PreUp and PostDown scripts in your WireGuard config. To add a route for the 10.0.1.0/24 block with 192.168.1.1 as the gateway using the eth0 interface, add the following PreUp and PostDown settings to the [Interface] section of your WireGuard config:

[Interface]
PrivateKey = ...
PreUp = ip route add 10.0.1.0/24 via 192.168.1.1 dev eth0
PostDown = ip route del 10.0.1.0/24 via 192.168.1.1 dev eth0

[Peer]
PublicKey = ...
AllowedIPs = 10.0.0.0/8
Note that you can have multiple PreUp and PostDown lines in your config (similar to AllowedIPs). Multiple PreUp or PostDown lines are equivalent to a single PreUp or PostDown line joined together by semicolons.

Also note that the ip route commands above apply only to IPv4 addresses — for IPv6 addresses, you have to add the -6 flag (eg ip -6 route show table main).

AllowedIPs does two things:
1. It adds a route to the given networks, i.e. packets addressed to 10.90.99.2/32 or to 192.168.100.0/24 will be routed through the WireGuard interface to that peer

It depends. If I give this config to e.g. WG client on Windows, it will add routes for all AllowedIPs, because it assumes that I want them reachable, otherwise what would be the reason to list them. But WG client on Windows is high level tool. RouterOS on the other hand requires you to configure things manually. So you can have allowed-address=10.90.99.2/32,192.168.100.0/24 and:

a) no manually added route pointing to WG interface (and also no IP address on WG interface that would create connected route) => WG won't be used for any outgoing traffic
b) manually added routes for same destinations pointing to WG interface => same result as with WG client on Windows
c) route to e.g. 192.168.0.0/16 pointing to WG interface => if there's packet to 192.168.1.1, RouterOS will try to route it to WG interface (you will see it in forward chain), but WG will report that it's unreachable.

That's what I meant by "WG's allowed IPs have nothing to do with routing". Feel free to improve wording, but the point stands.

......................

Don't worry, MikroTik won't add any artificial unnecessary limitation only to stop your creativity (I'm not sure if it's the best word ). You're not that much important, and this is far from being the only thing in RouterOS that can be misconfigured.

.......................

Main point, in case you missed it:

viewtopic.php?p=913951#p913951

b) is your latest invention with 10.0.1.254 address. Just don't do that. Not because of me, I can take it, but it's really so wrong that no beginner should ever see it.

............................

Once more, it's not the address or its format, it's that the address in your example is in wrong place, on wrong interface and even on wrong router. I told you and then tried to explain it several times, starting in this post:

viewtopic.php?p=913363#p913363

I also told you to ignore the "network" parameter of IP address, just don't touch it, pretend that it doesn't exist, and you can live happily ever after.

And no, you can't blame me for not giving you simple answers to your questions. Sometimes it's possible. But if you ask me something like "is carrot bigger animal than dog?" (some questions feel like that), I really can't give you yes/no answer.

........................

Let's take the simple ones first:

1) You swapped 10.255.255.1 and 10.255.255.2, I assume it's innocent mistake. Gateway to remote subnet should be the address on remote end of tunnel.

3) We've been over this, it's not what's usually used in tutorials, but ok, it could be like this. You also mentioned gateway=<WG interface> in 1) already.

And now the star of the evening:

2) No. No! NO! Hell NO! It's utter nonsense. It doesn't make any sense whatsoever.

192.168.16.0/24 is MK2's LAN subnet. It belongs on MK2's LAN interface. Why would you take address from MK2's LAN subnet and put it anywhere on MK1? Yes, it will create route to 192.168.16.0/24 pointing to WG tunnel. But if you need route, then just add route, don't add completely useless address (*).

And before that idea gets anywhere close to your brain, no, it's not validation for your original "no addresses needed at all". It's not just two things (addresses / no addresses), it's three (correct use of addresses / no addreses / completely wrong use of addresses). This is the third one.

And what does it have to do with allowed IPs? Didn't I just describe what's the relation between routes and WG's allowed IPs?

--
(*) Unless you're setting traps for enemies who would take over your router, to mess with their brains, then it would be ok. But I'd argue that it's very special case and shouldn't be in tutorial for beginners. Unless it's "Beginner's guide to guerrilla warfare, cyberspace edition".

And if you still don't understand what's wrong with 2), it's like if you wanted to route traffic to Google's DNS resolvers (8.8.8.8, 8.8.4.4) via tunnel, and you'd do it by assigning 8.8.0.1/16 to your WG interface. It would work (plus it would take "few" more addresses, about 65k of them, but let's skip this small detail). But it would feel wrong, correct? And don't you dare to say it wouldn't.

.........................

1) Let's say your ISP gives you public address x.x.x.2/29 (static, dhcp, doesn't matter) and default gateway is x.x.x.1. I already spoiled it, but which one you'll use as gateway? Will it be local x.x.x.2? Of course it won't, it will be remote x.x.x.1.

Or if you have large home network with main LAN 192.168.88.0/24, and for some reason you want another LAN 192.168.99.0/24 connected behind another router. Main router has 192.168.88.1 and the other one has 192.168.88.10. On main router you'll add route: /ip route add dst-address=192.168.99.0/24 gateway=192.168.88.X. And the X will be 1 or 10? There's no chance you'll pick wrong answer (I hope), of course it will be remote 10.

And do you remember the pattern I'm bringing over and over, about things being the same? Surprise (not really), it's the same with WG! Gateway is the remote address. But how does WG know that it's there? Well, it doesn't really know for sure that this specific address exists, but if it exists, it knows where it is (reachable using which interface). How? Same way as in previous two examples, because it has address with mask, which defines the subnet, creates connected route pointing to the interface this address is assigned to, and this route tells it that all other addresses from this subnet are on that interface and nowhere else.

There is small difference, in first two examples there's ethernet and router actually checks using ARP if the address exists. With WG there's no ARP, because it's L3 tunnel, so router blindly assumes that all addresses in defined subnet are there (except the one that this router has). And if such address is used as gateway, it's basically saying that traffic should be sent to that interface. It doesn't require doing anything else with that address.

2) No, you don't see people doing this. Something with addresses, yes. Exactly this, no way. Not without some additional config that could make it somewhat acceptable, but still quite unusual, and I haven't seen anyone do that (but let's not get into that, it wouldn't help you to understand what I'm trying to explain, maybe later, when you're ready).

..........................

And what's the problem? You do understand first two examples (gw from ISP, subnet behind another router), right? You must, otherwise I don't know what I've been doing here last four years. So why it suddenly becomes hard to understand with WG?

[......................

An ip address is 4 octets of 1 byte = 4x 256.
That subnet number is the number of bits to use for the subnet definition.
So v.x.y.z/30 means the first 30 bits stay fixed. 2 bits to play with = 4 combinations within that subnet (of which usually 00b goes for subnet ID and 11b means broadcast).

Gateway is whatever you define it to be. Can even be in a different subnet.
I usually use .1 for my devices.
One of the commercial partners my client uses always defines .254 for their gateway routers.
Where I am now there are 2 subnets in one big LAN x.y.112.0 and x.y.113.0 but there is only one gateway x.y.112.254 for both subnets.

I think If the subnet is /30 then the first IP would be network and gateway and the last IP is broadcast.

........................

duplicate

I think If the subnet is /30 then the first IP would be network and gateway and the last IP is broadcast.

Missing my lack of knowledge /30 which four 0-4 50-54 125-129 etc.........

So if the /30 exist inside a bigger network like /24 then if you use an IP calculator and you set it to calculate a /30 for this specific IP then the 0-4 or 50-54 is happening depending on what specific IP you used for /30 calculation. then it might be 49-53 depending on what is the CIDR for the bigger network.
If it's not a part of a bigger network then it could be whatever you want it to be. if you select 125 then it's 125-129 if you use 50 then the range is 50-54 ( Wrong )

If it's not a part of a bigger network then it could be whatever you want it to be. if you select 125 then it's 125-129 if you use 50 then the range is 50-54

I don't think so.
125 decimal = 01111101 binary.
If you want to use /30 you need to have multiples of 4 so you can play with the last 2 bits.
So 124 or 128.

.125 would be part of a network 124 (all 0's at the back) with broadcast 127 (all 1's at the back), 125 and 126 are then the 2 adresses you can use.

Binary system is the base.

@holvoetn

Correct, Thank you. I need to take care of my network+ too.

To understand subnets and masks, play with http://www.subnetmask.info. Start with defaults, select size of network in third field ("enter the required number of nodes/hosts per network") and click Calculate. Then click List Network to view all networks of that size.

If you enter 256 as number of hosts, you'll get the most common /24 mask. Nice thing about it is that only last number changes (and in full range), so it's always 0/1-254/255 (<network address>/<first usable address>-<last usable address>/<broadcast>).

If you enter 128, it will be /25, so half of /24. And you'll have two: 0/1-126/127 and 128/129-254/255.

If you enter 4, it will be /30, so 0/1-2/3, 4/5-6/7, 8/9-10/11, etc.

Or you can have larger subnets, 512 will give you /23, which spans over two /24s, so e.g. x.x.0.0/x.x.0.1-x.x.1.254/x.x.1.255.

... I dont understand why .1 doesnt work and .2 works sigh...

It's really simple, don't overthink it. Gateway = different device. So gateway address must be address of that device. That's it. If you have .1 and gateway has .2, then .2 is the right choice. And .1 isn't, because it's on your own router, so it doesn't really tell it where else it should send those packets. And yes, sometimes the interface can be used as gateway. But when it's address, it's the remote one.

............................

Yes, or the interface that ip belongs to

.............................

In other words, the IP address and the gateway look eerily similar do they not??
Why does Mikrotik call that address the gateway then??
(default ip address 192.168.88.1/24 dns-server=192.168.88.1 GATEWAY=192.168.88.1

Sure they do look similar, because gateway address is also IP address, only on another device. So if router has 192.168.88.1/24 on LAN and in DHCP server config you have gateway=192.168.88.1, it mean that this router is gateway for (or "used by" may be better term) other 192.168.88.x devices in LAN. But gateway for this router is whatever address the upstream router has.

It’s the IP address of the virtual network interface that WireGuard sets up for the peer; and as such you can set it to whatever you want (whatever makes sense for the virtual WireGuard network you’re building). AHA!!!!

AHA not. The "you can set it to whatever you want" means that you can choose anything you want, like 192.168.100.x/24, 10.11.12.x/30, 10.56.x.x/16, even public addresses if you have enough of them, whatever makes sense for you network. It does not mean that you should create nonsense config where you replace routes by addresses/subnets that are used elsewhere, as you tried to do.

If we set it to /24, that would indicate to the local host that other addresses in the same /24 block as the address itself (10.0.0.0 to 10.0.0.255) are routable through the interface. BINGO!!

Again, it's not saing what you think. No BINGO. It means that if you're going to have several clients/peers and each will have 192.168.56.x, it makes sense to assign 192.168.56.1/24 to WG interface, to tell router where to look for those 192.168.56.x clients. Assigning 192.168.88.1/24 to local WG interface, when 192.168.88.0/24 is in fact remote subnet connected behind peer is still nonsense.

...........................

No one can say I didn't try. Let me put it this way, if someone tells you to put anything you want on your pizza, they don't mean rat poison. If it works for you, knock yourself out, but please don't try to serve it to others.

WireGuard (Site to Site VPN Example) in Pictures and Text

This SUPERB presentation is done by Rick Frey a MikroTik Consultant who is 2nd to none IMO ...

@anav ... MikroTik WireGuard configuration Pictures are far more desirable for the new user ...
and To BOOT properly done by the author [wg-interface=IPaddress]

Take note of the following by Rick Frey

Add an address to the WireGuard interface on each router.

This address is unique and special. WireGuard doesn’t handout IP addresses to the far side like SSTP or OpenVPN. You have to manually add that IP to the WireGuard Interface. That IP address causes a DAC (Dynamic Active Connected) route to be populated in the main routing table and it will be the IP address that we use latter on to create static routes. Whatever the destination address of that DAC route is, it needs to be specified in the “Allowed Address” on the far side. I played with multiple CIDR combinations and sumerization and it all worked as long as the “Allowed Address” list on the far side contained the IP address on that Interface.

.............................

.............................

Brilliant take-down, of the fallacy's of using IP address for WG interface as the only viable method.
I would like Mozerds take on point (2) and roaming endpoints and specifically how this works in MT.................... using an example.

Yes it does apply to MT ... Rick uses MT in all of his examples .... what you have forgotten is how Cryptokey Routing works

................................

@anav ... When discussing RouterOS YOU must MUST Must remember that WireGuard is an integral part of the Linux KERNAL and as such Tik have to follow tightly in its footsteps ... I have ZERO knowledge how closely Tik follow the rules but regardless its ALL LINUX ... all Tik have done is prevented its users from making changes to how Tik want its version of LINUX to work through the SHELL it provided ... that shell is called RouterOS.

Last point on this rather senseless journey you are on .... RouterOS is not a PHD Tool .... its made for people who are network knowledgeable ... not for the PHD crowd ... For the network crowd the NUMBER ONE Tool is called Ping .... for the WireGuard world if one wants to calculate the effective MTU of the WG interface Ping is the Tool of Choice .... IF you do not assign a IP Address to the WG Interface then you cannot use Ping .... If you want to TEST out the WG Interface PING is the TOOL that the great majority of admins will GoTo .... etc etc etc.

.............................

Process of elimination.
If you can not ping the other side, you don't know where in the chain it's broken -> multiple steps.
If you can not ping WG interface address on local side, you know where to look first.
Then WG address on remote side. If that works, you know the tunnel is ok.
Then router on remote side. Etc etc ...

I understand the ping crutch, only needed if you get it wrong the first time ;-P.

Actually you do not understand .... and that is the sad part for someone who I consider smart.
Let say the default MTU for WG is 1420 ... which it is BUT in some instances that MTU setting will cause throughput degradation because packet fragmentation or the throughput is not as fast as it should be ... so you will need to test and see what is the effective MTU setting for the WG Tunnel to get the optimal THROUGHPUT ....
Use Ping to Find a Path’s MTU

You are TESTING the WG Tunnel and that Tunnel is the WG Interface .... if that Interface does not have a IP address how are you going to TEST it.

.........................

remember I have no formal training!

So you do not like the proper way and you want to rebel
IT Basics: The Ping Utility Explained

I read the main part (didn't dive much into examples, too many subnets, not enough images) and I find some parts confusing. Not counting funny bits like address 172.168.10.5.2 or port 80901.

In (3) you have (i) and (ii), and I had to read it several times, trying to find what's the difference, but there really isn't any. You're splitting incoming and outgoing traffic as two different things, but why? Whether there's communication initiated from local to remote subnet, or from remote to local subnet, it doesn't matter, because unless you're doing something special and unusual (e.g. some asymmetric routing), it will be bidirectional communication. And as far as routing is concerned, it doesn't matter which side started it. In both cases you need route to remote subnet, just one (if there's one remote subnet). But when I see it split in (i) and (ii), at first sight it seems there should be two routes.

In (4) it's hard to understand what belongs where. Those four addresses at the beginning, it looks like I should put all of them on main router, because the whole block starting with "/ip address" uses RouterOS syntax. But they are in fact addresses for individual devices. Also the choice of addresses, maybe it's just me, but wouldn't it be better if main router/server, as the most important component, had .1 and was mentioned first before others? There are also different mixed up subnets.

And when showing command to assign address, don't include network parameter (/ip address add address=172.10.5.5/24 interface=wg-local network=172.10.5.0). It suggests that it should be entered manually, but it's almost never the case. RouterOS will compute it automatically, and it won't make a mistake, unlike user entering something and not knowing why exactly.

@anav
very daunting presentation but well laid out. Perhaps it should be broken down into a series of posts

suggestions ... test each scenario out so that it will reflect reality under MikroTik ..

I've done some more testing in my Lab and confirmed that when Donenfeld's WG 'clients' are used under Windows, IOS and Android MikroTik;s WG implementation does properly sync both ways ... for example --- Allowed IPs will generate routes automatically on a peer to peer basis when the WG Interface has been assigned its IP Address ... however because those routes are auto generated there is more work to be done all depending on the end user objectives ... The additional work is Firewall related not routes.

A Windows machine may NOT be reachable in "any" subnet unless some prep work is done like having its Windows Firewall adjusted to have ICMP allowed for ipv4 and ipv6 plus network discovery enabled and shares properly defined for the user in question .. each platform has its quirks. ... If Windows Firewall is NOT adjusted for ICMP that machine will not be reachable .... after being reachable then one must confirm network discovery is enabled and shares properly defined otherwise the user objective may fail again. Also under Windows when traversing subnets the Windows Firewall needs attention ... it get complicated all depending on network type -- Domain, Private, Public ... not a big issue for the simple home but certainly an config issue for the SMB .... only meaningful when Routing from the Router in question.

I have not detailed all my findings here based on the tests I have conducted .. I do not have the time .... One very critical area is the IP Address and its subnet mask ... make a mistake there and those auto generated routes will not work. So actual testing will reveal what is possible ... very time consuming but the revelations make it worth while.

One very critical area is the IP Address and its subnet mask ... make a mistake there and those auto generated routes will not work. So actual testing will reveal what is possible ... very time consuming but the revelations make it worth while.

Concur, and is why it has its own section. Thanks for taking the time to look it over. The article was not meant to address general networking on a PC (windows firewall etc.) so its not really germane but will see if I can stick something in. I have not had time either to go over all the examples, or put the diagrams back in................. work in progress.

THanks Sob, will try to tidy up some of the bits you noted.
Also yes the diagrams and examples will get attention but not yet too busy.

In (3) you have (i) and (ii), and I had to read it several times, trying to find what's the difference, but there really isn't any. You're splitting incoming and outgoing traffic as two different things, but why? Whether there's communication initiated from local to remote subnet, or from remote to local subnet, it doesn't matter, because unless you're doing something special and unusual (e.g. some asymmetric routing), it will be bidirectional communication. And as far as routing is concerned, it doesn't matter which side started it. In both cases you need route to remote subnet, just one (if there's one remote subnet). But when I see it split in (i) and (ii), at first sight it seems there should be two routes.

THis para is more about explaining to new users where the allowed IPs come from. Your observations and comments are correct in terms of functionality or outcome, but was not the real intent.
I will attempt a rewording......... but yes, not all traffic is two way and thus a route could be made just for return traffic of remote users, or a route could be made just for destination addresses or local users.

The following rules demonstrate the possibilities that exist at both ends of the tunnel:
add action=accept chain=input in-interface=wg-interface-name dst-port=winboxport src-address=Admin_IP { to allow admin to config the local router from a remote site }

@anav
The above example is missing protocol .... if protocol= is not included you cannot have dst-port=winboxport
Suggestion: each time you include rules I suggest that you follow the syntax otherwise people will have issues .... routeros does a good job of error spotting so its easy for you to trial the code before posting.

Thanks for that .........will hopefully get to it later today. Edit: Done!

Hi, thanks for sharing.
I have an LHG antenna with a PPPOE connection to my ISP. I configured wireguard interface and peer and assign an IP to it. It's OK. But how can I send internet traffic through wireguard then pipe interface? Thanks. I use a WG client on windows, but i want to move it to routerOS for simplicity. Thanks.

Start a new thread at the beginner forum, with your question, this thread is for discussion on improving the user article..........