A User Experience & Keenetic Kernel-Level Bug: Post Soft-Reload, Conntrack/NAT Chain Locks Port Forwarding Target to a Stale/Ghost IP (Proven with ARP + NAT Table)

[asdem]

I have been a long-time Keenetic user. Although I am generally satisfied with the hardware and interface, a chronic kernel-level bug and the subsequent inadequate support process have led me to decide to leave the Keenetic ecosystem entirely. I present this experience as a concrete, reproducible diagnostic record for users struggling with a similar issue and for the development team.

I am not a network engineer; I am an ordinary user with limited resources. However, the data in my possession is clear enough to require no expertise: **the router ignores a valid IP in its own ARP table and routes traffic to an expired, "ghost" IP that has never existed on my network.** This is not an interpretation; it is a fact visible in the raw CLI outputs below.

---

## Evidence: ARP Is Correct, NAT Is Wrong

After a modem soft-reload (certificate renewal, scheduled task, etc.), the port forwarding rule appears "active" in the management panel, but traffic from the outside world does not reach the local network. The WAN connection silently times out — not "connection refused", the packet falls into a black hole at the kernel level.

This is a synchronization/cache bug in KeeneticOS's netfilter/nf_conntrack subsystem (explicitly visible as `nf_conntrack version 0.5.0` in the kernel boot logs). Two different CLI outputs captured simultaneously during an outage prove this:

**`show ip neighbour`** output shows two separate entries for the same MAC address (`de:ad:be:ef:fe:01`, my ESP32-W5500 device):

```
id: 10
via: de:ad:be:ef:fe:01
mac: de:ad:be:ef:fe:01
address: 192.168.1.114   ← valid IP, my registered static DHCP reservation
last-seen: 12             (seconds ago)
expired: no                ← VALID and ACTIVE

id: 5
via: de:ad:be:ef:fe:01
mac: de:ad:be:ef:fe:01
address: 192.168.1.102   ← an address that has never existed on my network
last-seen: 191
expired: yes                ← expired
```

**`show ip nat`** output captured at the same time shows that incoming WAN TCP/80 traffic is being forwarded not to the correct IP marked `expired: no`, but to the invalid IP marked `expired: yes`:

```
TCP  172.71.102.233   12410    [WAN_IP]        80       4
         192.168.1.102    80      172.71.102.233   12410    4

TCP  172.71.144.9     10915    [WAN_IP]        80       4
         192.168.1.102    80      172.71.144.9     10915    4
```

The port forwarding rule is defined as MAC-based (`ip static tcp PPPoE0 80 de:ad:be:ef:fe:01`). While the ARP table shows the correct IP (`.114`), the NAT/connection tracking mechanism still uses the old/invalid IP (`.102`).

> **Additional fact:** A static DHCP reservation for `192.168.1.114` is defined for this device in the modem panel. Despite this, the `192.168.1.102` address appears to have been assigned/associated with this MAC at some point — which directly contradicts the reservation rule.

**Workaround/Temporary fix:** Disabling and re-enabling the rule via CLI or panel instantly resolves the issue.

---

## Root Cause: NAT/Conntrack Layer Ignoring ARP Update

The above data points to a single conclusion: when resolving the target IP for the MAC-based forwarding rule, **the NAT/connection tracking layer continues to use a stale cached mapping instead of the current, valid entry in the ARP table.** The router itself carries conflicting information in two different layers: the ARP table says `.114` is "valid", while the NAT chain still uses `.102`. This is, by definition, a synchronization error — two internal subsystems contradict each other about the same reality.

Let me be clear: a client device cannot choose its own IP. The authority for IP assignment and addressing lies 100% with the router's DHCP server. If my device was associated with `192.168.1.102`, the entity that created and maintained that association is the router itself — and this address directly contradicts my static DHCP reservation (`.114`) defined in the panel. A DHCP server violating its own reservation rule and/or carrying this violation into the NAT chain is an error that must be sought in KeeneticOS's addressing/routing layer, not on the client side.

