Wrong "DHCP server" appears in Windows with Mikrotik hEX S

RouterOS General
1

Hi,

Recently I purchased a hEX S 2025 and I am configuring this with WinBox. Everything works so far, just one really annoying thing.

Originally this router has internal IP of 192.168.88.1, and then I changed the internal network to 192.168.1.0/24, then I set IP address 192.168.1.1/24 on bridge, then changed the DHCP pool to 192.168.1.11 to 192.168.1.254.

Now my computer running Windows 11 can receive IP address and access Internet. Just one thing really annoying: when I open “Network connection status” page or run ipconfig /all, it shows:

DHCP Server . . . . . . . . . . . : 192.168.88.1

Although my computer can get IP address, but it should not be that. When I try to ping 192.168.88.1, no, it won’t work, and my routing table has no “on-link” entry to that address; in that case I think all connections to 192.168.88.1 will be forwarded to 192.168.1.1 which is the router as default gateway.

I also use Wireshark to capture DHCP packet, and the reply is indeed coming from 192.168.88.1.

Although it does not break anything, just wondering if there’s any way I could correct this in my router’s config?

2

You can /export file=xyz the configuration to a file, download it (xyz.rsc) and open it with a text editor. Then search for any remnant of 192.168.88 left in the configuration. Also search for =* in the exported text. If you find a match, that might mean that the configuration has broken references to deleted items.

If you can find none of that, maybe try to restart the DHCP server by going to IP -> DHCP Server -> DHCP, then disable the entry and re-enable it after a few seconds. Then run ipconfig /renew on your Windows device.

3

In command line cmd as administrator.

4

No, from my experience ipconfig /renew does not require administrator right or UAC under modern Windows. I've just tested again with multiple devices running Windows 10 22H2, Windows 11 24H2 / 25H2 / 26H1 (Insider Preview). My daily account is never member of the Administrators group, only of the Users group.

  • On all devices, running ipconfig /renew or ipconfig /renew6 with normal (member of Users group only) account without UAC prompt is not a problem.

  • On all my devices with multiple accounts, the ipconfig /release and ipconfig /release6 commands also work with normal user account and do release the DHCP / DHCPv6 lease. The same user executing the /renew / /renew6 command will restore the IP lease.

  • Only on one test VM that solely has a single user account (which naturally is part of the Administrators group), does the ipconfig /release or ipconfig /release6 command refuse to work, citing the missing elevated right. The commands ipconfig /renew or ipconfig /renew6 work normally without UAC.

  • However, on that same VM, once I've added another account from the Users group, ipconfig /release or ipconfig /release6 work on all accounts, including the previous admin account that required UAC.

The machines are not part of any domain. Maybe the restriction is different if the device joined a domain.

Actually, the /renew action requiring no elevation is understandable to me. Because renewal would sooner or later happen anyway, and the user has no influence on the obtained IP address, only the DHCP server.

What I find less understandable is /release working with normal user rights :smiley:.

5

Scratch my previous post.
Check IP -> Addresses, you probably have the old IP still there.

6

wHAT @Znevna says. I feel fairly sure you still have the old address.

Remember that DHCP is a Layer 2 protocol and is active before the client machine has an IP address, so the server will take any active address on its operating interface - for you, the local bridge - according to some internal logic of its own.

I think that when you changed the IP of the router, you may have just created a new address and not deleted the original IP address, which is actually not a bad thing to do, because it leaves you able to get back in if you mess up. You would of course need to set up a static IP address in the range 192.168.88.0/24 to use this. The fact that you can't ping the router on 191.168.88.1 is down to the DHCP giving you an address on a different subnet and there being no route available.

7

I searched the file but no findings.

But after I tried to upgrade the firmware and enable/disable the DHCP server, now it shows 192.168.1.1 as DHCP server in Windows.

Thanks a lot!

8

I am pretty sure it is not there; but the issue has been solved after firmware update, then disable/enable the DHCP server. Now Windows has shown that correctly.

9

Ohhh I see, this is not my daily driver. Thanks that you confirm that. Was long time ago Internet Support Tech, and said always to the customers that you have to run cmd as administrator. But lately I don't know the new features of the new Windows versions.

