Messages

You do not have to set an upstream DNS server for Unbound at all, because it can resolve on its own.

Try leaving the DNS servers empty in System:Settings:General and uncheck both "DNS server options" on that page.

If both firewalls can ping one another (BTW: on which address? The tunnel IP or their LAN IP?), then it seems obvious that your firewall rules created in step 6 of the official instructions are wrong. You should not have to use NAT on the Wireguard interfaces. Just follow the docs.
 

No, Patrick, just no. That device is not at all transparent, which is a huge difference.

Should I add a new point "About Home Network Guy's and other's youtube videos and why to avoid transparent bridges in general" to the READ ME FIRST article? Up to this point, I avoided changing the order because of the many references, but this one should probably be way up.

Or you go cheap (as I did) and switch to Intel 12th-14th gen. Those LGA1700 boards are still available and many use DDR4. New AM4 boards are unobtanium. And having had the experience of a 400€ board passing out after less than three years, I am not too keen on trying a used/refurbished one.

I never had failing RAM until now, only mainboards. I think it is getting worse with the voltage regulation now on the mainboards instead of the PSU and the obscene power draw of modern CPUs.

Yup, sometimes, this hits earlier than one thinks... Yesterday, I found my Proxmox server getting unstable until I increased Vcore by 100mV - obviously a VRM is on its way out.

Replacing it by a current platform means getting 128 GByte of DDR5 instead of DDR4, which costs ~1500€ for any non-abysmal speed at the time of writing, so the cost for mainboard, CPU, RAM and cooler comes to ~2500€

It is an AM4 system with lots of storage, so I need a decent chipset for many PCIe lanes - X570 is the only one that fits. The only specimens capable of handling my needs and still being available are at least 400€ and are backordered.

At that price, it is easier to keep the existing RAM and order an Intel LGA1700 based board, CPU and cooler for the same cost.

IDK, because "AI" can mean anything, so, probably, yes, it may prevent you from running "anything", too.

BTW: Do you still love your router?

IMHO, using a router on top of another is a bad thing (tm) in the first place. Having one of these routers do unspecified magic "might" make it even harder. Once you throw an unknown variable in the mix (i.e. your first router), you will not get much helpful advice with the other (OpnSense).
Even less so when you use a non-typical setup like a transparent bridge.

The problem is / was probably present before. If you use DNS names for wireguard peers, then the daemon will only resolve them once on start and never recognizes if the peer's IP changes. There is a cron job "Renew DNS for Wireguard on stale connections" which will restart Wireguard. You can run that job every 5 minutes and it will probably fix the DNS resolution problem during startup, too (at least after 5 minutes).

This has been reported over an over, so now I appended it as point 30 here: https://forum.opnsense.org/index.php?topic=42985.0

Firewall aliases are meant to be used with pf rules. pf acts on IPs and subnets. So what should a DNS "domain" mean in that context?

It is not even a specific hostname within a domain, which could at least be resolved to an IP (or a set of IPs).

You can use domains in DNSBL lists to block DNS resolution of specific names, but that is another concept that has nothing to do with firewall rules (and aliases).

Wenn Du individuelle Interface-Regeln brauchst, dann musst Du sie entweder im Interface oder in den Floating Rules machen.

Die Priorität ist ja in der offiziellen Dokumentation erläutert. Floating Regeln sind ganz vorne, dann kommen Interface Gruppen, dann Interfaces.

Entsprechend muss man die Regeln auch positionieren. In den Floating Rules kommt das, was mehr oder weniger für alle gilt - übrigens kann man dort auch Interface Gruppen verwenden.

Wenn Dir das zu unübersichtlich ist, kannst Du auch alle Regeln in den Floating Rules belassen, dann übersiehst Du nichts.

I have to access the WAN net because I'm behind another NAT unfortunately. Should The Admin Aliases to Firewall be placed in the Floating, or are they best left specifically for the Admin VLAN rules?