This is the limit of what I can detect with the tools available to me — identifying which internal function misses this synchronization is, of course, the development team's job. However, I have no doubt that the problem exists, is reproducible, and is not client-originated.

---

## Workaround

I am bypassing the issue with an external Cloudflare Worker + ESP8266 watchdog combination that sends an automated disable/enable command sequence via Telnet to the router. This works functionally but is, of course, an application-level temporary fix; the actual correction should be on the modem/firmware side.

---

## Support Process

1. I presented the issue comprehensively to the Keenetic TR technical team with syslogs, NAT tables, and a live connection.

2. Despite the technical team connecting to my computer, verifying the issue live, and recording that the device was listed as static; instead of producing a solution, I observed attempts to shift the blame onto me with technically invalid justifications that contradict network engineering principles, such as *"your device is using two IPs, it is responding to an old IP."* I subsequently requested the closure of my support ticket.

   > My request to close the support ticket does not mean I accept the "client-side" explanation provided, nor does it mean I withdraw my technical objections — it is solely because of the pointlessness of continuing the process in this manner.

3. The initial corporate solution proposed (binding DHCP/ARP/port forwarding directly to a static IP) may work in practice, but it is a workaround — it leaves unanswered the question of why MAC-based dynamic forwarding behaves inconsistently in this scenario, and it proves that the MAC-based dynamic forwarding feature described in the documentation does not work under these conditions.

4. As an ordinary user, making definitive judgments with my limited data or misinterpreting the situation does not make the WAN access loss problem invisible, nor does it grant the technical support team any justification. My use of AI-assisted analysis tools to describe my problem is not "arrogance"; on the contrary, it is to describe the problem with the correct terminology, to draw attention to a chronic bug, and to find a rational solution. Distinguishing the limits of end-user analysis, correctly evaluating the data, and finding and researching the root cause is directly the responsibility of the Keenetic support team.

---

## Conclusion

The support team's approach gave me the impression that the focus was not on resolving a possible software bug, but on "rightfully closing" the support ticket at all costs, and the connection with the support team has been terminated.

As someone who previously recommended Keenetic to my circle with pride, this corporate lack of vision has deeply disappointed me.

Therefore, I have decided to move my network infrastructure entirely to another brand. This post is not a dry criticism of a company, but rather a technical reference and warning for those who are facing a similar issue and are left helpless.

---

**For Keenetic engineers who wish to examine the logs, the support ticket number is: `#656648`**

 

[eralde]

Hello @asdem

Your issue was investigated by the Turkish support team under the ticket number #656648. They conclude that the behavior you are experiencing is related to the client device on your network. The support team suggested that you should inspect how the client device is configured. They also did suggest a way to configure the port forwarding rule to target the static IP address assigned to that client device which should resolve the issue.

If you'd like, you can describe your issue in more detail in this forum thread (for example, by attaching a log from your router). This will help everyone reading the thread better understand what's going on.

In general, posting text generated by artificial intelligence on a technical forum is not encouraged. 

[asdem]

Thank you for keeping this topic open for discussion and technical evaluation. The only reason I moved this from the local support channel to the global forum was to present my experience as a concrete, reproducible diagnostic record — for other users facing a similar issue, and for the development team.

I'd like to note that the summary you shared conveys the TR team's conclusion, but it does not directly address the specific contradiction I presented in my report — that the IP marked as valid in the ARP table differs from the IP the NAT table is actually forwarding to. Attributing the issue to the client device without resolving this contradiction does not make the contradiction go away; if anything, it strengthens my doubts about the accuracy of that assessment.

Thank you for the suggestion of binding port forwarding to a static IP; I'm aware this is a practical workaround, and the TR team had already proposed the same thing earlier. However, before we can discuss a proposed solution, we need to agree on the problem itself: moving to a static alternative without first clarifying why MAC-based dynamic forwarding fails to work consistently in this scenario would mean avoiding the problem, not solving it. I'd therefore ask that you first provide a technical explanation for this — that is the only way we can reach common ground.

