Messages

And how would you actually go about that?

I often pointed to the obvious fact that along with great flexibility and functionality, "easy going" for end-users goes out the window. I accept the fact that OpnSense is an expert tool.

As a simple example, take the fact that ISC DHCPv4 is a part of the initial rant (while that did not even include the firewal setup or IPv6). And at this point, we have no less than three (!) DHCP daemons, namely ISC, Kea and DNSmasq. Which would you choose if the process was indeed more streamlined?

The only approach I could imagine was a set of some kind of "helpers for common tasks", but these would have to be on top of the fine-grained settings menus. Also, they would be prone to break pre-existent settings, just because they have to be limited to default settings (which ones, BTW?) instead of the wide variety of potential settings.

I can already picture upcoming forum discussions about how the default X of helper Y "does not suit my needs, can we change it or at least make it selectable?".

[any]

In practice, this makes little sense, because, unless you explicitely disallow any traffic, you will not be safe against exfiltration anyway:

Consider any other type of traffic being allowed, like HTTPS - since you cannot break up that encrypted connection, you know jack about what is in it. And this is even true for outbound connections. Of course, any IP connection can be used in any direction regardless of the direction it was initially started in.

The only reason why this is psychologically threathening is that because ICMP ping is usually not a real connection, it looks somewhat sneaky.

You can specify a "host" type firewall alias in the source of the NAT rule.

BTW: https://docs.opnsense.org/manual/how-tos/ipinfo_geo_ip.html is way more detailed and accurate than Maxmind. You may have to enlarge the "Firewall Maximum Table Entries" to make it work.

/var/log/filter/latest.log

I put all applications that are reachable from outside, regardless if they are containerized or VMS, in a DMZ. For docker containers, I have one docker host for internal services (on LAN) and one for web services (in DMZ).

Caddy does not really help if your apps are prone to authentication circumvention attacks, SQL injections or other attacks.

Take a full web UI like Proxmox as an example - I would not expose that with a "dumb" reverse proxy only, rather use a VPN or limit access to API endpoints. It would be similar for the Portainer UI.

By putting such applications in a separate network zone, potential attacks are mostly limited to spreading outside that zone.

If you mean the "let out anything from firewall host itself" rule - it is "last match", so if you block traffic before it, it will never fire.

Take a look at this, point 24.

Keep in mind that you then need to explicitely allow anything that is needed to build up your ISP connection, probably including DHCP.

[-6]

The gateway IP will most certainly not be the culprit, as this is very common. Also, the destination IP can and almost guaranteed will be the routable IPv6 of your client, so instead of "destination" = 192.168.x.0/24 you would use whatever destination IPv6 network(s) you have.

Also, instead of using subnet addresses, you can use the "interface 2" instead like so:

You cannot view this attachment.

This way, you can leave the destination "any".

I tried it via:

#iperf3 -6 -c paris.bbr.iperf.bytel.fr -p 9207 -R -i10
Connecting to host paris.bbr.iperf.bytel.fr, port 9207
Reverse mode, remote host paris.bbr.iperf.bytel.fr is sending
[  5] local 2001:a61:524:xxxx:e5db:5a2d:dbaf:xxxx port 47370 connected to 2001:864:f003::2:1 port 9207
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-10.01  sec   113 MBytes  94.7 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.06  sec   118 MBytes  98.3 Mbits/sec  3513             sender
[  5]   0.00-10.01  sec   113 MBytes  94.7 Mbits/sec                  receiver

As you can see, it works just fine.

Is the netmask and gateway that the DHCP service hands out correct? Or is it /24?

OMG, I need "Weigthed Fair Queue" scheduler type in the pipe... then it works. I copied from another pipe with FQ-Codel...

And it works with netmasks as destinations instead of src ports as well.

[9205]

Then, two rules to select ports 9207 and 9203:

You cannot view this attachment.
You cannot view this attachment.

I also used the "in" direction from the WAN, as to denote downstream.

Then, I tested with:

