Messages

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.

I got hooked by their APs many years ago, so adding their switches is a no-brainer. The management is more "prosumer" than what Cisco or Mikrotik offer, but quite effective and easy to manage. Of course it depends on if you already have one of their router-type appliances or can use all of that on a VM.

Matter-of-fact, the network controller is also available on iOS and Android as standalone apps, because apart from the guest portal, you do not need it running 24/7. I never tried those, because IMHO, you need a bit of screen real estate to easily use the interface.

My main gripes about them are:

1. The dream boxes are crap.
2. Unify protect is only available on their hardware (dream boxes and NVRs) - they stopped the VM versions.
3. In the last 2 years, they started way too many variants of their products, leading to a confusing portfolio and, with the many new offerings, degraded support for any of them.

What would be the difference between WAN and pppoe0?

One is just an assigned name for the underlying PPPoE interface - unless you made the mistake of naming the physical NIC (or VLAN) as WAN.

That is the problem with many of those videos: There is no such thing as a step-by-step tutorial, because each situation is different, like your example clearly shows.

You have to understand how things work, otherwise you will be stuck at each crossing.

With a PPPoE connection, you can have one of these topologies on the WAN side:

1. ISP ONT/modem -> physical NIC ("ONT") -> PPPoE interface ("WAN")
2. ISP ONT/modem -> physical NIC ("ONT") -> VLAN ("VLANXX") -> PPPoE interface ("WAN")

With OpnSense, you have either two or three logical interfaces. Name them according to the scheme above. Firewall rules should always be applied to "WAN", which usually is the same thing as "pppoe0". You do not even need explicit names for ONT and VLANXX, unless you want to have direct ONT/modem access. You also do not need firewall rules for "ONT" either, as per default, everything is blocked.

You obviously use it differently, which causes your confusion:

ISP ONT/modem -> physical NIC ("WAN") -> PPPoE interface ("???")

I have the USW-Pro-HD-24-PoE, which offers more ports, 4xSFP+, 2*10 GbE, PoE. I like the centralised management for Unifi Gear. Their routers are crap, but you can have the network management on a VM.

There are smaller offerings available as well, with and without PoE:

https://geizhals.de/?cat=switchgi&xf=13283_2%7E16696_8%7E2270_Ubiquiti&sort=p#productlist

[one]

@150d: What you characterize as a DMZ is actually something different, namely a double-firewall setup. Thus, you mix up two questions here.

I would argue that a "real" DMZ, in the notion of having some (potentually exposed) devices on a separate network in order to keep them out of your internal LAN makes complete sense. By doing that, an attack could not proliferate to your LAN. This would only presume one leg (either physical NIC or VLAN) of one OpnSense to be separated.

What you propose instead has two disadvantages the way you decribe it:

1. This is a router-behind-router scenario with double NAT and all of its complications, e.g. port-forwarding must be configured on both firewalls. I would avoid it for the average setup.

2. It does not even have the benefit that some enterprise setups would try to reach by doing such a thing nonetheless: By using two cascaded firewalls of different kind, you could potentially harden your infrastructure against attacks to known vulnerabilities of one or the other. This is not the case with two cascaded firewalls of the same kind.