If they are really VLAN-specific, they do not need to be in the floating rules. As I said, I put everything there that I need to have for many VLANs or things that must override inbound NAT rules. Those with "pass" rules are evaluated before any interface-specific rules, so they must be done in the floating rules. As an example, when you want geoblocking on WAN, you may have to do that in the floating rules, because otherwise, your forwarded ports will not be protected.

IDK, but I doubt it. Did you install the microcode updates?

ASPM is your smallest problem. That is neither the first nor the only thing in point 23. You need to use the os-microcode-intel plugin and the tuneables from the linked posting in point 23 with your Alder Lake CPU.

You also do not need to add anything to any files, just use the web UI to enter the tuneables and reboot afterwards.

There are lots of problems with those rules.

First, you have to ask yourself what you want to achieve by separating out a guest VLAN.

Usually, this is used to protect your "valuable assets" in your main LAN from anyone who may just use your internet connection. In order to do this, you should have rules in place to protect your LAN from the guest VLAN.

Your rules show an attempt to further regulate the traffic originating from your guest network. This is debatable at best and your rules do not provide that, either. The way you currently do it would keep most guests from browsing anything at all, because current browsers use DoT on port 853, which you do not allow. On the other hand, because you allow port 443, anybody could use DNS via DoH, so you do not block external DNS requests effectively.

Before I go on to show what is wrong with your rules, I tell you what mine are:

1. I have floating rules to allow traffic that I need to allow basic network functions for all local networks - that includes the guest VLAN.
Those would be DNS (53/UDP) and NTP (123/UDP). I also allow access to specific resources there, like a printer on my IoT VLAN.

2. In the VLAN-specific rules, I have one rule to allow any to any, like the default LAN rule. This will allow guest clients to access anything on the internet. Why? Frankly, because you cannot effectively regulate traffic, there anyway. The only thing you have to do there is a block rule to an alias "RFC1918", which has to be placed before the "allow any" rule, in order to keep guests from accessing your local networks.

That is about it.


Now for your rules:

- Allow DHCP Port 67/UDP: This rule is unneccesary AFAIR, because that is allowed in the "Automatically generated rules" already. Delete it.
- Allow DNS Port 53: Only needed with UDP and should beplace in floating rules for all local network interfaces. Move it there.
- Block External DNS Port 53: Why would you? These days, browsers mostly do DoT or DoH, anyway. As long as you do not block that, either, this is fruitless. If you want to block it: This is very complex and frankly, at your current level, you would not succeed in doing it. Leave it be, delete the rule.
- Block access to firewall management: Since this rule comes before the next rules, it would block anything after it, like "Allow NTP", so it is misplaced. If at all, you should move it further down in the list. Then again, it is not needed at all, because there already is an implicit "block all" rule at the end of the list. Rule of thumb: order matters! Delete it.
- Block access to private/internal networks. Yes, keep it.
- Allow Inbound Connection Ports 80-443: Problem here is, you allow not only ports 80 and 443 ofr HTTP and HTTPS, but anything in between, including NTP (123) and many others. If you really want ports 80 and 443 only, you need either two rules or a "Port" alias for web traffic consisting of port 80 and 443. I would say, delete the rule and replace it by an "allow any" rule.
- Allow Outbound traffic Port 443-80: You never need to have a firewall rule for outbound directions (with only a few exceptions), even less so for an existing inbound rule. The responses to allowed traffic are always allowed. Delete it.
- Allow NTP Port 123: Move the rule to floating.
 

As long as Kea DHCPv6 is not active for an interface, it is neither shown nor selectable in the interface filter of the "leases" display.

SLAAC is never shown at all, because those are no leases - the clients decide for themselves, which suffix they use. You would see SLAAC assigments in the NDP table only. If you ever had DHCPv6 leases, they will show up for a long time after they have been handed out, though.

Why wouldn't they? They want (some actually need) the party to go on.