Quote from: doktornotor on September 12, 2024, 03:37:02 AMHa, this makes a lot of sense. I disabled the network.host option in the yml configuration file (basically putting it back like it was by default) and created this NAT rule:Quote from: dnll on September 12, 2024, 02:13:19 AMQuote from: doktornotor on September 10, 2024, 09:37:01 AMUnsure why I would need any port forwarding here, I'm connecting directly to the OPNsense box on the correct port.
You need a port forward to 127.0.0.1:9200 on the interface where the monitoring host is, not an allow rule on localhost.
Because the packets are not arriving on localhost (loopback) interface at all, as you have observed.Quote from: dnll on September 10, 2024, 09:18:29 AM
However, when trying from 10.1.1.21, the telnet never connects. Am I missing something obvious here? The 10.1.1.0/24 subnet is in the LOCAL group.
P.S. Making ES listen on wildcard is... crazy. Would really suggest to undo that and do the simple port forward. This post has a proper example of such NAT rule to make services that listen only on loopback accessible over LAN to chosen hosts. Use 10.1.1.21 for source and 9200 for destination and redirect target ports.

And I can confirm it now works through the loopback interface. I used the "This Firewall" option as destination, unsure if it makes any difference or not compared to the other possibilities and/or if there are better practices in that regard.
Either way, it's certainly more secured than having ElasticSearch listening to everything (or even just the whole local network). I guess it's more or less similar as if I had ElasticSearch listening specifically to my source, but having the configuration centralized within the firewall without having to edit any configuration whatsoever is just cleaner overall.