PFsense Hardware
-
Genau dafür legt man Floating Rules an, und das pro Gateway für IPv4 und IPv6, also in dem Fall sind das dann 4 Regeln.
Denn in den erweiterten Optionen setzt man ja explizit das Gateway und dann die Pipes.
So stellt man sicher, das jeder Limitier auf auf dem richtigem WAN Interface sitzt.
-
@nocling
ja das war mir nicht mehr wirklich bewusst, dass man die Limiter auch bei den Floating Rules benutzen kann. Habe das testweise auch bei mir mal umgesetzt und es scheint zu funktionieren. Wenngleich ich auch ein etwas ungutes Gefühl habe, wenn ich da jetzt Regeln habe, die auf den WAN1 & 2 Interfaces liegen mit ANY in Source/Destination
-
@m0nji die Firewall Rule Action ist ja hoffentlich 'Match' und nicht auf 'Pass'.
-
@thiasaef ja das habe ich gefühlt 10-mal überprüft
-
@m0nji Vielleicht machts Sinn die Regel auch mal optisch zu posten, damit die Leute das sehen und verstehen? Ich musste gerade im Kopf auch 3x überlegen, bis ich verstanden habe, dass ihr match auf floats macht
-
@jegr
sind die Regeln von @thiasaef aus dem verlinkten Beitrag (https://forum.netgate.com/topic/112527/playing-with-fq_codel-in-2-4/815)
Die icmp Regeln sind Pass Regeln und die letzten 4 sind Match Regeln
Die ersten 2 Match Regeln sind IN Direction Regeln und die letzten beiden Match Regeln sind OUT Direction Regeln. -
@m0nji die ICMP Regeln kann man zusammenfassen, wenn man jeweils beide Interfaces auswählt.
-
Zudem ist die Regel mit Richtung OUT.
Die ICMP Regel habe ich inzwischen wieder deaktiviert, weil das mal ein Fehlverhalten war, das ist soweit mir bekannt ist aber behoben worden. ICMP sollte nicht länger verworfen werden.
-
@nocling said in PFsense Hardware:
Die ICMP Regel habe ich inzwischen wieder deaktiviert, weil das mal ein Fehlverhalten war, das ist soweit mir bekannt ist aber behoben worden.
Gerade eben mit 2.6.0 getestet. Ohne die Regeln funktioniert traceroute via ICMP bei mir nicht:
traceroute -I netgate.com traceroute to netgate.com (199.60.103.104), 30 hops max, 60 byte packets 1 _gateway (192.168.1.1) 0.213 ms 0.190 ms 0.187 ms 2 199.60.103.104 (199.60.103.104) 1.841 ms 1.839 ms 2.008 ms 3 199.60.103.104 (199.60.103.104) 7.242 ms 8.821 ms 8.819 ms 4 199.60.103.104 (199.60.103.104) 10.758 ms 12.598 ms 12.715 ms 5 199.60.103.104 (199.60.103.104) 12.491 ms 12.536 ms 12.833 ms 6 199.60.103.104 (199.60.103.104) 33.998 ms 35.192 ms 35.186 ms 7 199.60.103.104 (199.60.103.104) 28.251 ms 24.201 ms 24.282 ms 8 199.60.103.104 (199.60.103.104) 16.290 ms 16.395 ms 16.583 ms 9 199.60.103.104 (199.60.103.104) 13.551 ms 13.662 ms 16.119 ms -
Ja stimmt, die ICMP Regeln sind immer noch notwendig, sonst kommt es unter Last zu einem nicht gewünschtem Verhalten.
-
Danke für deine Ausführungen, ich habe die Einstellungen angepasst.
Gleichzeitig habe ich ein Upgrade auf 2.6 durchgeführt. Deine Einstellungen die du im Link erwähnt hast, gelten aber auch für diese Version?Hier meine Einstellungen (Abweichend zu deinem Screenshot, aufgrund der Version?)
LTE IN
LTE OUT
Floating Rules
Da bin ihc mir bei dem Gateway nicht sicher, meinst du das WAN Interface unter dem Punkt Gateway: Default? Wenn ja, gehe ich von dem LTE WAN Interfache aus, richtig?
Laut deiner Liste:
1.) Add quick pass floating rule to handle ICMP traceroute. This rule matches ICMP traceroute packets so that they are not matched by the WAN-Out limiter rule that utilizes policy routing. Policy routing breaks traceroute.Action: Pass
Quick: Tick Apply the action immediately on match.
Interface: WAN
Direction: out
Address Family: IPv4
Protocol: ICMP
ICMP subtypes: Traceroute
Source: any
Destination: any
Description: policy routing traceroute workaround
Click Save
2.) Add quick pass floating rule to handle ICMP echo-request and echo-reply. This rule matches ping packets so that they are not matched by the limiter rules. See bug 9024 for more info.Action: Pass
Quick: Tick Apply the action immediately on match.
Interface: WAN
Direction: any
Address Family: IPv4
Protocol: ICMP
ICMP subtypes: Echo reply, Echo Request
Source: any
Destination: any
Description: limiter drop echo-reply under load workaround
Click Save
3.) Add a match rule for incoming state flows so that they're placed into the FQ-CoDel in/out queuesAction: Match
Interface: WAN
Direction: in
Address Family: IPv4
Protocol: Any
Source: any
Destination: any
Description: WAN-In FQ-CoDel queue
Gateway: Default
In / Out pipe: fq_codel_in_q / fq_codel_out_q
Click Save
4.) Add a match rule for outgoing state flows so that they're placed into the FQ-CoDel out/in queuesAction: Match
Interface: WAN
Direction: out
Address Family: IPv4
Protocol: Any
Source: any
Destination: any
Description: WAN-Out FQ-CoDel queue
Gateway: WAN_DHCP
In / Out pipe: fq_codel_out_q / fq_codel_in_q
Click Save/Apply Changes -
@sub2010 said in PFsense Hardware:
Deine Einstellungen die du im Link erwähnt hast, gelten aber auch für diese Version?
Ja.
Quick: Tick Apply the action immediately on match.
Das hast du bei der 1. ICMP Regel vergessen zu setzen.
Wenn ja, gehe ich von dem LTE WAN Interfache aus, richtig?
Ja, allerdings hast du zweimal WAN-Out in der Beschriftung stehen. Ist nur die Beschriftung falsch?
Hier meine Einstellungen (Abweichend zu deinem Screenshot, aufgrund der Version?)
Und was sagt https://www.dslreports.com/speedtest jetzt?
-
@thiasaef said in PFsense Hardware:
Das hast du bei der 1. ICMP Regel vergessen zu setzen.
Ja, hatte ich vergessen und korriergiert
@thiasaef said in PFsense Hardware:
Ja, allerdings hast du zweimal WAN-Out in der Beschriftung stehen. Ist nur die Beschriftung falsch?
Habe ich ebenfalls korrigiert
Heute Morgen habe ich einen Test gefahren und leider hat es nicht wie erhofft funktioniert.
-
@sub2010, stell den Limiter doch einfach mal auf 4 Mbit/s im Download und 1 Mbit/s im Upload, mach einen ganz normalen Speedtest auf speedtest.net und poste das Ergebnis hier. Sonst drehen wir uns noch zwei Wochen im Kreis.
