pfSense auf vServer - mit VPN schneller als ohne?

  • Moin,


    ich habe auf einem VPS 200 G8 die Firewall-Distribution pfSense installiert, das läuft soweit erstmal ohne Probleme. Zusätzlich habe ich IPSec-Tunnel zu den FritzBoxen meiner Eltern und meiner Wohnung eingerichtet. Außerdem läuft unter pfSense noch ein OpenVPN-Server, über den ich mich von überall in dieses Netzwerk einwählen kann. Das funktioniert ziemlich perfekt, ich kann von überall aus (Eltern, eigene Wohnung, unterwegs) alle Rechner egal wo erreichen (NAS bei meinen Eltern, mein NAS, etc...). Alles übrigens mit Dual Stack, also IPv4+IPv6. Soweit so gut.


    Was ich auch (zeitgleich) mit eingerichtet habe, war eine weitere OpenVPN-Client-Verbindung von pfSense zu einem anderen VPN-Server, um dort auch externe Knoten zu erreichen. Damit verfügt meine pfSense sozusagen über 4 Gateways (also Endpunkte über die aus dem Netzwerk ausgehender Traffic terminiert werden kann): Netcup v4, Netcup v6, Uplink-VPN v4 und Uplink-VPN v6. Da ich nicht der einzige bin, der sich per VPN auf die pfSense einwählt, habe ich als Standardgateway für eingehende VPN-Verbindungen den Uplink-VPN konfiguriert, d.h. eine Firewall-Regel erstellt, die besagt, das alles, was aus einer bestimmten IP-Range kommt, nämlich das des pfSense-VPN-Servers, über das Uplink-VPN geschickt werden soll. Klappt perfekt, Durchsatz etwa 20 MBit Down/Up. Jetzt dachte ich mir: Das ist bestimmt voll der Umweg. Da ich selbst nicht auf das Uplink-VPN-Netzwerk zugreifen muss, kann ich mir per Client-Sonderregel ja ne feste IP zuweisen und der festen IP per Regel das Netcup-Gateway verpassen. Resultat: Nur noch 2 Mbit Downstream (witzigerweise 20 Up). Ich hab kein Rate Limiting in der Firewall noch sonst eine Idee, woher das kommt. Erwartet hätte ich, dass eine direkte Terminierung beim vServer (deutlich) schneller ist als noch ein weiteres mal die Daten durch VPN zu schicken und da erst terminieren zu lassen (also de-facto ein Hop mehr). Ich hab auch aktuell keine Ahnung, nach was ich suchen soll.


    Kann mir eventuell von euch jemand einen Tip geben? Danke!


    Viele Grüße
    Matthias

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

  • Welche CPU-Last hat denn dein Server wenn du einen Speedtest machst?

    Wie ist dein ‚Uplink VPN Server‘ hardwaretechnisch dimensioniert?


    L2 oder L3 VPN?


    Ich kann mir vorstellen, dass der kleine VPS einfach mit dem ganzen Abhandeln der NAT Verbindungen nicht klar kommt die entstehen sobald du aus dem VPN austrittst.


    Hast du Hardware Offloading usw. bei der pfSense am VPS von Netcup deaktiviert?

  • Zitat

    Welche CPU-Last hat denn dein Server wenn du einen Speedtest machst?

    Genaue Werte sind da schwer abzulesen, das hüpft auf dem Dashboard fleißig mal auf ~80-90% und dann wieder 20-30% (bei Tests sowohl mit Uplink-VPN als auch Netcup als Gateway).

    Zitat

    Wie ist dein ‚Uplink VPN Server‘ hardwaretechnisch dimensioniert?

    Details kenne ich leider nicht, aber definitiv ne GBit-Anbindung, die man auch voll ausnutzen kann. Sollte aber für mein Problem egal sein, da der ja bei dem 2Mbit-Problem nicht involviert ist.

    Zitat

    L2 oder L3 VPN?

    Von meinem Rechner zum pfSense L2, von pfSense zum Uplink-VPN L3.

    Zitat


    Ich kann mir vorstellen, dass der kleine VPS einfach mit dem ganzen Abhandeln der NAT Verbindungen nicht klar kommt die entstehen sobald du aus dem VPN austrittst.

    Keine Ahnung, wie viel Leistung man Grundsätzlich für ein NAT braucht (wie viel Leistung hat denn so ne FritzBox, die 100MBit schafft?). Was gegen deine Theorie spricht, ist, dass ich auch gegenüber dem Uplink-VPN NAT mache, und da 20MBit möglich sind. Von daher schließe ich, dass im Falle der 2MBit nicht die CPU der limitierende Faktor ist. VPN wird ja einmal "terminiert", wenn die Pakete von meinem Rechner zur pfSense gekommen sind. Die Weiche dort wirft sie entweder direkt ins WWW (über das Netcup Gateway) oder muss sie wieder in VPN Einwickeln und an den Uplink-Server schicken. Ich hätte jetzt angenommen, dass letzteres aufwändiger und damit langsamer sein müsste. Aber genau das Gegenteil ist ja der Fall.

    Zitat

    Hast du Hardware Offloading usw. bei der pfSense am VPS von Netcup deaktiviert?

    Ähm... erstes mal davon gehört. Aber nach kurzem Lesen und nachschauen: Ist deaktiviert.

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

  • Hay,

    Kann mir eventuell von euch jemand einen Tip geben? Danke!

    Habe ich das richtig verstanden, dass wir hier prinzipiell einen Tunnel im Tunnel haben?


    Dann würde es sich ggf. lohnen, die mtu bezüglich Fragmentierung zu überprüfen. Bandbreitenprobleme im VPN deuten sehr häufig auf Fragmentation, (Teil-)Paketverlust und Resend hin.


    In IPSec habe ich mich nur oberflächlich eingelesen (einlesen müssen), aber es gibt verschiedene Implementierungen einschließlich des nochmaligen Tunnelns der eigenen Pakete (was es dann durch einen dritten Tunnel noch komplizierter macht).


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Servus. Das wäre lediglich meine erste Vermutung gewesen.


    Ein guter Punkt von Peter und auch meine nächste Vermutung wäre die MTU. Versuche sie mal auf 1300 zu setzen. Wird das besser kannst du dich wieder hochtasten.


    Eventuell kannst du die Bandbreite zwischen nc und ‚Uplink VPN‘ auch mal testen.


    lg.

  • Irgendwie finde ich die wichtigste Information nicht: Tunnelst du TCP durch TCP und nochmal TCP? Hast du TCP Retransmits oder andere Störungen? Kannst du bitte per Wireshark einen tcpdump visualisieren bzgl. Fehlern sowie Pakete pro Sekunde?

    "Security is like an onion - the more you dig in the more you want to cry"

  • Dann würde es sich ggf. lohnen, die mtu bezüglich Fragmentierung zu überprüfen. Bandbreitenprobleme im VPN deuten sehr häufig auf Fragmentation, (Teil-)Paketverlust und Resend hin.

    Es tut so gut, wenn man etwas posten möchte, was einem dazu gerade einfällt, und dann merkt, dass CmdrXay wieder einmal schneller war.

    Tip an den TE: Grundsätzlich kann man OpenVPN mit den Optionen tun-mtu und fragment auf die Sprünge helfen, denn mtu-disc funktioniert nicht überall. Bitte niemals die die link-mtu tunen oder mit tun-mtu-extra arbeiten. tun-mtu auf 1500 oder 9000 und fragment auf eine Paketgröße von 1472 (oder 1400, damit es auch mit IPv6 und über Router, die nicht mit einer MTU von >1500 auf dem DSL-Interface umgehen können, noch klappt) stellen.


    Für IPv6 sollte man einplanen, dass der IP-Header um 20 Byte länger ist als für IPv4, also statt 20 Bytes 40 Bytes lang ist.


    Für die Berechnung empfiehlt sich ein Tool wie dieses:

    https://baturin.org/tools/encapcalc/

    Freilich macht es auch einen Unterschied, ob mit tun oder tap gearbeitet wird - im letzteren Fall kommt noch der Ethernet-Frame hinzu.

  • Habe ich das richtig verstanden, dass wir hier prinzipiell einen Tunnel im Tunnel haben?

    Ne, das habe ich wohl zu kompliziert erklärt. Folgende 2 Wege können die Daten nehmen:

    • Client <--[OpenVPN]--> pfSense <--[Netcup Leitung] --> WWW (2 MBit/s)
    • Client <--[OpenVPN]--> pfSense <--[OpenVPN]--> Upstream VPN - WWW (20 MBit/s)

    Es ist also kein Tunnel im Tunnel. Und insofern seltsam, weil die Daten Richtung Upstream VPN ja auch über das "Netcup-WWW" rausgehen - eben Richtung Upstream-VPN.


    Gleichermaßen müsste damit die MTU auch unverdächtig sein, da sie ja im unteren Fall funktioniert. Ich hab das Bandbreitenproblem ja witzigerweise genau dann, wenn ich den Upstream-VPN nicht nutze.

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

  • Ne, das habe ich wohl zu kompliziert erklärt. Folgende 2 Wege können die Daten nehmen:

    • Client <--[OpenVPN]--> pfSense <--[Netcup Leitung] --> WWW (2 MBit/s)
    • Client <--[OpenVPN]--> pfSense <--[OpenVPN]--> Upstream VPN - WWW (20 MBit/s)

    Es ist also kein Tunnel im Tunnel. Und insofern seltsam, weil die Daten Richtung Upstream VPN ja auch über das "Netcup-WWW" rausgehen - eben Richtung Upstream-VPN.


    Gleichermaßen müsste damit die MTU auch unverdächtig sein, da sie ja im unteren Fall funktioniert. Ich hab das Bandbreitenproblem ja witzigerweise genau dann, wenn ich den Upstream-VPN nicht nutze.


    1. Wie schaut denn das Traceroute innerhalb des Tunnels für beide Varianten aus? Spielt da etwas Routen-Ping-Pong?

    2. Etwaige MTU-Unterschiede und würde tracepath ebenso wie asymmetrische Routen gut aufzeigen.

    3. Was sagt netstat -rn auf pfSense und was sagen die Routentabellen auf den Clients?

    4. Wenn es sich um unterschiedliche Betriebssysteme handelt, gibt es einen alten Bug, der bewirkt, dass sndbuf und rcvbuf ungünstig bemessen werden: https://community.openvpn.net/openvpn/ticket/461

    Man kann diese Werte in pfsense (bequem über das Menü oder besser manuell) setzen und auch an die Clients pushen.
    Sofern die Konfiguration Tunnel-an-Tunnel (sprechen wird hier von zwei verschiedenen Ports oder läuft das im Peer-Mode über denselben Port?) kein MTU-Problem hat, kann das eventuell noch helfen.

    5. Hinsichtlich des Gateway/Defaultrouten-Problems gibt es unterschiedliche Herangehensweisen. Das Pushen von Routen (2x 1/2 Internet (0.0.0.0/1, 128.0.0.0/1), 4x1/4 Internet, o.ä.) könnte effektiv sein. Siehe: https://community.openvpn.net/…iki/IgnoreRedirectGateway



    Die Frage von

    Irgendwie finde ich die wichtigste Information nicht: Tunnelst du TCP durch TCP und nochmal TCP? Hast du TCP Retransmits oder andere Störungen? Kannst du bitte per Wireshark einen tcpdump visualisieren bzgl. Fehlern sowie Pakete pro Sekunde?

    sollten wir auch noch erörtern. Das kann sehr wohl Einfluss auf die Performance haben. Fragen, die da sonst interessant wären: lzo, lz4? Die springende CPU-Last kann damit im Zusammenhang stehen. Tun oder Tap? Logerrors oder Messages hinsichtlich Fragementen, tun mtu-extra oder abweichende Werte zwischen den Peers, Client oder Servern. (welcher Mode überhaupt)?

  • Moin,


    erstmal vielen Dank für die Rückmeldung, leider scheint aber das Problem noch nicht korrekt kommuniziert zu sein ;) ch dachte ich hatte es klargestellt, dann eben nochmal, in anderen Worten:


    In beiden Setup ist es der selbe Client, mit der selben OpenVPN-Konfiguration, selbes Betriebssystem. Die OpenVPN-Verbindung wird, wie oben beantwortet, über L(ayer)2, also tap, aufgebaut, Protokoll ist UDP. Es ist die selbe pfSense-Firewall, der selbe OpenVPN-Server zu dem ich verbinde, selbe Server-Konfiguration. pfSense besitzt (die ganze Zeit) (logischerweise) eine WAN-Verbindung, eben den virtuellen Netcup-Netzwerkstöpsel. Außerdem ist (die ganze Zeit) eine VPN-Client-Verbindung von der pfSense zum Upstream-VPN-Server aktiv (der natürlich die WAN-Verbindung nutzt, wie soll er sonst irgendwohin kommen). Damit verfügt die pfSense über 2 (wenn wir über v4/v6-Dual-Stack reden 4) Gateways: WAN, Upstream-VPN. Dieses Setup existiert die ganze Zeit und ist bei beiden Testfällen identisch. Es gibt kein TCP in TCP und erst recht kein TCP in TCP in TCP.


    Nun zu dem einzigen Unterschied: In der pfSense existiert eine Regel für den innerhalb der eingehenden VPN-Verbindung ankommenden Traffic, also alles das, was der Client-Rechner in das VPN-Netzwerk steckt. In dieser Regel kann man in den Advanced-Settings ein Gateway definieren, über das der eingehende Traffic weitergeroutet werden soll. Meine einzige Änderung: Ich wechsle zwischen WAN und Upstream-VPN.


    Resultat (speedtest.net) aus Sicht des Client-PCs in Abhängigkeit des in der pfSense eingestellten Gateway für eingehende Daten innerhalb des (eingehenden) VPN-Dienstes, aktuell gemessen an einer 100MBit-Leitung (synchron):

    WAN Upstream: 40-55 MBit/s, pfSense-CPU-Auslastung ca. 80-90%

    WAN Downstream: 5-7 MBit/s, pfSense-CPU-Auslastung: ca. 20-30%

    Upstream-VPN Upstream: 40-50 MBit/s, pfSense-CPU-Auslastung ca. 80-90%

    Upstream-VPN Downstream: 40-50 MBit/s, pfSense-CPU-Auslastung ca. 80-90%

    • Wäre der Wert mit Upstream-VPN niedriger als der bei WAN, hätte ich nix gesagt, da es ja eigentlich ein Hop mehr und eine zusätzliche Verschlüsselung ist und die Bandbreite zum Upstream-VPN durch die WAN-Bandbreite limitiert ist. Die Tatsache, dass WAN signifikant langsamer ist als Upstream-VPN (über WAN), macht mich stutzig
    • Die Tatsache, dass lediglich der Downstream (also die Daten vom Internet hin zum WAN-Port des pfSense-Servers) wirklich signifikant einbricht, ist extrem auffällig.
    • IPSec hat mit dem Problem nichts zu tun, das ist zwar auch konfiguriert, aber für das Problem irrelevant, da die fraglichen Daten dort nicht langlaufen. Hatte es nur der Vollständigkeit halber erwähnt.

    Meine Schlüsse (zur Diskussion freigegeben):

    • Der Client hat keine Ahnung wie er terminiert wird. Von daher gehe ich davon aus, dass das Problem nicht auf der Strecke zwischen Client-PC und pfSense liegt, da diese in beiden Fällen identisch ist.
    • Es hat nichts mit der MTU zu tun, da die Tunnel einwandfrei funktionieren, es bremst erst, wenn ein Nicht-Tunnel (WAN) involviert ist. Noch ein weiterer Grund, der gegen die MTU spricht: Die Pakete, die die pfSense absendet (Upstream), werden schnell bestätigt. Daher scheint die MTU auf meiner Seite zu stimmen. Auf die MTU der Gegenseite (das wäre der Netcup-Router) habe ich keinen Einfluss, nehme aber mal dreist an, dass die in Ordnung ist.
    Zitat

    Wie schaut denn das Traceroute innerhalb des Tunnels für beide Varianten aus? Spielt da etwas Routen-Ping-Pong?

    Innerhalb des Tunnels zwischen Client-PC und pfSense identisch. Von pfSense zu 8.8.8.8 über Netcup 5 Hops, über den Upstream-VPN 8 Hops. Wie sehe ich, ob da Routen-Ping-Pong gespielt wird?

    Zitat

    Etwaige MTU-Unterschiede und würde tracepath ebenso wie asymmetrische Routen gut aufzeigen.

    Falls meine Annahme, dass es nichts mit der MTU zu tun hat, falsch ist: Wie finde ich das mit tracepath heraus?

    Zitat

    netstat -rn

    Client-Routing-Tabellen sind aus besagten Gründen in beiden Fällen identisch.

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

  • Außerdem ist (die ganze Zeit) eine VPN-Client-Verbindung von der pfSense zum Upstream-VPN-Server aktiv (der natürlich die WAN-Verbindung nutzt, wie soll er sonst irgendwohin kommen).

    Netcup-VLAN? Wäre ja denkbar.

    In dieser Regel kann man in den Advanced-Settings ein Gateway definieren, über das der eingehende Traffic weitergeroutet werden soll.

    Danke! Kenne ich: produziert vermutlich asymmetrische Routen, weil es einen Hop auf der ausgehenden Route eliminiert.

    Versuch doch bitte einmal das über (gepushte) Routen innerhalb des VPN statt über die Firewall zu regeln, denn nur so kannst Du sicher sein, dass auch die korrekte inbound-rule im ersten Anlauf getroffen wird - gerade dann, wenn man im NAT (für IPv4) die automatische Regelerstellung zu Gunsten der besser kontrollierbaren manuellen Regelerstellung umgestellt hat, wird das auch sichtbar werden.

    Wie sehe ich, ob da Routen-Ping-Pong gespielt wird?


    Durch das WAN-Gateway innerhalb der NAT-Rule vermutlich gar nicht. Tracepath würde eine Asymmetrie der Route aufzeigen.


    Danke für die Infos.

    Mein Tip: WAN-Gateway herausnehmen und innerhalb von OpenVPN mit spezifischeren Routen arbeiten, wie im vorigen Posting von mir bezeichnet respektive wie nachfolgend beschrieben:


    0.0.0.0/1 und 128.0.0.0/1 sind spezifischer als 0.0.0.0/0

    0.0.0.0/2 und 64.0.0.0/2 und 128.0.0.0/2 und 192.0.0.0/2 sind spezifischer als 0.0.0.0/1 und 128.0.0.0/1.

    ...

    so kann man die Defaultrouten übersteuern.

    Detto wird eine Hostroute A.B.C.D/32 stets einer generellen Route vorgezogen werden.


    Das Problem mit dem pfSense-Gateway im NAT, so wie ich das von eigenen Experimenten damit in Erinnerung habe, ist, dass der ausgehende Traffic direkt über dieses Interface geschickt wird, während der related inbound traffic die NAT-Regeln erst durchlaufen muss. Und da könnte es auch durchaus sein, dass der Traffic im Kreis geschickt wird oder mehrere potentielle Pfade nimmt.


    Vielleicht liege ich falsch, dann würde es mich freuen, über meine Fehlannahme aufgeklärt zu werden. Ebenso würde es mich freuen zu erfahren, ob ich richtig lag. Viel Erfolg jedenfalls!

  • Hallo,


    habe ein ähnliches Setup mit pfsense (2.4.4-p1) auf einer VPS 200 G8 aufgesetzt und bin vermutlich auf das Gleiche Problem gestoßen.


    Auf das WAN-Interface habe ich eine Outbound NAT-Regel gelegt, die den Verkehr aus dem VPN auf die Adresse des WAN-Interface übersetzt.

    Sobald der Verkehr durch diese NAT-Regel läuft, sinkt die Downstream-Bandbreite um etwa 90%. Der Upstream ist nicht betroffen.


    Wenn man auf der pfsense z.B. das Squid-Paket installiert, kann man über den Proxy mit vollem Downstream in das Internet zugreifen.

  • Sobald der Verkehr durch diese NAT-Regel läuft, sinkt die Downstream-Bandbreite um etwa 90%.

    Sobald der Verkehr downstream auf das VPN trifft, kommt es ja zu einer Veränderung der Paketgrößen. D.h. es müssen die eingehenden Pakete mit der maximal möglichen MTU 1500 ihre Payload (das sind für OpenVPN wegen UDP 8 Byte +20 Byte IP vor Kompression) in das VPN, das eine tun-mtu von 1500 aber eine link-mtu von über 1540 Byte haben wird, übertragen. Das ergibt an sich schon ein ungünstiges Verhältnis.

    Man könnte versuchen, das im VPN über eine Route-MTU zu lösen oder eben darauf zu achten, dass man die Fragmentgrößen besser wählt.

    Dass es sich um ein generelles Performance-Problem von pfSense handelt, würde ich jetzt einmal nicht vermuten. Sofern Verschlüsselung im Spiel ist, sollte man pfSense aber auf AES-NI-Unterstützung konfigurieren (/system_advanced_misc.php), damit es die Prozessorfeatures dafür nützt und nicht hier zusätzlich ein Flaschenhals geschaffen wird: pasted-from-clipboard.png

    Das geht natürlich nur insoweit, als das VPS diese Features auch durchreicht.

  • Um das nochmal kurz klarzustellen: Das Problem (bei mir) tritt dann auf, wenn ich ohne Upstream-VPN unterwegs bin. Also "kleine" Pakete. Mit Upstream-VPN (also den potentiell größeren Paketen, also dem höheren Risiko in ein MTU-Problem reinzurennen) ist es schnell.


    Falls das soweit verstanden ist, verstehe ich noch nicht, wie das mit der MTU in diesem Fall zum Problem werden kann.

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

  • Um das nochmal kurz klarzustellen: Das Problem (bei mir) tritt dann auf, wenn ich ohne Upstream-VPN unterwegs bin. Also "kleine" Pakete. Mit Upstream-VPN (also den potentiell größeren Paketen, also dem höheren Risiko in ein MTU-Problem reinzurennen) ist es schnell.

    Jetzt dachte ich mir: Das ist bestimmt voll der Umweg. Da ich selbst nicht auf das Uplink-VPN-Netzwerk zugreifen muss, kann ich mir per Client-Sonderregel ja ne feste IP zuweisen und der festen IP per Regel das Netcup-Gateway verpassen.

    Noch einmal zurück an diesen Punkt:

    Auf welche Weise bekommt die IP des Clients per Regel das Netcup-Gateway verpasst?

    a) Über die Firewall-Regel (Erweitert und folgendes Element:

    pasted-from-clipboard.png

    oder
    b) als von OpenVPN gepushte Route via:

    pasted-from-clipboard.png


    Im Fall, dass Du in pfsense innerhalb der NAT-Regel ein gateway zuweist, kommt es nach meiner Erfahrung mit an Sicherheit grenzender Wahrscheinlichkeit zu asymmetrischen Routen. Du siehst dann im Traceroute auch nicht, welchen Umweg das Paket vor dem Verlassen der pfSense nimmt, weil diese Hops im Traceroute nicht erkennbar sind.


    Du kannst Deinem OpenVPN-Client zur Übersteuerung der Default-Route zwei Halfnets (0.0.0.0/1 und 128.0.0.0/1) als spezifischere Routen pushen, sodass dieser Traffic die regulären Filterregeln durchläuft. Wenn dann immer noch ein Performance-Problem besteht, schauen wir uns das VPN im Detail an.

  • Moin,


    per in b) genannter Client-Konfiguration gebe ich einem der Clients eine fest IP-Adresse. Alle anderen erhalten IP-Adressen aus dem Pool. Alle Clients bekommen die selben Routen (incl. default) gepushed.


    Firewall-Regeln:


    In der Firewall-Konfiguration kommt zuerst eine Regel, die auf die spezifische (Absender-)IP-Adresse prüft. In den Firewall-Regel-Einstellungen ist kein explizites Gateway konfiguriert, es wird daher das Standard-Gateway (WAN Richtung Netcup) verwendet.

    Als nächstes kommt eine Regel, die auf alle (bisher unmatched) Pakete zutrifft und dann wie in a) beschrieben explizit das Gateway auf das Upstream-Gateway setzt.


    Warum möchte ich die Default-Route übersteuern (die funktioniert ja - mein Client-Traffic kommt ja bei der pfSense an)? Ich verstehe, was diese Routen machen, aber nicht, warum mir das helfen könnte (aktuell sehe ich keine Kollision). Oder setzt die in a) genannte Firewall-Regel nochmal ne neue Route?


    Viele Grüße
    Matthias

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

  • Warum möchte ich die Default-Route übersteuern (die funktioniert ja - mein Client-Traffic kommt ja bei der pfSense an)? Ich verstehe, was diese Routen machen, aber nicht, warum mir das helfen könnte (aktuell sehe ich keine Kollision). Oder setzt die in a) genannte Firewall-Regel nochmal ne neue Route?

    Der Sinn, einen Gateway in der Route zu setzen, erschliesst sich dafür mir nicht. Wann immer ich das in pfSense seit 2.1.x gemacht habe, gab es irgendwo Probleme. Filter ohne Gateway, Advanced Manual Outbound NAT und explizite NAT-Regeln auf die Schnittstellenadresse waren für mich stets zuverlässiger. Aufgrund der statisch vergebenen Client-Adresse sollte das leicht machbar sein. (Client an !RFC1918 via WAN).

  • Hallo,


    in meinem Setup habe ich gestern noch eine Beobachtung gemacht.

    Ich teste bisher immer per HTTP/HTTPS. Der Traffic scheint pro Session auf etwa 30-40KB/s limitiert zu sein. Wenn man mehrere Sessions startet, liegt jede Session bei 30-40 KB/s

    Mit einem Download-Manager, der die Downloads in mehrere Sections aufteilt, schaffe ich den Downstream meines DSL-Anschlusses auszulasten.


    Eine MTU-Problematik oder asymetrisches routing müsste sich nach meinem Verständnis auf den Verkehr insgesamt auswirken, unabhängig von der Anzahl der Sessions.


    Ich teste in den nächsten Tagen mal mit anderen Protokollen.