I am daily driving Arch Linux now, and Windows is always welcome in my computer as VM :grinning_face:

10

Did you reboot the router after you added the new IP address? Perhaps that might have been sufficient? ....

11

Edit: given info in first post of thread, I don't think this was the cause of what @coltlv1994 was seeing.

Followup post has my reasons.

But it is a thing to be aware of in general when using a new address with a dhcp server.

My guess is that the PC's lease expired in the mean time. So that is the reason for the "self healing".

If you still have the saved output from the ipconfig/all, it would have the time that the lease expires

   Lease Obtained. . . . . . . . . . : Thursday, April 02, 2026 11:22:32 AM
   Lease Expires . . . . . . . . . . : Sunday, April 05, 2026 2:44:31 AM

Note that the Lease Obtained is the time the address was first offered as the result of a DHCP discover, not the time of the last least extension. In this case the lease time was one day, but it has been extended multiple times, so you can't in general determine the lease duration from ipconfig/all (at least that I am aware of, if someone knows, please post).

If there is a switch between the PC and the router/dhcp server, it will keep the physical ethernet link up when a router is rebooted or replaced.

A lease is a "contract" that the address leased will be valid and not offered to another client until the lease has expired.

So until the client either loses link, or 1/2 of the lease period has, a client will not normally ever initiate a connection to the DHCP server. And even then it won't request a different ip than it already has a lease for, unless it gets a DHCP nak, in which case it will initiate a new discover.

So when changing dhcp addresses, power cycle any switches between the clients and the dhcp server.
Then any dhcp clients directly connected to the switch will lose link, and initiate a DHCP request asking the DCHP server for the same address is previously had (e.g. 192.168.88.250). If that DHCP server is no longer around, and there is an authoritative DHCP server on the ethernet segment with a different address, then that dhcp server will send a DHCPNAK with "wrong network", and the client will then send a DHCP Discover, and get a new offer from the new DHCP server, it will then request the offer, and the server will acknowledge that the client now has the new address (e.g. 192.168.1.254) leased for the specified period.

Or from the client either unplug the ethernet cable, wait a few seconds and reinsert it, or issue ipconfig/release and then ipconfig/renew.

12

@coltlv1994 After re-reading your OP, I don't see how my previous hypothesis (that PC has existing lease from before the IP was changed) could have been the cause.

Did the PC get a new ip address from the new DHCP pool (192.168.1.11 to 192.168.1.254) and the correct gateway? I don't understand how it would have been able to access the interenet otherwise.

Are you saying that wireshark showed option 54 DHCP server identifier was 192.168.88.1 even though the actual server was 192.168.1.1?

13

One possible explanation is that, although OP has edited the pools and the /ip dhcp-server network entries, the /ip dhcp-server instance itself has not been touched. The DHCP server is aware of the new pool ranges and gateways, subnets, DNS server changes and properly gives them out to the clients. However it only reads the IP address of itself at start (by reading the address assigned to the attached interface). When you later edit the /ip address entry to change from 192.168.88.1/24 the DHCP server instance is not aware of this modification and keeps the 192.168.88.1 address, and use it in the DHCP respomse packets.

That's why I suggested that a possible solution might be to restart the instance (by disabling then re-enabling), because the server will read the up-to-date address associated with the interface at start.

A router restart (induced by the firmware upgrade) will also have the same effect.

14

This is actually point #23 of the GP&CSA:
GP & CSA for Mikrotik devices

I don't understand why many people do not try rebooting the router, the final scope of a configuration is that it should work when booted afresh, and it costs nothing, a handful of seconds, or you could run a system shutdown, go and get a coffee, and power up the router when you come back.

15

@Buckeye Sorry I did not have the original info output or wireshark capture; will remember to save them next time.

Regarding your questions. Yep, my PC gets a new IP address from new DHCP pool correctly, and it has correct default gateway of 192.168.1.1.

Over the wireshark issue, I cannot remember very correctly, but it is either option 54 or source address of DHCP reply that shows 192.168.88.1. I definitely see the hex, C0 A8 58 01, that represents 192.168.88.1 in the DHCP reply.