tofubl

Read your reply now, and not sure about the requirements you have: must not leave the local devices or must not use the WiFi?

If it's the latter, a 4g USB modem with a cheap iot data plan easily frees you of that.

I second Zigbee.

• There's plenty of devices available.
• Battery life is amazing.
• zigbee2mqtt is an easy way to bring those messages into your regular IP network; they have a huge list of supported devices.
• Once translated to MQTT, you can hook any automation onto it you want: a python script, home assistant, or my recommendation in this case, NodeRED. NodeRED has a module for zigbee2mqtt that is very well integrated to just know all devices registered on your zigbee network and stringing flows together is actually fun once you get the hang of it. Plus, there is no upper bound to flow complexity.
• Gateway device can be a sonoff zigbee USB coordinator and the whole thing can comfortably run on a rpi3.

It's only fair.

Have your parents and siblings changed their everything as well? That's how I would try to find someone I went to school with.

The answer seems to always be "not segmented enough". ;)

Haha, why do I even ask.

This is a good hint, I'm going to take a look at that. Thank you!

I never specified, I think, and probably wasn't too clear on it myself. Thanks for your insights, I'll try to take them to my configuration now.

This is exactly the type of answer I was looking for. Thanks a bunch.

So but in that way, having a proxy on the LAN that knows about internal services, and another proxy that is exposed publicly but is only aware of public services does help by reducing firewall rule complexity. Would you say that statement is correct?

Right, I agree with proxy exploit means compromised either way. Thanks for your reply.

I am trying to prevent the case where internal services that I don't otherwise have a need to lock down very thoroughly might get publicly exposed. I take it it's an odd question?

Re "bouncer": Expose some services publicly, not others, discriminated by host with public dns (service1.example.com) or internal dns (service2.home.example.com), is what I think I meant by it. Hence my question about one proxy for internal and one public, or one that does both.

Right, I could have been more precise. I'm talking about security risk, not resilience or uptime.

"It’ll probably be the most secure component in your stack." That is a fair point.

So, one port-forward to the proxy, and the proxy reaching into both VLANs as required, is what you're saying. Thanks for the help!

The services run on a separate box; yet to be decided on which VLAN I put it. I was not planning to have it in the DMZ but to create ingress firewall rules from the DMZ.