VM1: iperf3 -4 -c paris.bbr.iperf.bytel.fr -p 9207 -R -i10
VM2: iperf3 -4 -c paris.bbr.iperf.bytel.fr -p 9207 -R -i10

I got:

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.04  sec  65.2 MBytes  54.5 Mbits/sec  728             sender
[  5]   0.00-10.00  sec  58.2 MBytes  48.9 Mbits/sec                  receiver

and

#iperf3 -4 -c paris.bbr.iperf.bytel.fr -p 9207 -R -i10
Connecting to host paris.bbr.iperf.bytel.fr, port 9207
Reverse mode, remote host paris.bbr.iperf.bytel.fr is sending
[  5] local 192.168.10.3 port 58524 connected to 5.51.3.41 port 9207
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-10.00  sec  58.2 MBytes  48.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.04  sec  65.2 MBytes  54.5 Mbits/sec  728             sender
[  5]   0.00-10.00  sec  58.2 MBytes  48.9 Mbits/sec                  receiver

which is approximately the same.


The "in" direction is correct, because when I test with

iperf3 -4 -c paris.bbr.iperf.bytel.fr -p 9207 -i10 (i.e. without "-R")

I get my full upstream speed on both VMs, i.e. I do not use the rules, apparently.

Also, with:

iperf3 -4 -c paris.bbr.iperf.bytel.fr -p 9205 -i10

I get the unlimited downstream speed, so the rules obviously apply to select a queue. Yet, the weights do get get applied.

WTH?

[Note: The FQ-Codel cheduler was the problem, you have to use "Weighted Fair Queue" to make it work.]

I do not get it. I created one pipe which has less than my real downstream bandwidth:

You cannot view this attachment.

Note: The FQ-Codel cheduler was the problem, you have to use "Weighted Fair Queue" to make it work.

Two queues with weights 1 and 99:

You cannot view this attachment.
You cannot view this attachment.

Die Anleitung ist inzwischen obsolet, es gilt die aktuelle Dokumentation. Das steht auch zu im dritten Satz im ersten Post!

If that is true, @Seimus, which is unexpected to me, but seems true, as far as I now have tested, then there is a problem:

It does not work for applications (= ports), either. That means, I just tested that the whole example in the documentation does not work as expected.

Did I get you right? You seem to imply that not all inputs in the rules can be used as selectors, in this case the destination IPs, but the source ports (i.e. the application) can. The latter is what the documentation describes. But I just tested with two VMs with iperf3 against different ports (9203 and 9207) on paris.bbr.iperf.bytel.fr. I used those as src-ports in two rules to select two pipes to queues with weights of 1 and 9.

Then, I let both tests run at the same time. They showed the same speeds at both VMs.

Thus, to me, it seems even worse than you describe. On the other hand, there are a lot of new parameters that become visible only when you enable advanced settings that may or may not be the culprit. In the rules settings, there are even "interface 2" settings now which suggest that instead of a netmask, you can simply specify the destination interface for a rule and also a "direction" parameter. I tried the interface 2 parameters, and they did not work, either.

I do not understand the question, because it can be read two ways:

1. It is a specific client you know which you want to block. In that case, create a floating block rule for the client's MAC in order to block it also if it uses IPv6 pricavy extension, where you cannot block based on IP.

2. You want to block any unknown client - in that case, you would have to create a list of all known MACs of any "authorized" client and allow only those.

That being said, you have to know that any client can and sometimes, for privacy reasons, will, use random MACs - some Android and iPhone smartphones do it per default. You can also fake MACs of existing "autorized" devices. Thus, any kind of MAC-based authorization scheme comes to a natural limit.

If the devices are connected via a hotspot, you can protect the network by using a strong WiFi password in the first place. Some hotspots also allow whitelists for MACs, BTW.

The only "secure" way of protecting your internal network for cabled connections is 802.1x with client certificates - but not all devices can do that and you need 802.1x-capable switches and an LDAP database (like FreeRADIUS).