Hello,

I have set up a Mikrotik peer in a Routerboard RB760iGS running the latest ROS (7.1) connecting to another peer (at home) which is also a RB760iGS running ROS (7.1).

The peer is defined in:

/interface wireguard peer

And the peer works once I have set it up. I am able to use my "road warrior" MikroTik and connect to home and web sites see me coming from my home address. Great!

But when I reboot my road warrior MikroTik, upon reboot, the peer does not "activate". There are no handshakes and no traffic flows.

I can start the peer by either of these methods: 1) Edit the entry and change something, such as the keep alive or 2) Click on enable

Strangely, the peer is not "disabled" either. It is in a status somewhere in between. Only when I disable it, is when the entry is greyed out in Winbox.

So as a result, I have no internet access unless I got into the road warrior MikroTik and perform one of the 2 steps above. And then everything works.

What am I missing here? How can the peer be started/enabled on its own after a reboot? Right now it seems want to be 'touched' by a script or human.

This used to be an issue in earlier versions of 7.1rc , I think it was solved in rc6.
Strange it pops up again...

I circumvented it with a script. Maybe it's because that script is still running I haven't noticed on the devices which I upgraded to 7.1...

This used to be an issue in earlier versions of 7.1rc , I think it was solved in rc6.
Strange it pops up again...

I circumvented it with a script. Maybe it's because that script is still running I haven't noticed on the devices which I upgraded to 7.1...

One cannot tease with such a script and then not provide it. Do we have to beg, pray or pay for it? ))
Perhaps one should test your current setup with the script disabled, to ensure we have a consistent issue!

I know.
Was planning to do just that tomorrow.

I know.
Was planning to do just that tomorrow.

Yes -- please do. Thanks!

Took the easier road and checked the log of the device which is now sitting 105km away from home
Just did a reboot to be sure ...

The issue is not there.
Netwatch properly logged status as being down at startup but after 10 seconds the interface came up without assistance.
And that was logged as well.

For archive purposes, this is a script you can use if you do have this problem (raw version which works for me. Could be fine tuned with proper search of ITF name etc etc)

For archive purposes, this is a script you can use if you do have this problem (raw version which works for me. Could be fine tuned with proper search of ITF name etc etc)

Code: Select all

:delay 25
/interface wireguard peer disable 0
:delay 5
/interface wireguard peer enable 0
:log info "WGPeer toggled"

I am not good with all this so can you tell me where/how you implemented this? (Does this run only on startup?) If so how do you do that?

Tool Netwatch
Host, ip address on other side of tunnel
Down script. Paste script from above
Time to check. Up to you. I would say 1 to 5 minutes. It should only run after a reboot.

You have a dns name (not just an ip address) in peer's endpoint-address, right. This is still an issue, I have an open issue with SUP-62097.
Looks like the peer does not come up when the first resolve fails. If this happens again, please check if peer's current-endpoint-address is empty.

You have a dns name (not just an ip address) in peer's endpoint-address, right. This is still an issue, I have an open issue with SUP-62097.
Looks like the peer does not come up when the first resolve fails. If this happens again, please check if peer's current-endpoint-address is empty.

Interesting inch worm that was an early question of mine somewhere in some thread somewhere that probably no one from MT read or ignored.
Firewall address list items at least for firewall rules seem to stay up to date. IS THERE TTL or some feature where it regularly checks?
I was wondering if so , if the router does something similar for WG associated rules where we use IP Cloud addresses..........

Is it a one time thing only??

And that's why I prefer to use plain ip when possible... it's simple.

Oh and BTW
That setup of mine also uses ddns name as endpoint.
So it is not a 100% cause.

You have a dns name (not just an ip address) in peer's endpoint-address, right. This is still an issue, I have an open issue with SUP-62097.
Looks like the peer does not come up when the first resolve fails. If this happens again, please check if peer's current-endpoint-address is empty.

Same here. Not reconnecting after a failure (keeping my remote devices without communication after the daily reboot)

Hello Community,
i have the same problem. After reboot or failed, the peer does not come automatically up.
All Firewall running of RouterOS 7.2rc1.

Regards

The same issue. Only manual disable/enable peer on server help to resolve.
No connection even i do it after 110s after Mikrotik start via script. Only manual disable/enable peer.... No DNS name on server configuration.
ROS 7.1rc3

Tool Netwatch
Host, ip address on other side of tunnel
Down script. Paste script from above
Time to check. Up to you. I would say 1 to 5 minutes. It should only run after a reboot.

Solution for now.