If my client device were truly behaving "inconsistently," this behavior should manifest the same way regardless of whether the router uses MAC-based or static-IP-based forwarding — because the client has no awareness of how it is being targeted. The fact that the problem disappears once a static IP is used instead points to the fault being in the router's MAC-to-IP resolution step, not in the client.

First, I want to state a plain fact: my client device does not have a static IP configured on the firmware side under any circumstances. The device operates entirely in standard DHCP mode and requests its IP address from the router itself. Per basic networking rules (RFC 2131), even if my device were to request a stale or incorrect IP, the router's DHCP server — given that a static reservation is defined in the panel — is obligated to reject that request and enforce the reserved `.114` address instead. The router violating its own reservation rule and leaking this stale data into the NAT layer points to a cache synchronization bug within KeeneticOS, not to the client.

I agree with your criticism regarding the use of AI. As an ordinary end user, I would have been expected to describe the complex kernel-level behavior I'm experiencing as simply "port forwarding doesn't work," receive the customer service response of "the client must be stuck — turn it off and on again," and move on with my life.

Hoping that your intention is genuinely to investigate the root cause, I am attaching the current, raw CLI output that demonstrates the error recurring systematically. For security reasons, I have masked only my WAN IP.

These current logs show the same mechanism we observed in the previous incident recurring — this time with the ghost IP `192.168.1.101`. I want to draw attention to one point here: if the issue were truly "the client responding to an old IP," this ghost IP should be the same in every occurrence. However, the fact that different addresses appear each time — first `.102`, now `.101` — strongly suggests that this behavior does not stem from the client holding onto a fixed "memory" of an old IP, but rather from a mechanism on the router's side that allocates a new address from its own DHCP pool each time and mistakenly carries it into the NAT/conntrack layer.

The ARP table correctly and freshly shows my device at `.114` (`expired: no`), while the NAT/conntrack table persistently continues forwarding packets to the expired ghost address `.101` (`expired: yes`).

If you continue to maintain that my client device is behaving incorrectly, I would ask that you technically explain how this behavior can be attributed to the client under RFC 2131, given that a static DHCP reservation is defined in the router panel — this would genuinely help us clarify the matter.

 

New_Telnet_Log(Wan IP Mask).txt

[eralde]

3 hours ago, asdem said:

Thank you for keeping this topic open for discussion and technical evaluation. The only reason I moved this from the local support channel to the global forum was to present my experience as a concrete, reproducible diagnostic record — for other users facing a similar issue, and for the development tea

@asdem, I've suggested that you provide logs from the router. You decided to provide output for specific commands instead and a wall of text that still reads like it was generated by an AI. The output provided is not enough to tell what lead the system to be in that state.

As for this:

3 hours ago, asdem said:

If you continue to maintain that my client device is behaving incorrectly, I would ask that you technically explain how this behavior can be attributed to the client under RFC 2131, given that a static DHCP reservation is defined in the router panel — this would genuinely help us clarify the matter.

please do not confuse moderating the forum and trying to help our users here with official technical support. I am sorry, but reading walls of AI text does not work for me personally. Maybe someone else will be able to help you more.

[asdem]

Understood — attaching the full raw router syslog below, covering the boot sequence and a fresh, live occurrence of the failure (July 16, around 06:28–06:29). WAN IP is masked for security.

I'll keep my comment minimal and let the timestamps speak for themselves. The relevant sequence (line numbers refer to the attached file):

06:28:58 — Soft-reload in progress (system time changed)
06:28:58 — Client (de:ad:be:ef:fe:01) sends DHCPREQUEST for 192.168.1.100
06:28:58 — Router correctly NAKs this request
06:28:58 — Client sends DHCPDISCOVER; router offers the reserved 192.168.1.114
06:28:58 — Client requests and receives ACK for 192.168.1.114 — DHCP negotiation ends correctly

