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 - Robertomcat

#1
General Discussion / Re: CrowdSec
August 29, 2025, 11:55:34 AM
Hello, good morning.

I've had CrowdSec installed for a few weeks now, and I understand that just installing it provides the basic configuration and protection to function properly. Are there any additional settings to improve its performance or security? Thank you very much for the development.
#2
Quote from: patient0 on August 27, 2025, 12:58:02 PMAs mentioned, you can consolitate the first and last rule into the one I wrote (a pass rule with destination everything-except-the-alias-network), but you don't have to. And the DNS would come before your block-the-aliases.
I've tested the rules you wrote for me, disabled my rule, and the order is now as follows: Access DNS > Client Isolation > Internet Access
With these three rules, all computers have Internet access, but they also have access to other LANs, and can also communicate with each other via remote desktop (for example).
I'm sure I didn't do the rule correctly. Do you see everything as correct?
#3
This would be the current configuration, but I haven't tested it yet to prevent the computers from losing Internet.
#4
Hello, good morning. Is this DNS access rule you've set up for me to be added after the rule I included in my first post?
Quote from: patient0 on August 26, 2025, 11:21:19 PM# Allow clients to access router for DNS queries
Action: pass
Interface: MQL
Direction: in
Protocol: udp, port 53
Source: MQL net
Destination: MQL address

This rule is already created, but I named it "alias" because the original name of the alias that blocks access to the three networks is: "Bloqueig_de_MQL5_a_LANs", which is written in Catalan.
Quote from: patient0 on August 26, 2025, 11:21:19 PM# Allow access to everything except 192.168.1.0/24 - 192.168.2.0/24 - 192.168.18.0/24 from the MQL network:
Action: pass
Interface: MQL
Direction: in
Protocol: any
Source: MQL net
Destination: ! (not) "aliases"

#5
Quote from: BrandyWine on August 25, 2025, 07:25:04 PMThere's also a "trick" where you use .1q between FW and a large # port switch, where each host is in it's own vlan ID (one switch port per ID), thus the only way two hosts can talk to each other would be to ride .1q to FW and then back to switch, but you would apply FW rules accordingly. Not 100% this would work with OPNsense.
I don't think I quite understand what you're referring to, because my knowledge of the vastness of OPNsense is pretty basic. My needs aren't very demanding, so I only have basic security settings, like Unbond DNS Blocklist and CrowdSec (CrowdSec doesn't require any further configuration with the basic installation, right?). Thanks!

Quote from: patient0 on August 25, 2025, 09:35:41 PMWhat about the other questions of mine? As I wrote, your clients won't be able to resolve any DNS request if the DNS is set to a MQL network IP.
Yes, OPNsense itself resolves DNS requests. I previously had external DNS servers, but reading posts here on the forum, I found the most private and secure way was the default OPNsense configuration. Thank you for your answers!

https://forum.opnsense.org/index.php?topic=39119.msg191611#msg191611
#6
Quote from: patient0 on August 25, 2025, 05:05:55 PMCan you post the full ruleset for MQL net?
This rule prevents access to 192.168.1.0/24 - 192.168.2.0/24 - 192.168.18.0/24 from the MQL network:
Action: Block
Interface: MQL
Direction: in
Protocol: any
Source: MQL net
Destination: "aliases"


And this other rule grants Internet access:
Action: pass
Interface: MQL
Direction: in
Protocol: any
Source: MQL net
Destination: any

I only have these two rules. The others are the ones OPNsense uses by default, plus the ones CrowdSec created, but those are all hidden in the drop-down menu.
#7
General Discussion / Isolate clients from a network
August 25, 2025, 01:59:30 PM
Hello, good morning.

I currently have three physically segmented networks: Wi-Fi, LAN, and MQL. All devices within the LAN and Wi-Fi have access to MQL, and I've created a rule for the MQL network to not have access to other networks.

But when I try to create a rule to prevent devices within MQL from communicating with each other within the same network, the devices are unable to access web pages, but they can ping DNS servers and services.

This is the rule, and I have it before the Internet outbound rule. What procedure am I doing wrong?

Action: Block
Interface: MQL
Direction: in
Source: MQL net
Destination: MQL net
#8
Quote from: cookiemonster on June 22, 2025, 06:50:04 PMUnderstood. But how does the cable (there must be one) from the street connect to the "router + ont Huawei" ?
Yes, a fiber optic cable runs from the street to the Huawei router+ont Huawei (it is an all-in-one device), and then I have to run a 15 cm cable from the Huawei router to the OPNsense device.
#9
Quote from: cookiemonster on June 22, 2025, 06:33:10 PMThat clear now.
OPN then on the DMZ is one way of doing things. I think fritboxes force this setup too but I am not certain.
One thing to check however. If your ISP leaves an electrical terminating device on the wall and it is an Ethernet cable from it to the current Huawei, you could in theory plug it instead onto the WAN of your OPN device directly. No Huawei in the chain.
Electrically is the same. The difference is whether your ISP requires authenticating details to establish a connection and those are hard set on the Huawei.
If that is the case and you can get them and transfer them to OPN WAN settings, you're set.
My ISP provides the fiber optic cable from the street to the router + ont Huawei, then I have to connect from a RJ45 port Huawei to OPNsense.
#10
Quote from: cookiemonster on June 22, 2025, 12:44:59 AMpesky ISP updates. I'm glad you got to the bottom of it.
Out of interest though. You say your ISP gives you a device running OPNSense as your ONT. Are you sure about that?


