Messages

[BUT!]

Hi,

meanwhile I used the Shaper-rules and it is working so far.

I re-checked the Shaper documentation and the provided examples. I re-created my rules (and re-check pipes and queue settings).
Now the setup is as follows:
Pipes (low limits for testing purposes)

• Global Upload --> 70Mb/s
• Global Download --> 80MB/s

Queues

• VOIP Upload, weight 80 --> Global Upload Pipe
• VOIP Download, weight 80 --> Global Download Pipe
• LAN Uplaod, weight 15 --> Global Upload Pipe
• LAN Download, weight 15 --> Global Download Pipe

Rules (192.168.9.0/24 is the remote VPN LAN while 192.168.1.0/24, 192.168.30.0/24 are the local ones)

• Seq 3, WireguardGroup, SRC 192.168.9.0/24, DST any, IN --> LAN Download Queue
• Seq 4, WireguardGroup, SRC any, DST 192.168.9.0/24, OUT --> LAN Upload Queue
• Seq 10, WAN, SRC 192.168.30.0/24, DST any, OUT --> VOIP Upload Queue
• Seq 11, WAN, SRC 192.168.1.0/24, DST any, OUT --> LAN Upload Queue
• Seq 20, WAN, SRC any, DST 192.168.30.0/24, IN --> VOIP Download Queue
• Seq 21, WAN, SRC any, DST 192.168.1.0/24, IN --> LAN Download Queue

Now I can see the limits working fine on traffic between LAN and Internet, in both directions.

BUT!
Traffic to/ from Wireguard VPN is not limited at all. So I guess the weighting is not taken into account here. Which might interfere with the VOIP traffic beeing capped by a large VPN traffic...

Before going further (and trying to start with the FW rules) I need to know why the Wireguad traffic is not limited? Even when the interface (wireguardGroup) is wrong it should be limited by the default LAN rule, shouldn't it?

Confused,

/KNEBB

[Line Download]

Hi,

thanks for your explanations and your patience! Very kind!

I am really trying to understand. And I think I got it in theory now.

So I have currently setup in the following way:

Line Download

• Min: 750Mbit/s
• Max: 1000Mbit/s

Line Upload:

• Min: 375Mbit/s
• Max: 500Mbit/s

Configured Pipes with the WFQ scheduler and CoDel activated:

• VoIP Upload -> 10Mbit/s
• VoIP Download -> 10Mbit/s
• LAN Upload (min) -> 365Mbit/s (the min available bandwidth reduced by the 10Mbit/s for VoIP)
• LAN Upload (max) -> 500Mbit/s
• WAN Download (min) -> 750Mbit/s
• WAN Download (max) -> 1000Mbit/s

No rules in Shaper

A rule on bottom of the WAN interface as catch-all:

• Action: Allow
• Interface: WAN (which is NATed to pulic IP)
• Direction: out
• First match: active
• IPv4
• Protocol: any
• Source/ SrcPort: any
• Dest/ DstPort: any
• Traffic Shaping:
• In RuleDirection --> LAN UploadQueue (min)
• In ReverseDirection --> LAN DownloadQueue (min)

Looks pretty fine for me...but!

As soon as I activate the rule on the WAN interface my traffic to any internet host drops completely.
But my traffic through Wireguard-VPN works pretty fine, but not limited to the above 365Mbit/s....

I have no clue what I am doing wrong...anyone an idea?
I think the bug is not related- as far as I understand it the bandwidth calculation is wrong and offers only half of configured values. But through Wireshark I do not have any limits (why not???) and to Internet all is blocked....
Thanks again!
/KNEBB

[NOT]

Hi,

thanks for the hints. I am currently configuring it. Still not understanding how it all works together, especially the two rule types and the issue with the reported bug...


Created a FW-rule on the (NATed) WAN interface (outgoing, src: VoIP VLAN) to assign traffic to the VoIP Shaper Queue (which is bound to the VoIP pipe, limited to 10Mb/s). Queue weight is 90.
 
