No worries; I appreciate the concern. You’re not being a bother or interrupting a vacation. I mentioned personal time so you knew why my response was delayed.
I compared this version with an earlier version (HERE), and the main difference is that instead of using the existing lan firewall zone, it creates a new zone. That’s one area where it might be more fragile than the original approach. I’m suspecting that there is a firewall or interface reload triggering a state drift which breaks this. That would explain why it works initially but later becomes unreachable.
Here is an updated version that returns to the original LAN-zone logic (it is a bit different as it adds detection in case we ever move it from [0]). It defaults to the simple, proven method (direct attachment to the LAN zone), and also includes an optional macvlan mode. The macvlan option doesn’t change routing or firewall behavior, but can be more robust on systems where interface or routing state changes might otherwise interrupt access.
There are some variables at the top if needed. Hope this helps but please let me know either way. I would recommend regular/plain mode to start, but if the issue persists, then I would suggest trying the macvlan mode next.
SCRIPT REMOVED.