06:29:03 — nginx proxy "ev.apranax.keenetic.pro" activates pointing to
           http://192.168.1.100:80 — the address that was just NAK'd
06:29:04 — coalagent logs: "Neighbour event duplicate rejected" for the same MAC
06:29:05 — nginx proxy re-activates, now correctly pointing to
           http://192.168.1.114:80

The DHCP server itself behaves correctly throughout — it rejects the stale address and assigns the reserved one without issue. The discrepancy appears between DHCP finishing negotiation (06:28:58) and the proxy/forwarding layer picking up its target address (06:29:03), which briefly uses an address the DHCP server had already rejected. This looks like a race condition between DHCP lease negotiation and proxy/NAT target resolution during soft-reload, rather than any inconsistency on the client side.

This may also explain why the "ghost" IP differs between incidents (previously .101, .102 — now .100): it corresponds to whatever transient/rejected address happened to be in flight at that specific reload.

Full log file attached.

Note: the client requesting a previously-used address on boot (INIT-REBOOT) is standard RFC 2131 client behavior, not a fault — and the DHCP server itself handles it correctly (NAK + reassignment). The discrepancy is isolated to the proxy/NAT layer's timing, as shown above

log(Wan_IP_Masked).txt

[asdem]

My previous message was intentionally kept strictly within the router syslog, in order to respect the moderator's request and stay within forum guidelines.

On re-reading it, I realized that the line "06:29:05 — nginx proxy re-activates, now correctly pointing to .114" could be misread as the system successfully "self-healing" or resolving the issue automatically.

To correct that potential misunderstanding, and to check whether the issue still exists on the latest firmware I just updated to (5.01.C.1.0-0), I'm sharing the log capture below.

**DHCP Is Working Correctly**
- `16:34:35` — Client requests `.101`
- `16:34:35` — Router rejects it with NAK
- `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 ev.apranax.keenetic.pro to http://192.168.1.101:80`
  → pointing to the IP that DHCP had just rejected.

**Nginx "Corrects Itself" Within 2 Seconds**
- `16:34:41` — `activated proxy ev.apranax.keenetic.pro to http://192.168.1.114:80`

However, nginx correcting itself within 2 seconds does **not** prevent incoming traffic from still being routed to the `.101` ghost IP roughly **2.5 hours later**, as shown in the NAT table below.

**`19:00:59` — CLI capture (MobaXterm session timestamp: 2026-07-16 19:00:59)**

`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 

CLI.txt log.txt

[asdem]

# KeeneticOS Post-Reboot Static NAT / Port-Forwarding Stale-Target Bug
## Live Reproduction Report with Timestamped CLI/Log Evidence (Redacted)

> **Note:** Identifying information (public WAN IP address, KeenDNS/registered domain names, router hostname, and the target device's MAC address) has been masked/replaced with placeholder values in this version for safe public sharing. All private LAN IPs (`192.168.1.x`), third-party public IPs (Cloudflare edge nodes, scanning hosts), and technical details are unchanged and remain fully representative of the original evidence.

**Router:** Keenetic Extra DSL (KN-2111), hw_id `KN-2111`
**Firmware:** release `5.01.C.1.0-0`, title `5.1.1`, ndw4 `5.1.C.1.0`, region TR
**Reporter role:** Network owner / independent verification via direct CLI (Telnet, NDMS)
**Related public report:** [Keenetic Forum #26592](https://forum.keenetic.com/topic/26592-a-user-experience-keenetic-kernel-level-bug-post-soft-reload-conntracknat-chain-locks-port-forwarding-target-to-a-staleghost-ip-proven-with-arp-nat-table/)

---

## 1. Summary

A MAC-based static port-forwarding rule (`ip static tcp`) targeting a DHCP-reserved host continues to forward traffic to a **previous, stale/expired IP address** after a router reboot ("soft reload"), even after:

- the device successfully completes a fresh DHCP handshake and is assigned/confirmed on its **current, correct IP**,
- the kernel's IPv4 conntrack/route cache is explicitly flushed by the router's own `Network::InterfaceFlusher` during boot.

The rule only re-resolves the correct target IP when it is **manually disabled and re-enabled** (`no ip static tcp ...` / `ip static tcp ...`), which forces the `Network::StaticNat` module to re-register the rule. A plain reboot does **not** trigger this re-registration.

This was reproduced live, on request, on the affected router, with real (non-simulated) external TCP traffic from independent, geographically distributed hosts (Cloudflare edge network + several public scanning hosts) hitting the stale target during the bug window, and a **before/during/after** behavioral test (connection timeout vs. successful HTTP response) confirming both the failure and the fix.

---

## 2. Affected Configuration

```
known host IoT-Device <MAC_ADDR>
ip dhcp host <MAC_ADDR> 192.168.1.114
ip static tcp PPPoE0 80 <MAC_ADDR>
ip http proxy ev
    upstream http <MAC_ADDR> 80
    domain ndns
    ssl redirect
    security-level public
    timeout 86400