Then created a schedule for "office times" and used a FW-rule to assign any other traffic (excluding the VoIP) to the "default office time upload queue" which is assigned to a pipe and by this limited to 365Mb/s (guaranteed value of 375Mb/s less the 10Mb/s for VoIP). This sheduled rule is ordered before the above one. Weight of the queue is 10.

So I have:

• Pipe VoIP - Limit 20
• Pipe LAN daytime - Limit 365
• Pipe LAN nighttime - Limit 500

Queues:

• Queue VoIP - weight 90
• Queue LAN daytime - weight 50
• Queue LAN nighttime - weight 50

The queues and pipes are assigned as the names tell.

Disabled all Shapoer rules.
Created a FW rule on the WAN interface:

• Outgoing, src: LAN, DST: any, protocol: any, schedule: daytime, traffic shaping in rule direction: Queue LAN daytime

No other rule before this FW rule for outgoing traffic, acting as a "catch all".
(Tried to assign the reverse traffic to the same queue, same result)
 
My expection:
Outgoing traffic should be limited to 365Mb/sec.

My observation:
Outgoing traffic is NOT limited.


I even see in the FW-protocol the traffic is assigned to the queue.

Any idea?

Time based rules are not possible with the ipfw ruleset (FW > shaper > Rules) but they are possible when using the pf rules + Traffic shaping feature (FW > Rules (option Traffic Shaping)). However there is a BUG in regards of that feature for reverse-direction if NAT is involved see:
https://forum.opnsense.org/index.php?topic=47716.msg254051

Hmmm.. can you help me a little bit how this works all together?

I got it so far the pipes limit the bandwidth (upper limit) while the queues weight the traffic according to the rules. Queues can get oignoredd when a rule sends the traffic to a pipe immediately ( I do not know how any weight is then calculated). Got this so far.

But how are the (firewall-)rules coming into the game you mentioned above? Do I overwrite everything and directly assign traffic to pipes/queues? How are they different (except scheduling possibility) from the shaper rules?

Thanks a lot!

/KNEBB

Moin,

klingt für mich eher NICHT nach Softwareproblem. Wenn wirklich ein HArd-Reset notwendig ist, hängt irgendwo in der Hardware etwas.

Ich würde mal sicherstellen, dass jeweils die aktuellste Firmware installiert ist. Und natürlich auch die SW-Update, aber das hast Du ja wohl).

In den Logfiles mal auf alles achten, was kurz vor dem Zusammenbruch war... vielleicht gibt es da einige Hinweise....

Aber ist schwer, so aus der Ferne....
/KNEBB
 

Ich habe Queues und Rules eingerichtet, die das Ganze zuordnen. Lt. Shaper --> Status funktioniert das Ganze auch wunderbar.

Über die Pipes richtet man maximale Obergrenzen ein. D.h. mehr geht nicht über diese Pipe. DAs ist auch alles super, das "Problem" tritt ja nur auf, wenn der Provider die maximale Uplink-Bandbreite nicht abdecken kann (also 375 anstatt 500). Dann werden Pakete ggf. verworfen u.ä. Und zwar ohne auch irgendwelche Priorisierungen (von mir) zu achten. Und damit geht die ganze Konfiguration flöten...

Stelle ich es aber auf die minimale Rate ein, dann weiß ich, dass der Provider diese auch annimmt und ordnungsgemäß weiterleitet und meine Priorisierung greift. Auf Ksoten der maximal verfügbaren Bandbreite.

Und deshalb wäre da eine zeitabhängige Regelung sinnvoll. Tagsüber Limit auf min --> VoIP kriegt sicher Prio. Nachts auf max --> Nutzung voller Bandbreite, wenn die Prio flöten geht, ist das egal, da telefoniert hier eh keiner mehr.

/KNEBB

Moin,

I just configured my shaper for VoIP traffic. Seems to work fine so far.

For the pipes I assigned the following upload rates:
VoIP:             10Mbit/s
default Uplaod:  350Mbit/s

Now from my Internet provider I got information about the max, average and guaranteed bandwidth:
Upload max:    500Mbit/s
Upload avg:    400Mbit/s
Upload min:    375Mbit/s

