Static DHCP and possible web interface for port-forwards

[StickyDigit]

Port forwarding cannot currently be configured via the web interface. Even with port-forwarding, unless using static IP allocated at the client, it's hard to pin down the addresses to forward ports of, and unclear what the DHCP range is to ensure safe allocation of static IPs which leads me to a potentially more important feature request:-

I would like to be able to allocate static IPs for at least a few of the DHCP clients. Having a web interface for such a feature would be nice too, but not essential. With static IPs, it would be easy to reserve addresses for manual configuration, or ensure specific DHCP clients are "findable" for port forward or other purposes.

Last one for today.. I promise :)

[StickyDigit]

While digging around this, I found an odd thing.

It's possible to ping hosts on the NAT/AP side from the LAN/STA side if one sets a route like "route add -net 192.168.4.0/24 gw 192.168.0.123", where 192.168.0.123 is the STA IP on the 192.168.0.0/24 subnet. The routing is not complete, so one cannot e.g. ssh to the clients. This may be a sign of a broken NAT, forwarding all ICMP 'back' to any client that has opened a connection outbound.

[gjroots]

Hi @StickyDigit, thank you for raising this issue on GitHub. I understand the problem you're facing regarding port forwarding and the challenges with allocating static IPs for DHCP clients. It would indeed be useful to have a web interface for configuring these features.

To better assist you and provide a solution, I would appreciate if you could provide more details about the specific context in which this issue occurs. It would be helpful to understand the codebase or any relevant concepts related to the problem.

Additionally, if you have any insights on how to potentially solve this issue or any suggestions for improvements, please feel free to share them. This will allow me to better address the problem and provide you with a more accurate solution.

Next time using the issue template helps in capturing all the necessary details and context about the problem you are facing, which in turn enables me to provide a more accurate and timely solution. It also ensures that the relevant information is readily available to other contributors or developers who might be working on the issue.

Thank you for your understanding, and I look forward to assisting you further in resolving this issue.

[StickyDigit]

There is no apparent way to force a client to be allocated the same IP based on MAC address at each connect. There is also no apparent way to select a reserved block of the subnet which ESP32 DHCP will not serve, to allow for manual IP allocation where devices permit,

A quick look with Wireshark and it seems the DHCP lease time is 2 hours. My other laptop just got allocated x.x.x.47. I've not connected many things to that AP and would expect it to still be in single digits.

Example. Raspberry-pi server has 192.168.4.123/24 statically set manually when it is connected to esp32 AP. It cannot be assumed the device will be alive before another device has been allocated that address by DHCP, e.g. a few different IoT devices which report to the Pi using a fixed hard-coded IP, some not supporting mDNS. Imagine a small waiting room, with open AP, people pass through, maybe no more than four at a time, so the DHCP is possible to cycle through it's range and hit 123 during the server reboot.

That is of course not true if due to the limited number of clients the ESP32 can handle (10? I started having trouble after 7), the DHCP pool is also limited an d lease length is short. This not being documented or adjustable, one cannot assume the DHCP won't cycle round the whole range of 2-254 in some circumstances.

If we knew the DHCP range were limited to say 2-200, then 201 to 254 could safely be used. I realise it's not as easy as that unless the AP IP is always x.x.x.1.

In the case of having a server/service behind the NAT: One can forward a port from a specific IP inside the NAT, but it is futile if the IP is not knowable or reliably static from boot to boot.

• Knowing a bit more about the constraints of the DHCP employed would be helpful to this user. Being able to tune it may not be necessary if only a small pool is allocated, leaving some of the subnet safe for manual allocation.
• Being able to set MAC->IP reservations would make it worthwhile to set port mappings to reach simple web interfaces or sensors behind the NAT where the devices are "DHCP only". I expect this feature would be of more interest to most tinkerers who would want to prod services behind the NAT, like simple web dashboards of microcontrollers.

I have several scenarios where this project would be useful. Mostly low bandwidth, and to reduce client load on main wifi AP, and mostly needing to reach systems inside the NAT from outside it. Port-mapping is fine, but useless if the IP cannot be known.

I also realise stuffing a Pi behind the AP would allow me to e.g. auto-ssh to a server outside the setup. The Pi would still need to be able to identify the clients, ideally without such faff as tcp-connect-sweeping the whole subnet then scraping ARP to find them, which might need repeating when a client fails to respond due to new DHCP allocation.

One of my use cases is all ESP32/8266 devices, all with fairly limited resources, and all DHCP only. They all have web interfaces I can simply wget from outside the NAT for status updates, but not if they're on random IP which needs port-mapping every time they boot. This particular scenario is low power, and given the limited number of clients the ESP32 can handle, it's desirable to have only the ESPs connected to the AP. I may end up tweaking as many as I can to have static IP, and ignore DHCP in some clusters, but that's not as simple as rolling out "one firmware fits all", requiring per-flash configuration.

I hope this gives some insight into what I'm thinking about, and scenarios where DHCP reservations, and more detailed documentation of client-count limits, and DHCP parameters/function would increase usability of your fantastic fork of martin-ger's brilliant project.

For what it's worth, the esp8266 version of martin-ger's NAT router is potentially better in some of my use cases, the 'save dhcp' function is useful but seemingly unreliable. That project does route both ways where a static route can be set in the STA-side subnet, eliminating the need for port-mapping, at some expense to security in portable applications. I keep a keen eye on both his ESP routers. If you ever add a good web interface to that project, I'll be delighted.

[gjroots]

I may not fully grasp all the details, but I appreciate your input. I will take your concern into consideration for future updates. Thank you for bringing it up.