PfSense reagiert bei Routing durch bestimmten Gateway sehr langsam

Hallo,

ich möchte in pfSense einrichten, dass Traffic von einem bestimmten LAN-PC zu einem bestimmten Server durch LTE geroutet wird.

Als ich es eingerichtet habe passierte zuerst nichts und erst dann 20Min. ging der Traffic durch LTE...

Ist es normal?

Wenn ich die FW Rule speichere habe ich 2-3 Min. immer noch kein Traffic auf dem Gateway (laut pfSense Monitoring).

Ich meinte, dass so etwas sofort nach dem Speichern Auswirkungen haben müsste.

Mein Rule:

Bei meinen Versuchen war das Rule ganz oben in der Liste der LAN-Rules:

Woran kann dieses "nicht reagieren" liegen?

Die einzelnen WAN sind an sich in Ordnung, wenn ich sie jeweils als Default Gateway einstelle, gibt es IZugang inzwischen ohne Probleme.

Das Problem kann eventuell sein, dass die beiden Gateway in eine Gruppe erfasst wurden. Da aber DSL dort als default GW behandelt wird, kann ich auch in dem Rule nicht auf LTE routen.

Gr. I.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 279728

Url: https://administrator.de/forum/pfsense-reagiert-bei-routing-durch-bestimmten-gateway-sehr-langsam-279728.html

Ausgedruckt am: 21.04.2025 um 21:04 Uhr

7 Kommentare

Neuester Kommentar

Du hast Recht, Änderungen sind sofort nachdem du auf Save und Apply geklickt hast aktiv.
Was sagt denn ein Traceroute auf diesem bestimmten Client zu dem spzifischen Server ??
Zeigt der denn die richtigen Routing Hops an ??
Hilfreich wäre auch mal ein Output der Routing Tabelle
Ggf. solltest du immer bei solchen Änderungen die States Table unter Diagnostics resetten.

Die einzelnen WAN sind an sich in Ordnung, wenn ich sie jeweils als Default Gateway einstelle

Was meinst du damit ?? Beide sind immer Default Gateway per se und die Firewall balanced sessionbasiert zwischen ihnen ?!

Ich schau mal mit einem anderen PC nach. Mein Client ist ein Comrex VoIP Codec für Live Radiosendungen.

Dort gibt es kein CMD, wo ich Traceroute eingeben könnte ...

Mit Default meine ich, dass ich bei dem GW einstellen muss, ob es sich um den default GW handelt. Wenn Rules es nicht anders regeln, wird das Traffic dorthin geroutet.

Dort gibt es kein CMD, wo ich Traceroute eingeben könnte ...

Dann sei einfach mal etwas kreativ und setzt stattdessen einen Test PC mit der identischen IP Adresse dafür ins Netz mit dem du erstmal alle diese Tests durchführst.

Klappt alles ersetzt du es wieder mit dem Original Gerät ! Kommt man eigentlich auch von selber drauf....
Ggf. ist das hier noch hilfreich:
http://www.tecmint.com/how-to-setup-failover-and-load-balancing-in-pfse ...

Wichtig ist auch das Konfigurieren von richtigen DNS Servern pro WAN Link. Beachte was im entsprechenden pfSense Dokument steht:
"If the DNS servers are hardcoded on the clients, this limitation isn't relevant, however services on the firewall itself will still need DNS and could become slow or fail waiting for DNS if there is not a reachable DNS server."
Du solltest also darauf achten das die per WAN Port DNS Server auch welche sind die zum entspr. Provider gehören. Falls du eine Kaskade betreibst mit Routern dahinter sollte das immer der Router bzw. dessen IP sein, da die in der Regel als Proxy DNS arbeiten.
Fast alle Provider filtern fremde DNS Server anderer Provider. Konfigurierst du also hier einen falschen DNS kommt es zu solchen längeren Timeouts wie du sie siehst. Beachte das bei deinem Setup.

Ich bin jetzt dazu gekommen, mit einem PC zu testen. Es stellte sich heraus, dass die Filter extrem langsam geladen werden. Auf dem GUI wird die Änderung schnell übernommen, wenn ich mir aber im Hintergrund das Laden der Filter anschauen, daiert es 10-20 Min. bis ein "done" kommt.

Was kann der Grund sein?

Nach einem mit "done" abgeschloßenem Laden hat das Routing zumindest von einem PC gut funktioniert. Von unserem VoIP Codec nicht. Weder mit IP Adresse, noch mit Alias, mit Port, ohne Port,. Ich teste mal weiter.

daiert es 10-20 Min. bis ein "done" kommt.

Oha...da ist dann wohl etwas faul. Dauert hier sogar auf einem alten ALIX 2D13 Board nur max. 3 Sekunden !!

Von unserem VoIP Codec nicht.

Bahnhof... ??? Wie kann ein Codec routen ?? Das musst du dem Forum aber mal erklären...?!

Dies ist ein Comrex Access VoIP (Hardware) Codec mit eigenem IP. Wenn ich diese Audioübertragungen durch LTE routen möchte, klappt es nicht.

Ein "Codec" ist normalerweise immer ein Stück Software aber niemals Hardware. Aber nungut...wenn der Hersteller das als "Codec" bezeichnet ists ja OK.

Wenn ich diese Audioübertragungen durch LTE routen möchte, klappt es nicht.

Das ist oft daher bedingt das Provider solche Art Traffic im LTE blocken aus Bandbreitenschutz. Häufig ist das gekoppelt an die Art und Weise des Vertrags.
Bei billigen nur Siurf Verträgen ist sowas und VPN ganz oft geblockt. Frag sicherheitshalber beim Provider nach bevor du dir einen Wolf nach dem Fehler suchst !
Wenn sonst alles andere durchs LTE geht außer dieser Anwendung sieht es danach aus.
Hilfreich wäre auch mal zu wissen welches Protokoll der "Codec" für die Übertragung nutzt ? Stremaing mit RTP oder Multicast oder...?
Leider sagst du dazu ja nichts