Allow access to port 9200 locally

[dnll]

Hey y'all,
I use Zenarmor with the ElasticSearch database on OPNsense and want to monitor that database from another host on my local network. I noticed however that the connections to OPNsense on port 9200 are blocked. So I created this rule:


When I test locally on OPNsense, no problem as expected (no rule needed):

Code Select Expand


root@router01:~ # telnet 127.0.0.1 9200
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.


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.

[meyergru]

The database seems to be bound to IP 127.0.0.1 for security reasons. This way, it is not accessible from outside the host itself. You would have to make it bind to 0.0.0.0 instead, but IDK if you can tweak the configuration.

[doktornotor]

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.

[dnll]

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.

Unsure why I would need any port forwarding here, I'm connecting directly to the OPNsense box on the correct port.

The database seems to be bound to IP 127.0.0.1 for security reasons. This way, it is not accessible from outside the host itself. You would have to make it bind to 0.0.0.0 instead, but IDK if you can teak the configuration.

That actually makes a lot of sense, I'll keep digging.

[dnll]

The database seems to be bound to IP 127.0.0.1 for security reasons. This way, it is not accessible from outside the host itself. You would have to make it bind to 0.0.0.0 instead, but IDK if you can teak the configuration.

Solution was to add network.host: 0.0.0.0 to /usr/local/etc/elasticsearch/elasticsearch.yml. Haven't tested yet if this persists reboots/updates/etc but that will do for now, I will come back here and comment if I need to do anything else to make it persist.

[doktornotor]

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.

Unsure why I would need any port forwarding here, I'm connecting directly to the OPNsense box on the correct port.

Because the packets are not arriving on localhost (loopback) interface at all, as you have observed.

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.

[dnll]

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.

Unsure why I would need any port forwarding here, I'm connecting directly to the OPNsense box on the correct port.

Because the packets are not arriving on localhost (loopback) interface at all, as you have observed.

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.

Ha, 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:

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.