Messages

[-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).
 

[105)]

You mistyped either the port you wanted to open (according to the rules, 27105), or the one your tried to contact, which, according to the firewall log, is 27015.

Since ZFS is a COW filesystem, it will usually be consistent, unlike UFS. But redundancy would probably better be left to the "real" storage layer.

You need the pipe first as in the howto, with the total available WAN bandwidth - it must have a scheduler type of "Weighted Fair Queue".

Then you need two queues for LAN and GUEST referencing that same pipe and weights to define the relative priorities as in the howto.

Last, you define the LAN and GUEST rules referencing the resprective queue. They both use the WAN interface, apart from that they have for the LAN rule:

interface = WAN
proto = ip
source = any
src-port = any
destination = 192.168.x.0/24 (whatever your LAN network has)
dst-port = any
direction = in
target = LAN-Queue

and for the GUEST rule:

interface = WAN
proto = ip
source = any
src-port = any
destination = 192.168.y.0/24 (whatever your GUEST network uses)
dst-port = any
direction = in
target = GUEST-Queue

You probably used the LAN and GUEST interfaces in the rules, that will not work.

Things to check: https://forum.opnsense.org/index.php?topic=42985.0, point 10.

What exactly does not work? Do the clients receive IP adresses via DHCP? Do they receive a default gateway? Can you ping the gateway? Where does a traceroute 8.8.8.8 end?

For the first LAN, there is a default "allow any" firewall rule. Depending on how / when you created the VLAN on your machine, that will not have this rule per default, if you have not replicated it.

Try this setup for IPv6.