Renewing a Dynamic IP Address on MikroTik with RouterOS
Properly release the WAN DHCP lease, wait for reconnection, verify the received address, and automate the operation without confusing renewal with anonymity.
A so-called "dynamic" IPv4 address can remain the same for weeks. This is not necessarily a failure: the operator's DHCP server often recognises the same client and reassigns the previous lease to it as long as it remains available. However, RouterOS allows you to release the WAN lease and restart the DHCP client without rebooting the entire router.
The operation is quick, but it causes a brief Internet outage and never guarantees a different address. The final choice belongs to the operator's server. This guide therefore shows how to execute the procedure cleanly, check the result, automate it carefully, and avoid attributing security benefits to it that it does not provide.
What release and renew actually do
In the RouterOS IPv4 DHCP client, the two commands do not have the same purpose:
| Command | Action | Expected result |
|---|---|---|
renew | Requests the renewal of current leases. If it fails, the client attempts a reset. | The same lease is normally kept. |
release | Releases the current lease then restarts the DHCP client. | The router requests a lease again, identical or different depending on the operator. |
To request a new assignment, release is therefore sufficient: RouterOS restarts the client itself. Running renew first, then release, adds an unnecessary request and does not make the address change more likely.
Verify that the WAN actually uses DHCP
The procedure only applies to an IPv4 DHCP client. It is not suitable for a PPPoE connection, a static address configured in /ip address, an LTE modem that manages the session itself, or a router placed behind another box.
/ip dhcp-client print detailIdentify the entry whose interface corresponds to the WAN. In the following examples, it is called ether1. Always adapt this name to your configuration: it could be wan, vlan-internet, or another Ethernet interface.
Before continuing, the entry must be active and display status=bound. Also note the values address, gateway, and expires-after.
/ip dhcp-client print detail where interface=ether1Perform a manual test
Enable Safe Mode with Ctrl+X in the terminal, then launch the release on the identified client. Filtering by interface avoids depending on the order number displayed in the list.
/ip dhcp-client release [find where interface=ether1 and disabled=no]The status briefly passes through searching or requesting, then must return to bound. Depending on the modem and the operator, the outage may last a few seconds or more.
/ip dhcp-client print detail where interface=ether1
/ip route print where dst-address="0.0.0.0/0"Compare the new value address with the one noted before the operation. If it is identical, the command probably worked: the DHCP server simply chose to return the same lease.
release command restarts the DHCP client. A new address remains a possibility, never a guarantee.Create a controlled RouterOS script
Reliable automation must do more than send a command. It checks the existence of the client, refuses to work if the lease is not active, memorises the old address, waits for the return to the bound state with a maximum delay, and logs the result.
In System → Scripts, create a script named refresh-wan-dhcp with the policies read, write, and test, then paste the following content:
:local wanInterface "ether1"
:local wanClient [/ip dhcp-client find where interface=$wanInterface and disabled=no]
:if ([:len $wanClient] = 0) do={
:error ("No active DHCP client on " . $wanInterface)
}
:local oldStatus [/ip dhcp-client get $wanClient status]
:if ($oldStatus != "bound") do={
:error ("Client DHCP non lie, statut: " . $oldStatus)
}
:local oldAddress [/ip dhcp-client get $wanClient address]
:log info ("DHCP WAN: releasing " . $oldAddress)
/ip dhcp-client release $wanClient
:local secondsLeft 60
:while (([/ip dhcp-client get $wanClient status] != "bound") && ($secondsLeft > 0)) do={
:delay 1s
:set secondsLeft ($secondsLeft - 1)
}
:if ($secondsLeft = 0) do={
:log warning "DHCP WAN: no lease after 60 seconds"
:error "Expiration de l'attente DHCP"
}
:local newAddress [/ip dhcp-client get $wanClient address]
:if ($newAddress = $oldAddress) do={
:log info ("DHCP WAN: lease renewed, address unchanged " . $newAddress)
} else={
:log info ("DHCP WAN: new address " . $newAddress)
}The log text is intentionally written without accents to avoid surprises when copy-pasting between terminals. Replace ether1 only once at the beginning of the script.
Test before scheduling
First run the script manually and observe the log. Do not create any schedule until the reconnection has been validated from the LAN.
/system script run refresh-wan-dhcp
/log print where message~"DHCP WAN"
/ip dhcp-client print detail where interface=ether1Then check DNS resolution, Internet access, VPN tunnels, and published services. A new IP makes existing TCP connections unusable; they will need to be recreated.
Schedule execution with Scheduler
If a periodic renewal meets a real need, choose a maintenance window. The following example runs the script every day at 04:30. It is provided to show the syntax, not as a universal frequency.
/system scheduler add \
name=refresh-wan-dhcp-daily \
start-time=04:30:00 interval=1d \
on-event="/system script run refresh-wan-dhcp" \
policy=read,write,test \
comment="DHCP WAN lease maintenance"The scheduler has the same policies as the script and calls it explicitly. After the first run, check its last-started and run-count fields, as well as the log messages.
/system scheduler print detail where name=refresh-wan-dhcp-daily
/system script print detail where name=refresh-wan-dhcpDaily execution is often excessive. It multiplies interruptions, can trigger anti-fraud protections, invalidate allow lists, and complicate log analysis. Manual action or weekly maintenance is generally sufficient.
Update dynamic DNS
If services remain accessible from the outside, their DNS name must follow the public address. The RouterOS IP/Cloud service periodically checks for changes and updates its DDNS record. To enable it voluntarily:
/ip cloud set ddns-enabled=yes
/ip cloud force-update
/ip cloud printThe dns-name field indicates the assigned name and status=updated confirms the update. The service TTL is short, but already open connections do not migrate to the new address.
Do not enable IP/Cloud if you do not wish to use this service. An external DDNS provider can be updated by its own client. Never place an API secret directly in an article, a public export, or a log.
Why a different IP is not a privacy shield
Changing the address can interrupt a temporary block based solely on the IP or reduce the continuity of a very basic observation. It does not make browsing anonymous and does not secure a network on its own.
- connected accounts, cookies, and application identifiers remain the same;
- the browser and the device retain many fingerprinting elements;
- the IPv6 address can remain stable while the IPv4 changes;
- the provider retains its own visibility on the connection;
- an exposed service remains vulnerable if it lacks patches or a proper firewall.
To actually strengthen security, update RouterOS, restrict administration to the LAN or a VPN, disable unnecessary services, and check the input rules. For privacy, choose tools adapted to the threat model instead of relying on DHCP lease rotation.
Why the address does not change
- The server keeps the old lease: this is the most common behavior and there is nothing to fix on the router.
- The router is behind a modem: the public lease belongs to the modem, while the MikroTik only receives a private address.
- The access uses PPPoE: no relevant entry exists in
/ip dhcp-client. - The client is permanently identified: the operator can reassign the same lease according to its policies and the state of its pool.
- The line uses CGNAT: the public address is shared and managed upstream.
- The default route does not return: check
add-default-route, the link state, the operator VLAN, and the DHCP logs.
Changing the MAC address or the Client ID solely to obtain another lease is not a neutral solution: it can violate access conditions, trigger a limitation, or prevent authentication. Instead, ask for a dynamic, static, or public IP option suited to the provider.
Disable automation
To suspend the task without deleting it, only disable the Scheduler entry. The DHCP client will continue to renew its lease normally according to the protocol timeouts.
/system scheduler disable [find where name=refresh-wan-dhcp-daily]After an observation period, delete the task and then the script if you no longer use them.
/system scheduler remove [find where name=refresh-wan-dhcp-daily]
/system script remove [find where name=refresh-wan-dhcp]Conclusion
On a WAN actually configured in DHCP, the correct method consists of identifying the client, memorising the address, launching release, waiting for the return to bound, and comparing the received lease. The presented script adds the necessary checks and maximum delay for this operation to be observable and predictable.
The essential point remains external to the MikroTik: the DHCP server decides the address. Automation can request a new lease, not impose a new public identity. It must therefore serve a specific operational need, be scheduled during an acceptable window, and remain accompanied by reliable DDNS when services depend on the address.
Technical references
Read next
About the author
Jeremy Kraft runs the infrastructure and the self-hosted services of the IBCSC. These guides describe configurations that were actually deployed and re-checked before publication.
Discussion
Comments
No comment yet. Feel free to open the discussion with a question or your own experience.