My ISP provided me with a very basic Huawei router which is an all in one, ONT + Router, and I had to activate the DMZ and then put another device for the OPNsense. Tomorrow I will contact my ISP to see if they can provide me with a dedicated ONT, or provide me with the communication data between OLT and ONT and buy a configurable ONT myself.
#11
@viragomann @cookiemonster
I was able to fix the problem. The problem was that the ISP router had a factory reset for some reason, and the DMZ had disappeared. Once activated, everything worked, although in opnsense the internal IP address provided by the ISP router still appears. I will have to look for a universal ONT to solve this "problem". Thank you very much for your patience with your troubleshooting ideas.
#12
Quote from: viragomann on June 19, 2025, 07:28:33 PMYes, but your public IP is assigned to the ONT, while OPNsense behind it has a private IP as your screenshots show.
So your ONT is a router in fact.
This is an essential information.

So first of all you have to forward the traffic on the outer router (ONT) to OPNsense. Have you even done this?
The router/ONT It has a specific configuration to put it in bridge mode which is how it currently is, and all traffic is redirected to opnsense. It will be a year or so now that it has been running like this.
#13
Quote from: cookiemonster on June 19, 2025, 11:54:10 AMUnless I read this wrong, you seem to be in a double NAT scenario AND you have two OPN routers in series i.e. one behind another.
I'm going to let someone else chime in but in short, you need to then read up on double NAT, see if your second OPN has blocked private networks on the WAN interface settings at the minimum. Is it possible to have only one OPN in place?
p.s. I'm not going to be able to help much in a OPN behind OPN scenario
Oh no, I only have an opnsense and the ONT. And yes, it has been a lack of information on my part, because at no time had I reported that I had an ONT AND OPNsens, I had automatically deduced that it was something unimportant. Sorry for all this time.
#14
Quote from: cookiemonster on June 18, 2025, 11:44:29 PMRespectfully, this makes no sense yet. Your ISP can not give you an ip of 192.168.1.200; that is an internal ip address, one in your network(s). You will be able to see this in Interfaces > Overview. There you'll have the actual ip issued by your ISP assigned to WAN.
Can you share those assignments with a screenshot? Mask your WAN ip if you're uncomfortable showing it.
To reiterate: port forward from WAN to an internal LAN (regardless of its name) can only be tested from outside.
What I am trying to do is to help you not verify why your torrenting or whatever is not working, but to first verify that your port forward nat and associated rule works. When that happens, you can concentrate in the torrent or whatever.
Why? Because it can be your seeding thing can block your client, can block your ip address, etc.
To this end, I am suggesting to test the port forwards by putting some traffic across the rules to see where they stop. Makes sense?
So if you test NOT from the outside, you haven't proven the rules are the problem.
Hello, good morning.
The IP address 192.168.1.200 is the fixed IP address I assigned to my personal computer, and my ISP provides public IP addresses via DHCP, and I currently have 85.XXX.XX.86. The same company that provides internet also provided me with an OPNsense ONT in front of OPNsense, so OPNsense has an internal IP address on the WAN. But I've always had an ONT regardless of which router I've been using.
#15
Quote from: cookiemonster on June 18, 2025, 06:30:21 PMYour goal: to reach ports 55432 and plex(plex_port) from the WAN through OPN to the LAN server hosting those ports. That part I get.
The goal is to be able to access an HP ML110 server from the outside, which has the IP address 192.168.10.55, within the internal network called MQL5 (I have other internal networks called LAN and Wifi). And to open the specific port 55432 for qbittorrent and 46837 for plex. These two rules are created in the NAT and automatically on the WAN.
Quote from: cookiemonster on June 18, 2025, 06:30:21 PMScreenshot above. You seem to have tested from 192.168.1.200. Your target is 192.168.10.55 so that is not a test _through_ the WAN, so it won't test the NAT port forward. So unless you are trying to test another intra-interface flow, I'm not sure it helps.
What's shaded in the screenshot is my IP address provided by my ISP, and I've run the command with that IP address along with port 55432, but since I'm no expert, I've probably done it wrong.
Quote from: cookiemonster on June 18, 2025, 06:30:21 PMThe screenshot with the Live view with most blue lines. Those are all OUT flows from 192.168.10.55 and others. They suggest going out to WAN, that's expected. You haven't included or I can't see more than that i.e. destination. However, they seem to be redirected. I was not expecting that. Why would the flow OUT be redirected? Do you have other NAT or outbound rules perhaps?
And regarding this last question, as I indicated in the first answer, there are two NAT rules created; I have no other rules. I've also disabled the DNS Blacklist, but I don't think this affects the problem I'm having. I'm attaching another screenshot of the live view, in case you can glean anything. Thank you.