Now the shaper limits the traffice based on the configured upload pipe always to 350Mb/s sharp.
This is no good as I am wasting possibly available upload bandwidth. 350 vs. 500).

But configuring the shaper/ pipe to a higher value might lead to a saturated uplink without trafic shaping, right?

Is there any change to configure the shaper upload bandwidth based on some sort of automation? I like to have VoIP on top prio during the day but in the night the backup process should use all available bandwidth (500 instead of 350) to do the backups...

Thanks for ideas!

/KNEBB

DAs ist mal wieder ein typischer Fall von "Marketing-Verarsche" :(

Ja, diese Switches können tatsächlich routen. Und werden deshalb auch als L3 Switches beworben. Dabei sind sie bestenfalls L2+ Switches. Die können nämlich nicht die üblichen Routing-Protokolle, sondern nur statisches Routing.

Wie funktionert das bei denen? Du musst für jedes VLAN ein Interface des Switches einrichten. Und dieses Interface ist das jeweilige Default-Gateway des VLANs. Und dann wohl noch ein paar Sachen konfigurieren lt. Doku: IPv4 Routing, Inter-VLAN Routing (L3 Mode), Static Routes.

DANN routet das Ding (habe ich hier selbst im Einsatz, aber nur als ordentlicher Switch) wohl tatsächlich zwischen den VLANs.

Bleibt die Frage, die auch @meyegru gestellt hat, wo der Sinn von via VLAN getrennten Netzwerken ist, wenn die Routing-Wege dazwischen dann doch wie ein offenes Scheunentor sind...

Meine Empfehlung wäre auch, diese doch etwas krude Infrastruktur zusammenzulegen und nur ein lokales LAN zu betrieben. Ist ja auch besser, wenn man versteht was man macht ;)

/KNEBB

Wenn Dein Switch WIRKLICH ein Layer3 Switch ist, dann macht der doch auch Routing,oder?

Mac-Netz an den "Switch", OPNSense auch direkt da ran und auch den Proxmox Server da ran. Dann den Switch so konfigurieren, dass er dazwischen routet. Fertig die Laube. Dann geht nur das an die OPNSense, was auch wirklich raus soll....

Ansonsten ist das doch klar, dass die OPNSense der Flaschenhals ist - die hat nur 1GBit/s, wohingegen die beiden anderen Server 10gBit/s NICs haben...

Moin,

ich habe gerade mit dem Shaper meinen VoIP Verkehr priorisiert, das scheint soweit auch zu funktionieren.

In den Pipes habe ich Upload-Bandbreiten eingegeben:
VoIP:             10Mbit/s
default Uplaod:  350Mbit/s

Die Leistungsbeschreibung beim Provider sagt:
Upload max:    500Mbit/s
Upload normal: 400Mbit/s
Upload min:    375Mbit/s

Jetzt beschränkt der Shaper ja die Upload-Pipe IMMER auf 350Mbit/s. Das ist natürlich unschön. Setze ich das auf 490Mbit/s oder 390Mbit/s kann es aber sein, dass die VoIP Pakete nicht sauber priorisiert werden, richtig?

Kann man vielleicht das ganze irgendwie zeitbasiert steuern? So dass ich sicherstellen kann, dass die Priorisierung (bei max 350Mbit/s) auch sauber funktioniert- und Abends/ NAchts auch wirklich die volle vorhandene Bandbreite (zB für Backups) verwendet werden kann? Mag meine Backups nicht zwingend u 150Mbit/s beschneiden...

Danke für Ideen!

/KNEBB

Leider ist es so, dass das Verhalten von unmanaged Switches nicht genau definiert ist - im besten Fall verhalten sie sich so, als wenn alle Ports als "Trunk" konfiguriert sind, aber garantiert ist das nicht.

...was meine Aussage ja noch bestätigt. Sobald Du mit VLANs arbeitest, läßt du die Finger von unmanaged Switches. Einzige Ausnahme: die sollen in nur einem VLAN verwendet werden und werden über "Untagged" angebunden....

Ok, jetzt nicht 10GbE, sondern nur 2,5GbE:
ThomasKrenn LES Systeme.