ppe software
ppe hardware
```

Notes:
- The forwarding target is defined **by MAC address**, not by static IP, relying on KeeneticOS to resolve the MAC to the host's *current* DHCP lease at rule-apply time.
- The device has a DHCP **static reservation** for `192.168.1.114`, but historically (and again during this test) briefly requests/attempts its old lease `192.168.1.101` before the DHCP server corrects it.
- `ppe hardware` (hardware NAT acceleration / hwnat) is enabled — see §6 for a related observation.
- A second mechanism, `ip http proxy ev` (KeenDNS/nginx reverse proxy), also targets the same MAC independently of the `ip static tcp` rule.

---

## 3. Test Method

1. Captured a "before" snapshot: `show ip neighbour`, `show ip nat tcp`.
2. Manually triggered `system reboot` (soft reload) via NDMS CLI, with owner's explicit consent.
3. Reconnected as soon as the router came back online (~135–195s uptime) and immediately captured:
   - `show system` (uptime confirmation)
   - `show ip neighbour`
   - `show ip nat tcp`
   - `show log`
4. Attempted a live TCP connection to the router's public IP on port 80 from an independent host (LAN-originated, hairpin/NAT-loopback path to the WAN IP) to observe real behavior.
5. Applied the known community workaround: `no ip static tcp PPPoE0 80 <MAC_ADDR>` followed by `ip static tcp PPPoE0 80 <MAC_ADDR>`.
6. Repeated the same connection test to confirm resolution.
7. Additionally configured the router's **built-in native packet capture** (`monitor > capture > interface <if>`, `output-directory`, `filter "tcp port 80"`, `direction in-out`) simultaneously on `PPPoE0` (WAN) and `Home`/`Bridge0` (LAN), writing to a dedicated ext4 USB partition, to allow full packet-level analysis independent of the summarized NAT table.

---

## 4. Timeline of the Reboot Window (system log, local time UTC+3)

```
I [Jul 18 05:37:09] ndm: Core::System::Clock: system time has been changed.
I [Jul 18 05:37:09] ndhcps: DHCPREQUEST received (STATE_SELECTING) for
                    192.168.1.101 from <MAC_ADDR> hostname "IoT-Device".
...
I [Jul 18 05:37:11] ndm: Network::InterfaceFlusher: flushed IPv4 conntrack and
                    route cache.
...
I [Jul 18 05:37:19] ndhcps: DHCPREQUEST received (STATE_INIT) for 192.168.1.101
                    from <MAC_ADDR> hostname "IoT-Device".
I [Jul 18 05:37:19] ndhcps: sending NAK to <MAC_ADDR>.
I [Jul 18 05:37:19] ndhcps: DHCPDISCOVER received from <MAC_ADDR>
                    hostname "IoT-Device".