Alternatively check the script under this heading
(2) MYNETNAME - SPECIAL CONSIDERATION FOR ENDPOINT
found at this link - viewtopic.php?t=182340

Alternatively check the script under this heading
(2) MYNETNAME - SPECIAL CONSIDERATION FOR ENDPOINT
found at this link - posting.php?mode=edit&p=906311#preview

link is not ok

What is wrong with the link? Ahh weird, fixed and THANKS!!
Check it out, especially sol/n 2

Not sure what scripting you are referring to?
The scripts are to address when the client device is rebooted and the WG tunnel connection is attempted prior to the MYNETNAME resolving of the far end public IP.
I guess also for any interruption that may occur.

What is wrong with the link? Ahh weird, fixed and THANKS!!
Check it out, especially sol/n 2

Sweet but as indicated before, I can and will not take credit for it.
Someone else posted it first as manual solution but I do not recall who.
I just kept repeating my attempt of automating those manual steps.
But I did not invent that procedure.

It is very strange but holvoetn recomendations works only if both side (client and server) is mikrotik device.
If one of the peers for example is a phone with the wireguard program (the server is configured in Mikrotik) , then the connection will not occur unless the peer on the server is manually disable/enable at least once (script doesn't help).
It is worth restarting the peer once and then turning off the connection on the phone for a considerable time, and after this time, starting again the client on the phone, then the connection will be successful. I do not undestand why...

On your phone the issue will never occur.
The program will refuse to start wireguard when it can not resolve the endpoint name.
At that same time, there is no problem on the server since no request has been send

Try it on your phone

I did. Even on my windows laptop, no dice when there is no fully functional network connection.
So no problem on the other end either. Nothing was send.

On your phone the issue will never occur.
The program will refuse to start wireguard when it can not resolve the endpoint name.
At that same time, there is no problem on the server since no request has been send

Try it on your phone

The endpoint is configured on the phone only. On Mikrotik, this field is empty.
Is it incorrect?

No, it's normal with the Tik having peers with dynamic addresses. It can not know where to start.

The clients will start, Tik will follow.
If dynamic address of client changes, Tik will follow shortly after. That's the beauty of Wireguard.

No, it's normal with the Tik having peers with dynamic addresses. It can not know where to start.

The clients will start, Tik will follow.
If dynamic address of client changes, Tik will follow shortly after. That's the beauty of Wireguard.

Yes, client will start, but mikrotik will not start (no traffic). Then i disable/enable peer on mikrotik over the script - no result. Then i disable/enable peer on mikrotik via winbox - all is ok and traffic forwarded.

Nope.
If client starts connection, mikrotik will know where to go back to.
It does not initiate, it responds.
Big difference.

Are you saying you are effectively seeing this happen ?

Nope.
If client starts connection, mikrotik will know where to go back to.
It does not initiate, it responds.
Big difference.

Are you saying you are effectively seeing this happen ?

Yes, it is. I imagine it the same way. But for some reason, after turning on the Mikrotik after a reboot, the peer becomes working and forwarded traffic only if it is manually turned off first and then turned on.

When I turn wireguard on my iphone it initiates the conversation and connects every time, so not sure what you are trying to point out.

If you reboot your Tik, let it settle for some minutes.
Then toggle the peer.
And only then start the connection from your phone.
What happens ?

oh, that's very funny.
I found a solution to the problem. I had two peers configured on Mikrotik on the same wireguard interface (/24 net) with one port and two the same allowed address 0.0.0.0/0.
But one of the peer was disabled by me all the time.
What i did:
1) remove the disabled peer
2) reconfigured the wireguard network to /30
3) reboot mikrotik with script (disable/enable peer with delay on sartup)



Oh miracle, the connection was established from my phone.

The strange thing is that even with the disabled peer , the connection did not established and required the second peer MANUAL deactivation/activation .

OK, so config issue
You can not have 2 peers with the exact same allowed addresses.

I've seen that problem being reported before where it causes issues even when the "wrong" peer is in disabled state.

The problem was present even when one of the peer was disable. Only after removing it, the problem is no longer observed.

Any chanse to fix it? Issue exist even on the nevest firmware 7.1.3. Script with disabling/enabling peer works, but this is only work-around, not finall solutions.
Best regards

I just experienced the issue of Tunnel not being re-established on 7.2 after a power failure, and yes I have a DNS Name as Endpoint Address.

Glad to hear that, but there is no mention about this bug is fixed. I have to set it up in my configuration and figure it out.
Thanks!

