Probleme mir VLAN; Server hinter Firewall /NAT pfsense Download schnell upload langsam

    Hallo liebe Netcup-Community,


    ich habe folgendes Problem und hoffe jemand von euch hat ein ähnliches Setup mit einer Lösung oder eine Idee woran es liegen kann.


    Ich habe mehrere Server bei netcup mittels Cloud Vlan verbunden, die externen Nics habe ich alle deaktiviert, sodass die Server ausschließlich über das Vlan kommunizieren. Das Gateway ist ein Root-Server wo pfsense installiert ist worüber die Clients ins WAN gehen.


    Das Problem ist nun, dass wenn ich eine Datei über einen Server innerhalb des VLAN's (nicht auf den Server beschränkt verhalten bei 2 "VLAN Member" getestet) zum Beispiel per SSH über scp auf einen Server außerhalb des VLAN's uploade extrem die Geschwindigkeit einbricht und der Upload dann im kbit/s bereich liegt. Wenn ich allerdings vom selben Server eine Datei von einem externen Server herunterlade lädt er mit voller Geschwindigkeit. Wenn ich von außerhalb des VLAN (habe ich von einem Server bei h*er getestet) Dateien auf den Server per ftp hoch und runterlade bekomme ich ebenfalls die volle Geschwindigkeit.


    Den Upload von Server aus habe ich wie folgt getestet. Testdatei von irgendeinem Server heruntergeladen und dann per scp auf einen anderen Server geladen bei h*er wobei dann die Uploadgeschwindigkeit extrem einbricht. Merkwürdigerweise springt die CPU Last dann von einem der 4 Kerne auf 100%. Aber auch wenn ich das Kopieren über FTP probiere ist die Übertragungsgeschwindigkeit im Kbit Bereich und dabei ist die CPU nicht ausgelastet.

    Upload über FTP 9306112 bytes sent in 131.55 secs (69.0843 kB/s)

    Download: 9305900 bytes received in 0.87 secs (10.1681 MB/s)


    Aufgrund von Hinweisen die ich im Netz gefunden habe habe ich folgende Settings in PF-Sense vorgenommen was aber auch nicht geholfen hat:

    Disable hardware checksum offload

    Disable hardware TCP segmentation offload

    Disable hardware large receive offload


    Habt ihr eine Idee woran das liegen könnte?


    Viele Grüße

    Dominik

    Hallo gunnarh,


    danke für die schnelle Rückmeldung. Habe die MTU auf dem LAN Interface der Pfsense und auf dem Server auf 1300 gesetzt. Allerdings tritt das Problem leider weiterhin auf. Wenn ich per FTP etwas vom Server hochlade bekomme ich lediglich Datenraten von ein paar kbit/s.

    Was mich auch wundert ist, dass der Download von dem betroffenen Server bei netcup von meinem Heimrechner auch ewig langsam ist aber von meinem h*er Server der Download schnell ist.

    Habe getestet indem ich die Datei http://ganz-nach-oben.de/ubuntu.iso heruntergeladen habe.


    Viele Grüße

    Dominik

    Im SCP gibt es Optimierungseinstellungen für Linux, Windows und BSD. hast du das schonmal getestet?

    Welche Art von Servern sind denn hier beteiligt? Welchen Netzwerktreiber hast du gewählt?

    Hallo H6G,


    mein Gateway (PFSense) ist ein RS 1000 SSD G8. Dort habe ich bei Optimierungsmöglichkeiten lediglich Windows und Linux. Hier ist Linux ausgewählt.

    Ein betroffener Server welcher im VLAN hängt und über die PFSense ins Netz geht ist ein RS 2000 SAS G8 mit Ubuntu 18.04. Hier ist ebensfalls bei Optimierungen für Linux ausgewählt. Netzwerktreiber ist bei allen beteiligten VMs auf virtio eingestellt.


    Viele Grüße

    Dominik

    Quote from H6G

    der Server hinter der Domain blockiert ICMP auf IPv4

    Habe ich gerade mal korrigiert. Jetzt kann man den Server auch über v4 pingen. Es ist ja nicht nur ein eingehendes Problem. Wenn ich von dem Server aus Daten per SSH oder FTP hochlade bekomme ich auch nur ein paar kbit/s Übertragungsrate.

    Quote from Doim1990

    Habe ich gerade mal korrigiert. Jetzt kann man den Server auch über v4 pingen. Es ist ja nicht nur ein eingehendes Problem. Wenn ich von dem Server aus Daten per SSH oder FTP hochlade bekomme ich auch nur ein paar kbit/s Übertragungsrate.

    Sehr gut: über IPv4 bekomme ich jetzt eine hohe Geschwindigkeit, über IPv6 eine niedrige.

    Jagst du IPv6 durch einen Proxy oder direkt? Welcher Proxy wird verwendet?
    Wie sieht die IPv6 Firewall aus?

    Ich habe in der PFSense mein geroutetes IPv6 Subnetz hinterlegt wo die einzelnen Adressen dann per DHCPv6 an die "VLAN Clients" verteilt werden. Bzw. habe in der PFSense für den Server die IP Statisch im DHCP festgelegt damit immer dieselbe IP vergeben wird. Habe dann aber die IP zusätzlich nochmal statisch auf dem ubuntu Server eingerichtet. Die PFSense ist dann zusätzlich noch eine IPv6 Firewall. Allerdings sind die selben Ports in der Firewall für ipv4 und ipv6 freigegeben.

    Hallo H6G,


    habe das ganze auch nochmal ausgehend mit ipv4 getestet. Tatsächlich scheinen nur ipv6 Verbindungen betroffen zu sein, bei ausgehenden ipv4 Verbindungen tritt das geschilderte Problem nicht auf, bei ipv6 ein und ausgehend ist die Verbindung sehr langsam.


    Viele Grüße

    Dominik

    Hallo vmk,


    eingehend kann ich den Server pingen und ausgehend kann der Server auch pingen:


    Ping wird ausgeführt für ganz-nach-oben.de [2a03:4000:20:14b:b475:8481:99b9:d4fc] mit 32 Bytes Daten:

    Antwort von 2a03:4000:20:14b:b475:8481:99b9:d4fc: Zeit=40ms


    ping6 google.de

    PING google.de(fra16s42-in-x03.1e100.net (2a00:1450:4001:809::2003)) 56 data bytes

    64 bytes from fra16s42-in-x03.1e100.net (2a00:1450:4001:809::2003): icmp_seq=1 ttl=56 time=4.32 m


    Viele Grüße

    Dominik

    Was mich allerdings auch wundert, ist dass ich in PFSense unter Status / System Logs / Firewall lediglich ipv4 Einträge sehe und keine ipv6 Verbindungen. Allerdings kann ich die States sehen.


    Meiner PFSense Router VM ist folgendes ipv6 Subnet zugewiesen: 2a03:4000:32:8f::/64

    Anschließend habe ich mir ein geroutetes ipv6 Netz zusätzlich geordert damit ich dieses den Servern innerhalb des V-Lans zuweisen kann 2a03:4000:20:14b::/64

    Im Reiter Netzwerk steht folgendes:


    2a03:4000:32:8f::/64 Gateway / Routing auf fe80::1

    2a03:4000:20:14b::/64 Gateway / Routing auf 2a03:4000:32:8f:58a2:40ff:fea3:e0c2


    Habe der PF-Sense auf dem Interface WAN die IP 2a03:4000:32:8f:58a2:40ff:fea3:e0c2 zugewiesen mit dem Gateway fe80::1

    Im LAN interface habe ich der PF-Sense die IP 2a03:4000:20:14b::1 zugewiesen und per DHCP v6 Server & RA wird das 64er Subnetz an die angeschlossenen Server verteilt.

    Moin,


    gab es zu diesem Thema noch eine Lösung?

    Ich habe das gleiche Problem wenn ich pfSense einsetze ist die Bandbreite sehr begrenzt über das CloudVLAN


    VG
    Henning

    Hallo zusammen,


    mein Problem ist vergleichbar -

    Setup:
    - OpnSense als Firewall
    - 100 MBit/s CloudVLAN - innerhalb des VLANs kommt lediglich IPv4 zum Einsatz
    - Debian-Server hinter der Firewall innerhalb des VLANs

    Getestet habe ich verschiedene Punkte:
    - Up- und Download-Raten vom Server durch die OpnSense -> ~90 MBit/s up&down
    - Up- und Download-Raten über das WAN-Interface vom Server (habe es testweise aktiviert) -> ~90 MBit/s up&down

    Also an sich super Werte...

    Aber:
    Mittels iPerf3 komme ich zwischen dem Linux-Server und der OpnSense lediglich auf eine Bandbreite von 100 Kbit/s

    Die MTU ist auf dem LAN-Interface bei der OpnSense auf 1500 eingestellt. Beim Debian-Server genauso.
    Wechsele ich die MTU auf beiden System zu 1300 (und MSS bei der OpnSense auf 1200), fällt die Bandbreite auf ~70 Kbit/s

    Willkommen in ISDN-Zeiten... ;)

    Erklären kann ich mir das nicht wirklich.
    Besonders interessant ist die Tatsache, dass Upload- und Downloadrate durch die Firewall hindurch sehr gut sind.


    Falls jemand auf ähnliche Probleme stößt, noch ein paar Tipps zu iPerf3.
    1. Ist als Plugin auf der OpnSense problemlos installierbar. Findet sich dann unter Interfaces > Diagnostics > iPerf
    2. Auf Linux-System idR schnell per Paket-Manager installiert (z.B. apt install iperf)
    3. Auf einem System einen iPerf-Server starten: iperf -s (dort erhält man einen Port angezeigt)
    4. Auf dem anderen System den iPerf als Client starten: iperf -c [ip-adresse-vom-server] -p [vom-server-angezeigten-port]

    ----

    Jedenfalls habe den Support heute dazu schon angerufen. Man verwies darauf, dass ich bitte einmal im Forum nachhaken soll, ob auch andere Kunden dieses Problem haben bzw. was noch getestet oder analysiert werden könnte. Falls ich hier nicht weiter kommen sollte, soll ich ein Ticket beim Support erstellen.


    Liebe Community, habt ihr dazu eine Idee?
    Welche Informationen könnt ihr zwecks Analyse gebrauchen?

    Viele Grüße
    Volker

    Quote from mindtec

    Erklären kann ich mir das nicht wirklich.
    Besonders interessant ist die Tatsache, dass Upload- und Downloadrate durch die Firewall hindurch sehr gut sind.

    Offloading trotz VM aktiviert? Oder Offloading ohne virtio? TCP Checksums?

    Warum setzt Du die MSS um 100Byte kleiner als die MTU - anstelle von 60 (TCP/IPv4) oder 80 (TCP/IPv6)?

    Hi eripek,


    Danke für Deine Antwort und Rückfragen - auf letztere gehe ich weiter unten ein.

    Vorweg: das Problem ist in meinem Fall gelöst.

    Ablauf:
    Ich hatte gestern nochmal den Support angeschrieben und auch auf diesen Thread verwiesen. Heute morgen kam die Frage vom Support, welche Server betroffen seien. Parallel hatte ich die Performance im VLAN nochmal getestet und war bei 100 Kbit/s. Im Laufe des Nachmittags kam die Meldung vom Support, dass sie auf dem betreffenden Hostsystem keine Performance-Probleme feststellen können und hatten auch einen iperf-Log mitgeschickt:


    Ich habe dann direkt nochmal die Performance geprüft und kam auf sehr gute Werte:

    Code
    iperf3 -c [server-ip] -p [server-port]

    An den Systemeinstellungen hatte ich seit meinem Beitrag in diesem Thread nichts mehr geändert.

    Zu Deinen Fragen:

    Quote

    Offloading trotz VM aktiviert? Oder Offloading ohne virtio? TCP Checksums?

    Warum setzt Du die MSS um 100Byte kleiner als die MTU - anstelle von 60 (TCP/IPv4) oder 80 (TCP/IPv6)

    - Offloading ist bei OpnSense scheinbar schon per default deaktiviert - hatte die Einstellungen aufgrund dieses Threads schon gestern geprüft und sie waren schon deaktiviert, obwohl ich vorher nichts dran gedreht habe.

    Siehe auch: https://imgur.com/a/vt4tAMD

    - Als Netzwerk-Interface ist auf beiden betreffenden Systemen "virtio" aktiviert

    Zum Thema MTU vs. MSS:
    Hier hast Du mich kalt erwischt... ich habe tatsächlich kein Verständnis davon und habe Werte nur nach dem Try&Error-Prinzip ausprobiert.
    In der Vergangenheit bin ich diesbezüglich auch noch nie in Sachen Performance auf Probleme gestoßen. Daher vielen Dank für den Hinweis.

    Ich habe mir folgenden verständlichen Artikel zu Gemüte geführt und verstehe nun mehr: https://www.elektronik-kompendium.de/sites/net/0812211.htm

    Aus dem Artikel entnommen:


    Code
    ping -c 1 -s $((1500-28)) -M do [ip-von-anderem-host]
    Quote

    PING 192.168.1.1 (192.168.1.1) 1472(1500) bytes of data.

    ping: local error: Message too long, mtu=1400


    Die fürs VLAN bei Netcup optimale MTU scheint also bei 1400 zu liegen.

    Quote from mindtec

    Die fürs VLAN bei Netcup optimale MTU scheint also bei 1400 zu liegen.


    Hmm... VLAN bei Netcup wird über VxLAN realisiert. Das ist eine Verkapselung in UDP, die 8 Byte hinzufügt, wenn ich nicht irre. Wenn dieser Header nicht außen „aufgeschlagen“ wird, verringert sich das Paket also um 8 Byte Nutzlast - das wären dann 1464 Byte oder 1492 Byte MTU und einer MSS von 1432.

    Man korrigiere mich, wenn ich irre.


    Wenn Du einen „local error“ siehst, dann ist bereits der Host, von dem der Test ausgeht, in der MTU beschränkt. Über den Zielhost sagt das noch nichts aus.


    Danke für die unerwartete Rückmeldung!

    Ich habe nun die MTU 1492 getestet und erhalte dadurch nach wie vor super Werte.

    Ursprünglich hatte ich auf der FW und auf dem Server als MTU 1400 auf dem jeweiligen LAN-Interface eingestellt. Wenn ich nun mit einer höheren Paketgröße gepingt habe, kam die Meldung "local error".


    Nach dem Hochschrauben auf die MTU 1492 geht die Paketgröße 1464 Byte jedoch problemlos durch - alles darüber hinaus nicht mehr.

    Quote

    Wenn Du einen „local error“ siehst, dann ist bereits der Host, von dem der Test ausgeht, in der MTU beschränkt. Über den Zielhost sagt das noch nichts aus.

    Da es offenbar auch an den Einstellungen der VMs hängt (wie gerade durch die Einstellungsänderung getestet), bin ich mir nicht sicher, ob die Beschränkung bereits durch den Host kommt bzw. die Fehlermeldung dadurch ausgelöst wird.

    Quote from mindtec

    Ursprünglich hatte ich auf der FW und auf dem Server als MTU 1400 auf dem jeweiligen LAN-Interface eingestellt. Wenn ich nun mit einer höheren Paketgröße gepingt habe, kam die Meldung "local error".

    Warum eigentlich?

    Die Standard-MTU in Ethernet-Netzwerken beträgt üblicherweise 1500. Zur Erkennung einer geringeren MTU gibt es die pMTUd (path MTU discovery), die ebenso wie Dein manueller Test mit Don't Fragment Ping über ICMP Typ 2 (message too big) die Maximalgröße einer Übertragung ermittelt.

    Dieser Mechanismus versagt nur, wenn man ICMP komplett und damit echo replies und message too big blockt.
    „local error“ sagt eigentlich schon, was Sache ist: Das lokal generierte Paket ist größer, als das Interface es zulässt.

    (OpenVPN ist in manchen Versionen auch bei funktionierendem ICMP störisch).