Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - dnll

#1
General Discussion / Re: Allow access to port 9200 locally
September 12, 2024, 05:44:03 AM
Quote from: doktornotor on September 12, 2024, 03:37:02 AM
Quote from: dnll on September 12, 2024, 02:13:19 AM
Quote from: doktornotor on September 10, 2024, 09:37:01 AM
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.

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.
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.
#2
General Discussion / Re: Allow access to port 9200 locally
September 12, 2024, 02:25:17 AM
Quote from: meyergru on September 10, 2024, 09:35:31 AM
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.
#3
General Discussion / Re: Allow access to port 9200 locally
September 12, 2024, 02:13:19 AM
Quote from: doktornotor on September 10, 2024, 09:37:01 AM
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.

Quote from: meyergru on September 10, 2024, 09:35:31 AM
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.
#4
General Discussion / Allow access to port 9200 locally
September 10, 2024, 09:18:29 AM
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):

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.
#5
High availability / Re: 2 OPNsense routers
October 06, 2023, 06:05:20 AM
Quote from: Monviech on September 27, 2023, 06:47:24 AM
Is your modem connected via pppoe, or ethernet?
If you want to have help you have to post your basic network structure.

Also just as a tip, if its pppoe it's not going to work seamlessly. Also the failover with it (in my tests) was prone to wonky behavior. The patching of an opnsense takes like 2-3 minutes, in which the reboot maybe takes 1 minute. Only bigger upgrades every half a year take some more time. So you should think about if the usecase is really there. CARP and HA setups are quite complicated.

Here for a basic CARP HA setup: https://docs.opnsense.org/manual/how-tos/carp.html
I do get my main public WAN IP through PPPoE, although my ISP (Bell) also allows me to get a second public WAN IP if I don't go through PPPoE but use the modem-router DMZ instead. There is nothing else between the modem-router and my OPNsense box.

Obviously, the whole project is more for fun than anything else, I just happen to have 2 Sophos SG330 units, I kinda like the idea of having the backup unit in case hardware fails on the first unit, so why not setup high availibility. I did read the doc but I couldn't really make any sense of it, I just wish it could somehow be easier but I guess it isn't. I might just end up copying the config to the second unit and turn it off and just turn it on in case the first unit has issues.
#6
High availability / 2 OPNsense routers
September 27, 2023, 04:34:28 AM
Hello,
I have WAN on my modem going to my first OPNsense box. I have another OPNsense box and I'm unsure how to proceed. What I want is to be able to patch/reboot one box without losing my network.
What is the best way going forward?
Thank you
#7
Quote from: Maurice on September 02, 2023, 05:14:05 AM
Have a look at the routing table. 192.168.2.0/24 is on-link on wan_2. And because that route is more specific than the default route (0.0.0.0/0), it has a higher priority.

The outbound NAT rule is required because your "modem router box" doesn't have a return route to the OPNsense LAN subnet (from where you want to access that box).
You are right about the routes. Thanks for the explanation, that makes a lot of sense! I learn something new everyday :)
#8
Quote from: Maurice on September 02, 2023, 04:25:21 AM
The interface in the outbound NAT rule is WAN_2, everything else can be left at default settings.
It works! Would you care to explain to me how outbound packets know whether the need to use the WAN_1 gateway or what is currently called WAN_2 to reach their destination?
#9
Quote from: Maurice on September 01, 2023, 02:43:53 PM
Configure WAN_2 statically.
Don't create a gateway for WAN_2.
Create an outbound NAT rule for WAN_2.
That should be it.
So, I disabled the gateway and went to the outbound NAT rule section. Never used this in the past, I'm ready to add a rule but I'm worried I'll lock myself out of my network. I assume the destination would be wan_2_net but I'm unsure about the other settings.
#10
General Discussion / Basic multi-WAN route/prioritization
September 01, 2023, 05:04:36 AM
Hello there,

My ISP gave me a modem-router box which I'm able to bypass the routing functin with PPPoE passthrough (WAN_1). So I have this set up in OPNsense and it works well. However, with the PPPoE passthrough, I'm not able to log in to my modem to change its config, so what I'm doing is I'm hooking a second ethernet cable from my modem to my OPNsense box and have this set up as another WAN using DHCP (WAN_2). This way I'm able to access both the internet (through WAN_1 and WAN_2) and my modem-router through WAN_2.

Now, my local network on OPNsense is set up as 10.0.0.0/8. The modem-router box has its own DHCP server working on 192.168.2.0/24. I get a public address on WAN_1 through PPPoE, and a 192.168.2.0/24 address through WAN_2. I'd like all traffic to go through WAN_1 except explicitely for the trafic trying to talk to the 192.168.2.0/24 network. What is the easiest approach?

Thank you!
#11
Quote from: franco on April 28, 2023, 08:31:37 AM
Did you mistake 22.7_4 for 22.7.4 perhaps?


Cheers,
Franco
Definitely did, I updated through the web UI and never saw 22.7.4. Had to update ~4 times to get to 23.1.6.

Sent from my Pixel 7 Pro using Tapatalk

#12
Can confirm it's in the Unbound general settings starting with version 23.1. I just enabled the option and added an override for the IP I want it to be, works like a charm.
#13
Just upgraded to 22.7.4 and... can't find that option in Unbound settings or general settings?

I will complete the upgrades up to 23.7 later on tonight and will report back if I find that new setting. Didn't realize I was so far back.
#14
Quote from: franco on April 27, 2023, 02:14:24 PM
Which service are you using? And did you select specific interfaces or left it to "all (recommended)"?


Cheers,
Franco
I don't understand your question? What do you mean, which specific interface? You mean in Unbound settings? I left it untouched to "all".

Attached is a list of my running services. I'm still on 22.1.10 but someone else replied with another version.

Sent from my Pixel 7 Pro using Tapatalk

#15
Rather simple issue here, when I try to ping opnsense with its hostname it replies from a different IP every time.



All of those addresses are different subnets. I'm doing my tests from the 10.1.1.0/24 subnet (which has access to all the other subnets). Is there a way to make it so that the DNS answers with the IP from the correct segment when asked about itself?

I'm using Unbound.