I am trying to setup a site to site network between 2 Mikrotiks, using wireguard.
How to I make one site initiate the wireguard connection immediately upon startup? (And retry on disconnect)
Do I need to script this? It feels like a predefined setting that I just can’t find
Wireguard always starts when the router starts up (provided it was enabled upon power-down).
In previous versions there was a bug when wg-service was starting up and there was no DNS resolution available yet, the interface would simply stop cold and not retry.
Scripts where needed then to toggle the peer or interface to make it working.
As of (I think) 7.10 this should be fixed. 7.11 for sure (but that version is still in beta).
EDIT: just checked changelog, it was 7.10
Ok I’m running 7.10
Perhaps I’m misunderstanding, but it sounds like the WireGuard service starts automatically, but how do I make only one peer connect to the other? (So both peers don’t try to connect to the other at the same time)
I think you are saying I need to create a script which makes one site activate the WG peer ? After that, if the peer disconnects then the mikrotik will automatically retry the connection? Or do I need to monitor the connection and the reactivate?
And lastly, is there an example script that does this? If not I’ll have to do more reading.
The interface itself does not connect.
Peer does.
It doesn’t matter which peer initiates the connection.
But usually there is one acting as “server” (the one with public reachable IP, fixed or dynamic). The other then connects to that one.
If both are publicly reachable, one will be first.
If you set keep-alive on both peers, they will both make sure the connection stays alive (but it will consume some bandwidth/volume, something to keep in mind when on a restricted connection).
For more reading material (and example of script):
see this thread made by anav, section 6
https://forum.mikrotik.com/viewtopic.php?t=182340
Holve are you stating that as soon as both routers are functional, aka turned on, the client device attempts to establish the tunnel with the server device and once accomplished, the peers at both ends can access each other. My understanding is that there is no tunnel attempt until a user on the client device initiates traffic flow? Maybe I am getting confused LOL.
Tunnel will be made.
Just no traffic flowing until you do something.
Mr Expert… 
Ok I’ve followed the guide and my site to site seems to be working!
The last step is to monitor the connection, and I like the NetWatch solution (#2) so I have copied that script into place on site B in the on Down handler:
# WG peer 0 is tunnel to site A
:delay 25
/interface wireguard peer disable 0
:delay 5
/interface wireguard peer enable 0
:log info "WireGuard tunnel to site A toggled"
But this leaves me with a couple of questions.
1 correct
2 no idea. If netwatch already determined the link is down, I’m not sure where the added value is of waiting another 25 seconds.
Well I try to keep an open mind and mouth for belgium chocolate treats!
Did you test this, or is it written somewhere??
Test conditions: client and server device turned on. No traffic is attempted by users on the client device.
User from server device lan connects to device on client device lan ( opposite direction of handshake ).
25 Seconds is the same as the advised keep-alive for WireGuard.
Virtual tunnel is made by wireguard protocol via udp using key exchanges.
No tunnel, no L3 ip communication.
Section conceptual overview
https://www.wireguard.com/#conceptual-overview
Trying to find the reference that backups your claim.
and… doenst exist, a figment of your imagination…
Must be the crappy beer you are drinking.
When there is no tunnel, there can not be secured communication, can we agree on that already ?
The wireguard protocol sends handshakes from time to time to exchange updated secret keys, just in case some traffic needs to be send.
Which means the tunnel is virtually there. No traffic needed.
No permanent connection, that is true, but virtually the tunnel is prepared to accept communication because they already established the secret keys to be used between peers.
Do a test yourself:
Check your wireguard tunnel with active peers in firewall/connections. You should see outbound connections to your external peer with the specified port (depending on which one acts as pivot point, could be the reverse with src address showing the required port).
You can delete the connection in firewall, it may not reappear immediately but it will come back.
And still no TCP data exchanged.
Disable that peer and that connection will disappear (give it some time), only coming back when you enable the peer again (but I guess we’re not in disagreement there).
More reading (Connection-less Protocol section, first paragraph already sums it up)
https://www.wireguard.com/protocol/
I understand but if it already has been determined the tunnel is down, why wait ?
The tunnel is one and the connection is two.
Any secure protocol requires some state to be kept, so there is an initial very simple handshake that establishes symmetric keys to be used for data transfer. This handshake occurs every few minutes, in order to provide rotating keys for perfect forward secrecy. It is done based on time, and not based on the contents of prior packets, because it is designed to deal gracefully with packet loss. There is a clever pulse mechanism to ensure that the latest keys and handshakes are up to date, renegotiating when needed, by automatically detecting when handshakes are out of date. It uses a separate packet queue per host, so that it can minimize packet loss during handshakes while providing steady performance for all clients.
In other words, you bring the device up, and everything else is handled for you automatically. You don’t need to worry about asking it to reconnect or disconnect or reinitialize, or anything of that nature.
What I am saying is that the article is poorly written. 
(1) The para states there is an initial handshake, but it does not make clear what precipitates this handshake!!
(2) The article intimates that its talking about keep alive timing and not based on prior packets but seems to indicate there were prior packets to this timing thingy!
(3) It specifcally does not clarify what bring the device up means… does is mean turn on the device or does it mean bring the tunnel up tunnel by initiating traffic?
As I stated before the way to prove this is by having two routers A(server) B(client)
a. turn on both routers.
b. user on subnet A attempt to reach user on subnet B.
Since its B that has to handshake with A, the only way that step b., could occur is if the tunnel comes up automatically as you state.
If the requirement is to manually start the tunnel then it could never happen.
At least testing on my iphone to my router… proves to me that the tunnel is up, without traffic flowing, and the keep alives do start kicking in.
The stupid status on my router doesnt update the link status for some reason… maybe that links status only comes up when traffic passes through itl
I have revised the article
from:
iv. The initial connection starts on the client side when the router detects a user has requested a destination such that IP routing hits the wireguard interface. The Router then looks at the wireguard peer addresses that matches and then knows which SERVER is involved. The MT client router will establish a connection from itself (using default local WANIP) to the Server Router.
v. After initial connection is established the relationship is no longer Server/Client, the tunnel is now open to two way traffic and traffic can occur from either side (peer to peer network).
TO:
iv. If both devices at the ends of the tunnel are turned on (up) the client device will initiate a handshake and a Tunnel will be established. Traffic does not need to occur for the tunnel to be created. Additionally, the “keep alives” will start kicking in at the prescribed timing. After this initial connection is established the relationship is no longer Server/Client, the tunnel is now open to two way traffic and traffic can occur from either side (peer to peer network).
v. Wireguard traffic from either end of the tunnel can take place and follows wireguard routing behaviour utilizing, wireguard peer addresses, available Routes and adhering to firewall rules where applicable.
So, we’re in agreement then ?
Yes, I am eating belgium chocolate… and I was kidding belgium beer is great!
If wisdom is measured by the number of grey pubes, you must be very wise LOL.