Oder bekommst Du wirklich 10GbE WAN Uplink? Wo ist das? Kann ich umziehen ;)

Moin,

wenn ich auch Deine Struktur nicht so ganz durchblicke, so gilt: Finger weg von unmanaged Switchen bei Verwendung von VLAN!

Diese unmanaged Switche sind dann eher sowas wie eine Bridge. Eingehender Verkehr mit dem "VLAN42" tag wird auch auf allen Ports rausgejagt. Ebenso "VLAN3141".

Du könntest zwar einen managed dahinter schalten, aber dann blickt ja keiner mehr durch...

/KNEBB

Määäääääh!

Ja, ok, das hat geklappt. Wenn man im Kopf hat, dass ALLE Registrierungen aus sein müssen. Außer natürlich der Einstellung wo "KEINE" davorsteht...

Vielen Dank!

/KNEBB

[RICHTIG]

Moin,

meine OPNSense ist Teil der lokalen Domain, nennen wir sie "beispiel.de". Im LAN steht für diese (und eine wertere "example.de") Domain ein authoritativer DNS (Bind9 auf Debian), der ALLE DNS-Einstellungen für die Domains beinhaltet.
Jetzt möchste ich, dass aber auch die OPNSense einen Teil der DNS-Anfragen übernimmt und parallel zu dem eigentlichen DNS-Anfragen beantwortet. Also haben alle LAN-Clients ZWEI DNS-Resolver Einträge;
192.168.42.1 <--- OPNSense/ Unbound
192.168.42.15 <--- Debian Bind

Klappt auch gut, die Clients können DNS-Abfragen nach öffentlichen Domains über beide Resolver erfoolgreich durchführen.

Der Unbound auf OPNSense ist so eingestellt, dass er via Forwarding die lokale Zone (beispiel.de) an den lokalen bind9 weiterleiten soll. D.h. alles was diese Zone betrifft soll der 42.15er Debian Bind9 beantworten.
Funktioniert  soweit auch prima:

Code Select Expand

root@opnsense:~ # host -v lanhost.beispiel.de
Trying "lanhost.beispiel.de"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 642
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;lanhost.beispiel.de. IN A

;; ANSWER SECTION:
lanhost.beispiel.de. 3600 IN CNAME lanhost.example.de.
lanhost.example.de. 3600 IN A 192.168.42.114

Received 90 bytes from 127.0.0.1#53 in 1 ms
Trying "lanhost.beispiel.de"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36936
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;lanhost.beispiel.de. IN AAAA

;; AUTHORITY SECTION:
example.de. 2972 IN SOA ns.beispiel.de. admin.beispiel.de. 1763729903 3600 1800 604800 86400

Received 119 bytes from 127.0.0.1#53 in 0 ms
Trying "lanhost.beispiel.de"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36801
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;lanhost.beispiel.de. IN MX

;; AUTHORITY SECTION:
example.de. 2972 IN SOA ns.beispiel.de. admin.beispiel.de. 1763729903 3600 1800 604800 86400

Received 119 bytes from 127.0.0.1#53 in 0 ms
Einzig und allein die DNS-Sachen für den Namen der OPNSense selbst werden anhand der lokalen Interfaces aufgelöst:

Code Select Expand

root@opnsense:~ # host opnsense.beispiel.de
opnsense.beispiel.de has address 192.168.32.254
Das ist die IP eines der OPNSense-Interfaces, aber der DNS-Server verweist nur auf das "Haupt-Interface".


Also kurz:
 
Abfrage nach irgendeinem Namen in der lokalen Domain ---> Unbound forwarded an lokalen DNS. RICHTIG.
Abfrage nach dem Namen der OPNSense.lokale.domain --> Unbound beantwortet selbst mit einer willkürzlich gewählten Interface-IP (MIST)

Das muss doch irgendwie möglich sein, dem Unbound zu sagen, dass er für diese Domain echt KEINE NAmensanfragen selbst beantwortet, sondern einfach IMMER weiterleitet, odeR?

Wie kriege ich das hin?

Danke& Grüße
/KNEBB