I [Jul 18 05:37:19] ndhcps: making OFFER of 192.168.1.114 to <MAC_ADDR>.
I [Jul 18 05:37:19] ndhcps: DHCPREQUEST received (STATE_SELECTING) for
                    192.168.1.114 from <MAC_ADDR> hostname "IoT-Device".
I [Jul 18 05:37:20] ndhcps: sending ACK of 192.168.1.114 to <MAC_ADDR>.
```

**Key observation:** the device tried to renew its *old* lease (`.101`) twice, was correctly `NAK`'d, and was correctly re-assigned/confirmed on `.114` at `05:37:20`. DHCP itself behaved correctly.

Critically, **no `Network::StaticNat: static NAT rule has been added` event appears anywhere in this boot cycle's log.** Compare with the *previous* reboot (caused by an unrelated component install), where the exact same rule produced this log line on boot:

```
I [Jul 18 03:57:52] ndm: Network::Nat: a NAT rule added.
I [Jul 18 03:57:52] ndm: Network::Nat: a NAT rule added.
I [Jul 18 03:57:52] ndm: Network::StaticNat: static NAT rule has been added.
```

This strongly suggests the `Network::StaticNat` module does **not** always re-register/re-resolve the MAC→IP binding fresh on every boot — on at least one of the two observed reboots, the rule was carried over from a stale internal/serialized state rather than being freshly bound to the DHCP server's current lease table. This would explain why a manual `no ip static tcp` / `ip static tcp` toggle (which unambiguously forces a fresh `Network::StaticNat` registration) fixes the problem, while a reboot does not reliably do so.

---

## 5. Live NAT Table Evidence — Bug Active (captured within seconds of the ACK above)

```
show ip neighbour   (<MAC_ADDR>)
    address: 192.168.1.101   expired: yes   <- stale
    address: 192.168.1.114   expired: no    <- current, DHCP-confirmed, leasetime 193s

