Messages

Kannst du mal Screenshots deiner NAT Regeln posten? Bin der Meinung das sollte gehen, beim DNAT ist es eigentlihc nicht notwendig die Sourceadresse und -port anzufassen, und bin mir auch relativ sicher das in der Vergangenheit schon häufiger so mit OPNsense umgesetzt zu haben - hab allerdings gerade kein Testsetup zur Verfügung um es zu verifizieren...

It should be there already, check out Interfaces->Overview, it should display the link-local address. The address is deterministic, it's based on the interface's MAC address (EUI-64).

Regarding the error message i think the 2nd "warning" box from the docs should be the fix you're after: https://docs.opnsense.org/manual/dynamic_routing.html

[unsure]

Isn't this blowing a bit out of proportion?  :)

If I understand correctly, the OP simply suggested to make the wording in the release notes a bit more firm, i.e. along the lines of: "If a realtek NIC is used, install the driver before doing any update".

At least to me this doesn't seem like some unreasonable demand or blaming of the developers, but rather just a friendly suggestion to avoid more threads like this one. :)

I think everybody understood that, but then the next guy comes around and goes "You idiots suggested installing the package and now my sh** went down for a whole work day. I uninstalled the package and now it works. Go change the wording!"

The wording is, in my opinion, pretty spot on. It more or less says YMMV, and it even says that if you are unsure, you should probably go with the package.
OP, i think we've all been in your shoes. Even if you've done nothing wrong, things go bad and you get the blame (or at least feel the stress), and that's frustrating as hell. But sadly, this can happen anywhere. Print Nightmare patches, anybody?
You can take this instance as a lesson learned. There are a couple of things you can do next time to avoid problems (though nothing is 100% safe). HA setup allows you to patch with a week inbetween, testing in a lab for a longer period would've helped spot the issue aswell. Buying official hardware and a business subscription makes failure less likely because the vendor does the testing for you. Or just leave things as they are and accept the risk, but you save a lot of time and money.
At the end of the day "shit happens". If you did your due diligence, don't let hindsight bias eat you up. You were there to fix the problem, that's what counts.

@Fright is it strictly frontend work that you're doing to achieve this?

I'm wondering because, since there are clearly good arguments both for and against change to the product in this regard, wouldn't it also be an option to make a browser extension that handles it? That way it's decoupled from core development, and there's room for creativity.
One user might use categories strictly 1:1, in which case a colorization like mine could work really well. Another will be happy with your solution, and a third will want to keep things as they are. Putting all the different options into Core and making it configurable is probably too much. Choosing one option over the other will only satisfy a portion of the users. A plugin with different modes of operation can serve everyone, can be maintained independently by the community and the devs won't have to bother with compatibility at all

If you feel like that's a viable option HMU with a PN, i want to contribute :)

iperf tests to and from the firewall are not representative.
What counts is the speed at which the firewall can forward traffic. So you should always be testing like this:

PC 1 (iperf Client) -> Firewall -> PC 2 (iperf Server)

If i understood your previous postings correctly, this performs fine?

You're absolutely right, not displaying them under each category would add even more layers of indirection between what the eye sees and what the packetfilter actually does - they should definitely be displayed under every category.
I like your solution visually, and in the end it's up to the user how they choose to use categories. Maybe it's best to display a "here be dragons" warning when the view is opened for the first time or so?

There's another thing that springs to mind though; your representation mixes up the rule order visually doesn't it? Because it first "sorts" by category and then by actual rule order. That's something that would probably need some more thought aswell

Are you doing iperf tests to/from OPNsense?

This looks beautiful :)

Agreed, BUT it might cause confusion because a single rule can appear more than once.

The fact that categories aren't a 1:1 relation (didn't know that before :-D) makes it somewhat difficult to visualize them in an intuitive way, the coloured dots are accounting for that fact, the other solutions aren't.

Guess this is a never-ending dilemma?

Looks good. Since you're already redirecting all DNS requests to your box, another block rule wouldn't have any effect.
Also why are there two allow-all rules below your last "Deny all traffic" rule? They will probably never match...

Reasons why you might still be able to surf the web even if you disable the rule

• Cache
• Device falling back to Cellular internet
• DoH

What is your goal with redirecting/blocking DNS? You mention it's "for security reasons", but without concrete ideas/plans on what exactly you're going to do with the DNS traffic that you're trying to control, you will most likely end up getting no additional security, and you may even lose some. There are so many things that can go wrong, like accidentally exposing your firewall's Webinterface to the public internet because you don't fully understand what you're doing.
So, ask yourself this first: What security measures do i want to implement in my own DNS resolver that justify the effort of taking control over DNS traffic by means of redirection/blocking in the first place? If you have no answer to that question, it's not worth it.

By all means, i don't want to discourage you here. If you're trying to learn and improve your skills, that's awesome! But maybe, try to enhance your understanding of the different protocol layers and what happens where first. The OSI and TCP/IP reference models are a good starting point. There's also tons of free training materials on Youtube and in other places. Once you're getting more comfortable with your general knowledge of network technology, you'll find it much easier to understand what your firewall and NAT rules actually do, and how the different pieces play together to actually have an impact on your overall security.

