Messages

IDK. If you feel that is a bug, create a bug request on Github.

It does not do that per default. Identity association is the new version of the former "Track Interface". Thus, it depends on how many bits you have in your parent interface's prefix delegation size. AFAIK, you need a shorter than /64 prefix in order to be able to supply a full /64 prefix to any interface.

Maybe your ISP does not give you a /56 (which is pretty much the default) or you did not request as much on your WAN. How many bits is your IA_PD prefix?

Perhaps you should take a look at the official docs: https://docs.opnsense.org/manual/ipv6.html

Or my IPv6 guide (which is still based on track interface): https://forum.opnsense.org/index.php?topic=45822.0

I know. I edited in parallel and now augmented my post.

Sigh. I wish people would actually say if they use Proxmox underneath anything before asking seemingly unrelated questions...

Didn't I write something to that extent? Ah, yes, here, point 16.

While we are at this, also take a look at points 10, 22 and 27.

Also: How exactly did you set up your OpnSense under PVE? Virtio or passthru NICs? Did you use multiqueue on the PVE NICs in the VM definition?

You now answered that - in case you use Realtek physical NICs, you inherit all the problems in point 6 of the READ ME FIRST article.

Maybe it is time to also look at: https://forum.opnsense.org/index.php?topic=44159.0, with a caveat that the "hardware checksumming" on virtio interfaces may be fixed already and can be left enabled. If you disabled it before, maybe that explains why the VM became slower.

Wenn diese Seite TLS verwendet - im Wesentlichen: nein. Du müsstest Traffic Inspection machen, dazu benötigst Du eine TLS-Terminierung in OpnSense. Das geht zwar mit Squid, aber es müssen dazu Zertifikate on-the-fly erzeugt werden von einer eigenen CA, die in Deinem Browser als trusted eingetragen wird.

Siehe https://forum.opnsense.org/index.php?topic=42985.0, Punkt 12.

Yes, I was only talking about x64 as VM, which seems like the obvious choice for self-hosting.

I know you can use a Raspberry, yet I found it to have a high power envelope for what it can do and also, it cannot handle virtualisation for many different applications. The main reason that ARM image is supported seems to be that the UDM line of products is ARM64 as well.

The UNC can even be used as a package under OpnSense itself, it is available from Mimugmail's repository.

That AVX requirement on x64 platforms is mostly irrelevant anyway, because even an N100 has AVX2. Any fairly modern x64 CPU should have it.

It remains difficult and requires skills and experience. That's why I am not dreading to be replaced by AI.

Wise words, Patrick - and you are right.
 

As I said, there are other services that need to be accessible, logging is just one example that is obvious that I can mention. When you think more than a second about the application at hand, you will notice how it cannot be done with inside-out-access only... ;-)
Of course all of those services are themselves not on the LAN, but in separate security zones.

What I want to point out is that even with very strict security requirements, there is no such thing as black and white. I remember dicussing a full fledged firewall setup of this kind back in 1997:

You cannot view this attachment.

Where each of the three firewalls was supposed to be a dual-homed gateway with two routers and an intermediate appication-level gateway:

You cannot view this attachment.

Guess what? This was severly downscaled in reality...

What you define as a DMZ is in reality a "dirty DMZ" with actual devices between two routers. As such, it only benefits from the first router, whereas the LAN is behind both routers.

As explained, two routers of the same kind only bring more complexity, not more security and if you limit yourself to just one firewall, then it is the responsibility of that to separate the DMZ from the LAN.

There are many slight variations on this theme, so you have to explicitely say what you mean - that is what I referred to in my response.

Besides, with any kind of DMZ, you will find that more often than not, this sentence: "the DMZ would never under any circumstances be able to reach the internal net" is not true, either. Having build such setups for e.g. banks, I can tell you that e.g. logging must be able to pass to inside servers, among other things.

I saw that in the past when I over-optimized the shaper by not leaving enough headroom in the pipes' bandwidths in pursuit of maximum bandwidth. You cannot have your cake and still eat it.

Interesting tool, although I get a B for video calls each time and I do not understand why.

P.S.: Waveform still works for me.

Da könnte ich zwar auch helfen, werde aber abermals nicht können - letztes Mal Theater, diesmal Besuch... viel Spaß Euch!

Yes, correct:

The UniFi Controller has the following needs and issues :
- AVX/AVX2 compatible CPU
This puts older Intel NUCs and Raspberry Pi models in a weird corner where you need to do really weird things to keep it all running !!
- Linux OS
Which is not an issue.
But in certain situations you need to install old unsupported libraries that are no longer available in newer distors and thus also no longer patched/maintained and have open CVE's and that sucks!
- Java such as OpenJDK.
Now the crap starts...
- Mongo Database
This is linked to the AVX/AVX2 story above and gets even weirder :
Certain versions of the UniFi Controller are linked to certain versions of MongoDB that you need.

So the more we move into the future and use newer UniFi hardware the more chance you have got to run into the AVX/AVX2 issue !!

The AVX requirement is there, 100%. However, with Unifi OS Server, you do not need to install any dependencies yourself. That is the beauty of UOS when compared against UNC - it mirrors what Ubiquiti does in their own devices, like UDM, by running every module under podman internally.

Apart from that, even UNC with all of its dependencies can be maintained very easily, when you use Glenn R's easy install scripts (I use those scripts for UOS, too).

As for Protect, yes, there are projects to steal the protect container and run them on a similar platform, but they are limited to arm64, because Ubiquiti does not have an x64-based platform running protect.

I followed Tomasz'sYT video series for a while now, and noted early that I would like to see OpnSense on it, instead of OpenWRT - this seemed infeasible at the time...

However, apart from the entertainment and enthusiast aspect of this effort, which in itself deserves praise, I see three problems:

1. The box only has 2x SFP+ ports and 3x 1 GbE ones. I know why it was infeasible to do 2.5 GbE, however, I think that is something left to be desired.

2. The price is now 600€ (the finished product will even be more, AFAIU), which is more than I would pay for an x64-based appliance with 3x 2.5 GbE and 2x SFP+. AFAIK, the routing speed is 10 Gbps as well for those.

3. As it appears, there are some legal obstacles with conflicts of the GPL v2 and commercially licensed code, which Tomasz has acknowledged in a pinned comment under his video and now seeks legal counsel as to if and how it will be possible to do it they way he intended.

There are two parts of firewall rules (well, actually, it's three):

1. On WAN, you need to allow "in" access on the UDP port that your wireguard instance is running on.
2. On the Wireguard group, you need to create "in" rules to access any of the LAN resources you want external clients to have access to. For starters, you could "allow from any to any".
3. In the wireguard peer, you need to set the "allowed ip" range to those of the wireguard clients that you want to pass. You could use 0.0.0.0/0 here.

All of this is explained for both site-to-site and roadwarrior setups in the official docs.



The order of checks would be outside -> in, so first make sure that the wireguard instance is really contacted by your clients.

That means:

a. the client must be able to connect to your external WAN IP, probably by using its dynamic DNS alias.
b. the client must be allowed to use the wireguard instance's external UDP port.
c. the secrets must be correct, otherwise the packets will be silently discarded.

You can check that via the Wireguard status. It must be green, having a "handshake age" and both sent and received traffic.

The second step would be to verify access from your client to your internal networks.

You can enable firewall logging for the default block rules and watch if there are blocks.