show ip nat tcp   (filtered to relevant rows; <WAN_IP> = router's public IP)
TCP  172.69.63.192   9633   <WAN_IP>  80   4
     192.168.1.101   80     172.69.63.192 9633  4      <- real Cloudflare edge node, forwarded to GHOST IP
TCP  172.69.63.193   13722  <WAN_IP>  80   4
     192.168.1.101   80     172.69.63.193 13722 4      <- same
TCP  160.200.30.10   40733  <WAN_IP>  80   1
     192.168.1.101   80     160.200.30.10 40733 1      <- external scanner, forwarded to GHOST IP
TCP  160.200.32.10   40819  <WAN_IP>  80   1
     192.168.1.101   80     160.200.32.10 40819 1
TCP  160.200.38.10   40820  <WAN_IP>  80   1
     192.168.1.101   80     160.200.38.10 40820 1
```

At the exact same moment, the router's own neighbour table (correctly) shows `192.168.1.114` as the live, non-expired host for that MAC. **Five independent real external sources were forwarded to a dead IP while the correct IP was already confirmed and active.**

### Behavioral confirmation (live connection test)

| State | Test | Result |
|---|---|---|
| Bug active | `GET / HTTP/1.1` to router's public IP:80 | **`TimeoutError`** — connection never established, no RST, no data (silent black hole at `.101`) |
| After toggling `no ip static tcp` / `ip static tcp` | Same test repeated | **`HTTP/1.1 500 Internal Server Error`** returned immediately — proves the packet now reaches the live device at `.114` |

---

## 6. Secondary Observation: Hardware NAT Acceleration Path

While captures were configured on `Home`/`Bridge0` (LAN) with `filter "tcp port 80"`, a LAN-host-originated connection to the router's own public IP (NAT hairpin/loopback) **did not appear in the LAN-side capture at all**, despite succeeding at the connection level and despite the software `show ip nat tcp` table not showing an entry for it either shortly after. Genuine externally-sourced traffic (the Cloudflare/scanner hits above) *did* appear in the software NAT table and WAN-side capture growth.

This is consistent with — but not proof of — the hypothesis (also raised in the original forum thread) that KeeneticOS's hardware NAT acceleration (`ppe hardware`, "hwnat") maintains a flow table that can diverge from the software `nf_conntrack`/`StaticNat` state, particularly around reconnection/reboot events. Further investigation with the native packet-capture feature (see §7) across an additional full reboot cycle would help confirm or rule this out definitively.

---

## 7. Tooling Notes (for reproducing this test)

- KeeneticOS's Telnet/SSH CLI (NDMS) does **not** expose a raw Linux shell, even after installing the `opkg` / `opkg-kmod-netfilter` components. `opkg chroot`, `opkg disk`, etc. are configuration toggles, not command execution.
- A **native, built-in packet-capture feature** exists and does not require Entware/opkg at all:
  ```
  monitor
  capture
  interface <ifname>
      output-directory <disk-label>:/
      filter "<bpf-expression>"
      direction in-out
      enable
  ```
  This writes real `.pcap` files (+ `.stats`) to any mounted storage, and can be run simultaneously on multiple interfaces (e.g., `PPPoE0` and `Home`) — directly satisfying the "simultaneous WAN/LAN tcpdump" requirement without any third-party package installation.
- Component installation (`components` mode, `install <name>`, `commit`) can trigger an **automatic router reboot** when kernel modules are involved (e.g., `opkg-kmod-netfilter`) — this caused two of the reboots observed during this investigation and should be expected/scheduled deliberately.

---

## 8. Conclusion

This investigation independently reproduces, with router-native evidence (system log + live NAT table + real external traffic + a controlled behavioral before/after test), the exact defect reported in Keenetic Forum topic #26592: **a MAC-based static TCP port-forwarding rule can remain bound to a stale/expired DHCP lease after a soft reboot, silently black-holing external and internal connections, until the rule is manually toggled off and back on.** The DHCP server itself, and the `show ip neighbour` table, are correct throughout — the discrepancy is isolated to the `Network::StaticNat` rule-resolution/caching logic not being refreshed on every boot cycle.

### Recommended fix directions for Keenetic engineering
1. `Network::StaticNat` should re-resolve (or at minimum re-validate) each MAC-based static NAT rule's target IP against the current DHCP lease table on every boot, not only when the rule is explicitly (re)configured.
2. Alternatively/additionally, subscribe `Network::StaticNat` to DHCP lease-change/ACK events so a lease renewal (not just a config change) triggers re-resolution.
3. Audit whether `ppe hardware` (hwnat) flow entries are invalidated in lock-step with software `StaticNat`/`nf_conntrack` state during boot and interface flush events.

### Practical workaround (confirmed effective)
```
no ip static tcp <interface> <port> <mac>
ip static tcp <interface> <port> <mac>
```
Run this after every reboot (or automate it, e.g., via a startup script/schedule) until Keenetic ships a fix.

---

## 9. Request for Follow-up

We would appreciate an acknowledgment and status update from Keenetic's engineering team regarding this report. We are happy to provide additional diagnostic files, raw packet captures (`.pcap`), or perform further tests on request. Since this defect causes silent, hard-to-diagnose connectivity failures on a commonly used configuration (MAC-based static port forwarding), we believe it warrants investigation and a fix in an upcoming firmware release.

---
*Report compiled from live CLI/Telnet sessions against the affected router, with the owner's knowledge and consent, on 18 July 2026. Identifying details redacted for public sharing — see note at top of document.*

 

keenetic_stale_nat_bug_report_masked.md keenetic_stale_nat_bug_report_masked_TR.md kt_after_reboot_MASKED.txt kt_before_reboot_MASKED.txt kt_bug_live_MASKED.txt kt_confirm_fix_MASKED.txt kt_do_reboot_MASKED.txt kt_fix_toggle_MASKED.txt