On the other hand, if all you want to do is let devices on your wifi surf, just put in an allow-all rule and call it a day ;-)

Thanks for the reply,I got it working now by set ports on destination.
I also added these rules on LAN.

Do you actually want to allow traffic from the internet towards your firewall on these ports, or is your goal just to let LAN devices out?
If it's the latter, then you should remove the rules from your WAN interface, they're not doing what you think they're doing.

One more question:Should I create e.g. for the HTTPS traffic,2 rules,one with Direction "In" and one with Direction "Out" so as I do both Ingress(incoming) and Egress(outcoming) filtering?
I read that since Opnsense is a stateful firewall,you can only write one rule and it applies to both directions.Is this correct?

This is correct. All you need is a rule from LAN to (in this case) any and destination ports 80 and 443 to allow LAN devices to browse the internet.
In a default setup similar to consumer-grade routers, you will have no rules at all on the WAN interface.

Also, when I disable the Allow DNS rule,I can visit any site,so DNS Allow rule seems of no use.What could be the issue?
Thanks

Please post a screenshot of all rules on all interfaces, plus some additonal info on your DHCP and DNS (Unbound) settings. There could be many reasons

You've mixed up Source and Destination ports. You'll probably want source port "any" and destination ports 53/80/443

That would cover the case of traffic coming from the outside to these ports to be allowed. Are you really sure that's what you want? It would expose your OPNsense webinterface to the internet, not exactly best practice.

In OPNsense you always put rules on the interface where traffic comes in. So if you want to allow traffic from your LAN to the outside, put the rules on the LAN interface instead.

Referring to what bimbar wrote, what do u guys think of this:

Instead of having the small dots, maybe the category colors could instead be used as background color shades in their respective rows? I haven't looked at any of the code yet, but i (perhaps naively) assume that's not a big change, with very little additional risk of maintenance required down the road.
This might already give a big boost to visibility, don't u think?

/e: rough idea just quickly F12ed together. Please ignore that i messed up source/destination settings in some my example rules :-D


/e: and here's the same with some readability improvements around the first icons just to demonstrate how this problem from the 1st screenshot could be circumvented:


If there's enough positive feedback, and perhaps a hint from the core team whether they would be willing to pull such a change in, i'll try to craft a PR :)

Imho it's perfectly fine to run such as setup if it serves your needs. It can even have some pros to it.

Pro:

• The ISP-provided router can shoulder other duties like being a DECT station or providing an analog phone jack. Yes, there are people who use their landline number(s) with regular phones.
• Whenever your ISP has issues, you can skip all the "it's not our fault, it's your setup" hotline nonsense by plugging yourself directly into the LAN port of their plastic box. They'll try to weasel themselves out of all issues with any excuse they can find. I was once asked which color my cables were. Yeah, it's that bad especially with consumer lines.

Cons

• You're bound to the performance limitations of your ISP router (bandwidth, amount of connections and whatever else you may think of). Though in practice, at least for me, this has never been an issue.
• More power consumption. Not that i would take that argument seriously from somebody playing around with prosumer gear at home, but it is an argument.
• UPnP is YMMV. It is technically possible to daisy-chain it, but it can be a PITA to get it to work
• DynDNS is slightly more difficult to set up.

I personally think that, as long as the provider router is a halfway decent product (e.g. FritzBox), and your provider gives you more than a single /64 IPv6 prefix, it's almost always possible to work around the limitations by just relying more on IPv6 and avoiding NAT altogether. Heck, the providers with bad gear AND bad IPv6 politics are usually also the ones giving you CGNAT, which has all the same issues as your double-NAT anyway, so your best bet is to switch providers if you can. Last resort, rent a VPS and use a VPN to get access to non-castrated IP(v4 and v6)

If the devices ahead of the traffic are natting multiple layers this would create a reduced MTU size which many times create application level issues. one of which is routing. it's kind of odd to route traffic from 192.168.1.1 to 10.1.1.1.

The only way is to remove the NAT from the OPNSense.

I fail to follow here, in what way does NAT have any effect on MTU?
The suggestion to remove the NAT from OPNsense and add static routes to your ISP router instead is actually pretty good though, never thought about that. Less complexity is always nice :)

Depends on your requirements really. If you need the throughput and fault/downtime is no biggie, go with 10 Gbit/s. Though i'd test if your hardware is actually capable of maxing out the bandwidth.

Otherwise, go with the 4x 1 Gbit option but put all 4 Ports into a LAGG and put all VLANs on there. Poof, you just added some redundancy at least against failing ports and cables. And if you ever want to re-do your wires you can change them 1-by-1 without downtime.

/e: Another thing to consider is hardware support. Intel generally works really well and is almost always a safe bet. I have no idea about Mellanox, somebody else might chime in on that.