I have a Keenetic Extra DSL router. I configured a static DHCP reservation so that my ESP32-W5500 device (MAC: de:ad:be:ef:fe:01) always receives 192.168.1.114. There's a MAC-based port forwarding rule for port 80, and a defined [subdomain].keenetic.pro points to this device as well.
After a soft-restart, port forwarding silently breaks for WAN traffic. The rule appears active in the panel, but incoming connections from the outside just time out.
This has recurred consistently across multiple soft-reload events over several months, with a different "ghost" IP each time (.100, .101, .102).
From the local network, however, I can always reach the client on its assigned static IP (.114) without any interruption. And here's the kicker: if I simply disable and re-enable the port forwarding rule from the router's interface, the problem vanishes instantly and external WAN access comes right back.
The weird part: during an outage, when I look at the router's own diagnostic tools, the ARP table and the NAT table completely contradict each other.
From the router's system logs:
DHCP is working correctly
16:34:35 — Client requests .101
16:34:35 — Router sends NAK, rejects it
16:34:35 — Client sends DISCOVER; router offers the reserved .114
16:34:35 — Client receives ACK for .114
Nginx proxy connects to the wrong IP 4 seconds after DHCP
16:34:39 — activated proxy [subdomain].keenetic.pro to 192.168.1.101:80
Nginx "corrects" itself within 2 seconds
16:34:41 — activated proxy [subdomain].keenetic.pro to 192.168.1.114:80
But nginx correcting itself does not stop incoming traffic from being forwarded to the .101 ghost IP, as the CLI logs below show.
19:00:59 — CLI capture:
show ip neighbour:
id: 6
via: de:ad:be:ef:fe:01
address: 192.168.1.101
expired: yes ← INVALID
id: 7
via: de:ad:be:ef:fe:01
address: 192.168.1.114
expired: no ← VALID
show running-config | grep "ip static":
ip static tcp PPPoE0 80 de:ad:be:ef:fe:01
show ip nat – incoming WAN port 80 traffic:
TCP 172.71.102.232 13498 [WANIP] 80 4
192.168.1.101 80 172.71.102.232 13498 4
TCP 172.71.102.232 10776 [WANIP] 80 4
192.168.1.101 80 172.71.102.232 10776 4
At 19:00:59, incoming traffic is still being forwarded to the .101 ghost IP.
Manufacturer's Official Diagnosis and Proposed Solution:
Diagnosis: The problem originates from the client device (ESP32).
Their reasoning:
"The device is using two different IP addresses, responding to an old IP (.102)."
"The client appears to respond to the address 192.168.1.102 that it previously used."
"The IP/MAC behavior of the client is inconsistent."
Proposed Solution:
To resolve the issue, disable MAC based dynamic port forwarding and apply the following three commands in order:
ip dhcp host de:ad:be:ef:fe:01 192.168.1.114 (static DHCP reservation)
ip arp 192.168.1.114 de:ad:be:ef:fe:01 (static ARP entry)
ip static tcp PPPoE0 80 192.168.1.114 (bind port forwarding to IP instead of MAC)
The manufacturer does not acknowledge a software bug, but offers this as a solution to eliminate the existing "inconsistency". They do not provide an explanation of why MAC based forwarding does not work in this scenario.
I rejected their solution and requested an explanation, under RFC 2131, of why MAC based forwarding fails. An explanation was never provided.
My Questions
Do any of the points above realistically explain what the logs show?
Is this a client side issue, or does it point to a problem with the router?
Full raw CLI outputs and syslog are available upon request