Ok, finally I reproduced that bug. In fact, in normally condition wireguard link looks stable. But after serveral days I lost one localization. I can connect via web so I've access to logs. There was information about power outage (router rebooted without proper shutdown, probably power outage).
There was two wireguard interfaces, both link up, both has created interfaces but peer was created only for one of them (for interface no 2).
After normal reboot connection was restored. On second screen there is information that for FIRST wireguard interface peer was created.
(I have to hide full name of one of the wireguard interface)

Any ideas why after wrong reboot wireguard create peer for only one interface? (There is one peer per interface)
Best regards

16 seconds to bring up the peer for the 2nd interface is kinda a lot of time. Something is wrong there.

16 seconds to bring up the peer for the 2nd interface is kinda a lot of time. Something is wrong there.

Agree.

@madejson
when it fails and you toggle the peer status, does it activate then ?
if so, it still might point to DNS resolve issue.

Are both WG interfaces defined with FQDN names or one IP and the other FQDN name ?

16 seconds to bring up the peer for the 2nd interface is kinda a lot of time. Something is wrong there.

Are both WG interfaces defined with FQDN names or one IP and the other FQDN name ?

Are both WG i̶n̶t̶e̶r̶f̶a̶c̶e̶s̶ peers defined with FQDN names or one IP and the other FQDN name ?

oh rats ... must be the crickets making too much noise where I am now.
Good catch !

16 seconds to bring up the peer for the 2nd interface is kinda a lot of time. Something is wrong there.

Agree.

@madejson
when it fails and you toggle the peer status, does it activate then ?
if so, it still might point to DNS resolve issue.

Are both WG interfaces defined with FQDN names or one IP and the other FQDN name ?

What exactly do you mean "toggle"? Make a try to ping from that router to my localization? If yes, I didn't try that. I try ping from other side (from my router to that localization), and it doesn't work.
I'm sure, that rebooting WG interface on that remote router will help.

And that WG interface which not rebooted corectly after power outage is defined with FQND, and the other one which working ok is without any defined endpoint (second side has his FQND).

Wireguard / peer
Select peer
Toggle status ( disable and enable again)

That's what I mean.

16 seconds to bring up the peer for the 2nd interface is kinda a lot of time. Something is wrong there.

Thank you for informations. Is there any way to check it, whats possibly goes wrong?

Wireguard / peer
Select peer
Toggle status ( disable and enable again)

That's what I mean.

Ok thank you! No I didn't try that but I think it might be help. I used a script for work-around to fix that issue which restarting interface (not peer) and it was working well. Next time when I lose connection I will try your suggestion.

If that works, it is a possible indication of the dns resolving problem.
Which some declare a bug in ROS but can be circumvented quite easily using a small script.

It doesn't hurt to apply the script anyhow. Your logging should show if it has been used or not.
But at least the connection should come up.

And the peer needs restarting. Not the interface.

If that works, it is a possible indication of the dns resolving problem.
Which some declare a bug in ROS but can be circumvented quite easily using a small script.

It doesn't hurt to apply the script anyhow. Your logging should show if it has been used or not.
But at least the connection should come up.

Yes you are right. When I'm using that script it's working well, and in logging I saw that's was triggered from time to time. But I think this script is work-around, somebody before said that problem is no longer exists. As we see problem still present, but I think earlier that was much more offen. Even after correct reboot WG link doesn't up. Now it looks ok, but not when power outage.
And most important thing about versions ROS: mine is 7.4b4, remote is 7.3.1, both hap AC3.

OK, again it happend. But now I just disable/enable peer and connection restored.
So: I've two wireguard interfaces, both has only one peer for each interface. After power outage one is created and working well, second (using FQDN as endpoint) NOT.
Any chance to fix it?

best regards

yes, provide a redacted config export.

On the second one, with fqdn, use workaround script inside netwatch.
As long as the " other side" is not reachable, the script should toggle peer status.
Once it becomes reachable, the netwatch check will do nothing.

Simple.

post deleted

The final solution is, to my knowledge, not there in ROS.
In Windows e.g. you can not even start that interface if there is no dns resolution.
Plain error as it should be.
Therefor my view is this fix should be in the OS. ROS in this case.

So either you use the workaround or you can do so manually each and every time.
The beauty of the workaround is that it even works when they have fixed it without our knowledge.

Your choice.

There's no problem.
That's just how Wireguard works.
It's not something up to MikroTik to fix, best they could do is to implement the script behind the scenes, but I see no intention to do that, and even the official Wireguard implementations don't have something like this out of the box, there's a script that exists, but it's optional.
If you want your peer to connect to your other peer via DNS you have to be sure that you have internet and an operational resolver at the time wireguard starts. And of course you have to be sure that the other peer didn't change IPs in the meantime, because wg will keep trying whatever IP it gets at the first resolve.
All this can be scripted, and there are plenty examples around the forum.
Considering that for you this is only an issue after a power outage, I'm guessing that the ISP equipment needs some time to start too.
That's the diff between a power outage and a normal reboot.

