Kernaali ToolsAfter a mobile address change, check whether an authenticated packet from the new endpoint reaches the other peer. Then distinguish stale endpoint/NAT reachability from a tunnel that handshakes normally but has a routing problem. A scheduled peer reset hides that distinction and is not a universal fix.
Applies to: RouterOS 7.17 or later peer-role behavior and current WireGuard peer reference. Synthetic design: a mobile/NATed initiator connects to a stable reachable responder. Both-ends-behind-CGNAT, multi-WAN reply-policy designs and any claimed firmware-specific fixed bug need separate evidence.
Validation: documentation-checked on . No device or lab test is claimed. Version references identify the documentation checked, not a firmware upgrade recommendation.
Read configured and learned endpoints separately
/interface/wireguard/peers/print proplist=name,interface,endpoint-address,endpoint-port,current-endpoint-address,current-endpoint-port,persistent-keepalive,responder,last-handshake,rx,txRecord the values before and after one controlled network transition. In the peer reference, endpoint-address is the configured peer destination, while current-endpoint-address records the source of the most recent correctly authenticated packet. The latter is not a writable replacement for endpoint-address and does not prove LAN data traffic works.
Compare the learned UDP port as well as the address. A mobile provider or upstream NAT may change the mapping. Do not publish the real endpoint addresses or peer identity; retain a private before/after summary.
Choose the initiator and responder deliberately
In this design, the NATed mobile peer must be able to initiate toward the stable endpoint. Do not set responder=yes on both ends and expect either to start a lost exchange. The stable receiving endpoint can use the documented responder role so it does not keep initiating toward an unreachable old client endpoint.
The 7.17 release changelog includes the responder behavior change. That is a documented role change, not proof that a particular mobile-IP defect was fixed. If both public endpoints can change or neither side is reachable, establish an intentional rendezvous/reachability design rather than adding reset jobs.
Locate the failure after the transition
| Observation | Next check |
|---|---|
| No fresh outbound UDP from the mobile side | Initiator role, configured endpoint, its DNS resolution and underlay route |
| Mobile sends; stable side sees no authenticated update | UDP path, NAT mapping, source restrictions and the intended peer |
| Learned endpoint updates and handshake is recent; application fails | Allowed addresses, client routes, forward policy and return path |
| Connection fails only after idle time | Evaluate whether a keepalive is needed to retain the upstream NAT mapping |
| Failure follows a reboot but not an address-only change | Record that distinction; do not label every reconnect issue an IP-change bug |
Use keepalive only for the NAT condition it addresses
The WireGuard documentation describes persistent keepalive for peers behind NAT/firewalls that need to retain reachability while idle. If that condition is confirmed, the following changes one uniquely named existing peer on the NATed initiator. Inspect the name match first; the name is synthetic.
/interface/wireguard/peers/set [find where name="example-stable-peer"] persistent-keepalive=25sKeepalive generates periodic authenticated traffic; it cannot make an unreachable stable endpoint routable, repair a wrong allowed-address, or remove CGNAT. Do not assume a timer guarantees recovery from a software defect. Record the previous interval and role before any change.
Verify one roaming cycle and preserve evidence
During an agreed test window, move the test initiator between its intended access networks, verify a fresh learned endpoint/handshake and complete a remote application transaction. Include an idle interval relevant to the original failure. If the problem persists, collect the exact RouterOS build, roles and bounded packet observations privately for version-specific investigation.
Restore the exact prior peer interval or role if the change is unsuitable. Avoid rotating keys, removing/recreating the peer or clearing all router sessions merely to recover a test. Stop captures and temporary diagnostics. No firmware-fixed claim or automatic reset script is provided by this guide.
Handshake returns but LAN traffic fails · Check the cellular underlay
Technical references
Found an issue? Send a correction with a reproducible example.