If I tell router to connect to some hostname, I understand that it may fail, that's "ok". But it's not ok that it tries once and gives up. That should be handled internally, because it's too common problem, to have everyone rely on scripted workarounds.

Exactly !

Since the Wireguard protocol doesn't have something like this and still requires external scripting, I'm trusting more a script that I write instead of something pushed via a vague changelog.

Since the Wireguard protocol doesn't have something like this and still requires external scripting, I'm trusting more a script that I write instead of something pushed via a vague changelog.

Totally with you on that last comment

As a protocol I agree this is nothing to be solved by Wireguard. The prerequisites to make it work have to be there.
The application or OS using that protocol should prevent getting into a situation where it becomes unusable. It should not allow to claim to have been started, which it does now, even when quite easily being capable to detect the prerequisites are NOT fulfilled.
That's plain wrong.

I don' know what to say right now
I feel this same what Sob said, but from the other hand I understand what Znevna and holvoetn suggest.
Now, i'm going back to run script. Thanks to informations from Znevna and holvoetn I will do some small changes in it.
Thank you.

It's just basic expected level of user friendliness. If I use hostname with any other VPN type in RouterOS (IPSec, SSTP, ...) and it can't be resolved, it keeps trying. It would be really weird and unexpected if it didn't, right? Is there any good reason why Wireguard should be different?

Yes, it's slightly different, because there's not exactly distinct client-server connection as in other protocols, communication can be initiated from both sides, there's built-in roaming, etc. But it only changes how it should be evaluated. It shouldn't aggressively re-resolve peer's hostname all the time and change address, but if there's hostname as peer's endpoint and the peer it clearly inactive, then it should do it. It may be optional, but it should be built-it.

It's just basic expected level of user friendliness. If I use hostname with any other VPN type in RouterOS (IPSec, SSTP, ...) and it can't be resolved, it keeps trying. It would be really weird and unexpected if it didn't, right? Is there any good reason why Wireguard should be different?

Yes, it's slightly different, because there's not exactly distinct client-server connection as in other protocols, communication can be initiated from both sides, there's built-in roaming, etc. But it only changes how it should be evaluated. It shouldn't aggressively re-resolve peer's hostname all the time and change address, but if there's hostname as peer's endpoint and the peer it clearly inactive, then it should do it. It may be optional, but it should be built-it.

Sob is correct the other wannabee misses the mark entirely in terms of providing customer service based on expected use. There are many linux WG 'helper apps' and 'addons' in the wild because such practical approaches ( be it domain name solving or something else) are common, and the WG protocol in of itself itself is not intended/designed to do "ALL" things.
- https://wiki.archlinux.org/title/WireGu ... hanging_IP
- https://github.com/cedrickchee/awesome-wireguard

Sob is bang on, especially considering that MT provides a home grown cloud dyndns functionality and I would hazard a quess that many folks use that with wireguard. To be clear we are talking about the MT router as a client device (in terms of initial connection).
Seeing that the wireguard client is only setup to resolve once (due to udp protocol?), the only logical conclusion for MT coders is to ensure that resolving the endpoint is added additional functionality to the basic wireguard process. It could be as simple as taking the admin's checkmark entry in peristant keep alive as also direction to ensure the dyndns resolving process is not stalled by changed IPs, power bumps etc at the other other (the endpoint). - the resolving took place after the WG client attempted tunnel establishment /or/ a longer term resolving issue. When one adds a dyndns url to a firewall address list, MT clearly goes out and resolves the address and then displays this as a second line. The same existing processes could be utilized for improved WG stability/robustness. It may be as simple as adding the endpoint addresses as firewall address entries (automatically) etc........ The router initiates the WG process and if there is a dyndns url entered for endpoint, creates the entry in firewall addresses, ensures an address is returned and then goes back to the WG module to complete the connection process or something to that effect. Assuming the router is aware when keep alive is working (sends and receives confirmation network is up), two failed keep alive checks could trigger a re-resolve of the associated firewall address entry or whatever floats your boat in terms of seconds/min/hours/days etc with requisite log/email alerts.....

This wannabee was actually making the same point unless I was hugely misunderstood...

This wannabee was actually making the same point unless I was hugely misunderstood...

My bad, I didnt read your second sentence where you clearly point out that the OS handling of this issue is piss poor. Corrected.....