2
OPNsense Spurious Retransmissions zu einer Website
Hallo,
ich beobachte mal wieder ein echt seltsames Problem. Erst dachte ich schon das es an der Gegenstelle liegt, bis mir auffiel das über Mobilfunk alles wunderbar klappte. Ich habe zwei Standorte hier, jeweils mit OPNsense-HA. Bei beiden kann ich eine bestimmte Website nicht erreichen. Die Website ist ein CPanel was frisch installiert wurde und befindet sich bei einem Hosting-Provider.
Firefox sagt nach ewigen gerödel: PR_CONNECT_RESET_ERROR
Mit Wireshark, sehe ich viele TCP Retransmissions bei den Antwort-Paketen, teilweise Spurious Retransmissions. Mittlerweile kann ich es auf die OPNsensen eingrenzen. Auf den internen als auch externen Interfaces sind keine Fehler, kein Packetloss, keine In/Out Errors. Am Layer3-Switch jeweils an beiden Standorten an den entsprechenden Interfaces, keine Fehler.
Jetzt habe ich das Hardware Checksum Offloading im Verdacht. Das habe ich auf dieser Hardware schon weit über einem Jahr im Einsatz und da funktioniert es bisher tadellos. Da ist sowas noch nie aufgefallen. Komisch ist auch das es nur mit dieser bestimmten Website auftritt.
Hardware ist: https://www.supermicro.com/de/products/motherboard/x11sdv-4c-tp8f
Meine zweite Vermutung: Die internen Netzwerkschnittstellen der Sensen leiten die Pakete nicht schnell genug weiter. Deshalb werden sie im Wireshark als spurious makiert. Die Frage wäre, wie kann man das optimieren?
Jemand eine Idee?
Grüße
ich beobachte mal wieder ein echt seltsames Problem. Erst dachte ich schon das es an der Gegenstelle liegt, bis mir auffiel das über Mobilfunk alles wunderbar klappte. Ich habe zwei Standorte hier, jeweils mit OPNsense-HA. Bei beiden kann ich eine bestimmte Website nicht erreichen. Die Website ist ein CPanel was frisch installiert wurde und befindet sich bei einem Hosting-Provider.
Firefox sagt nach ewigen gerödel: PR_CONNECT_RESET_ERROR
Mit Wireshark, sehe ich viele TCP Retransmissions bei den Antwort-Paketen, teilweise Spurious Retransmissions. Mittlerweile kann ich es auf die OPNsensen eingrenzen. Auf den internen als auch externen Interfaces sind keine Fehler, kein Packetloss, keine In/Out Errors. Am Layer3-Switch jeweils an beiden Standorten an den entsprechenden Interfaces, keine Fehler.
Jetzt habe ich das Hardware Checksum Offloading im Verdacht. Das habe ich auf dieser Hardware schon weit über einem Jahr im Einsatz und da funktioniert es bisher tadellos. Da ist sowas noch nie aufgefallen. Komisch ist auch das es nur mit dieser bestimmten Website auftritt.
Hardware ist: https://www.supermicro.com/de/products/motherboard/x11sdv-4c-tp8f
Meine zweite Vermutung: Die internen Netzwerkschnittstellen der Sensen leiten die Pakete nicht schnell genug weiter. Deshalb werden sie im Wireshark als spurious makiert. Die Frage wäre, wie kann man das optimieren?
Jemand eine Idee?
Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 72932391391
Url: https://administrator.de/forum/opnsense-spurious-retransmissions-zu-einer-website-72932391391.html
Ausgedruckt am: 22.12.2024 um 03:12 Uhr
2 Kommentare
Neuester Kommentar
Moin.
läuft die auf der Hardware virtualisiert?
Ansonsten schau dir mal die Firewall Normalization/Interface scrub Settings an, die Sensen greifen da wenn aktiv teilweise in den Packet-Flow ein was bei manchen Endpoints zu solchen Effekten führen kann.
https://docs.opnsense.org/manual/firewall_scrub.html
Gruß.
läuft die auf der Hardware virtualisiert?
Ansonsten schau dir mal die Firewall Normalization/Interface scrub Settings an, die Sensen greifen da wenn aktiv teilweise in den Packet-Flow ein was bei manchen Endpoints zu solchen Effekten führen kann.
https://docs.opnsense.org/manual/firewall_scrub.html
Gruß.
1
Ok, habe es herausgefunden. Lag tatsächlich nicht an der OPNsense und läuft auch nicht virtualisiert. Die Verzögerung kam durch die Gegenstelle. Dort läuft ein BGP mit Multipath und das hat manche Antwort-Pakete auf andere längere Pfade geschickt. Im Endeffekt konnte das nur behoben werden, in dem man das in eine separate DMZ mit stinknormalem VRRP verbannt hat. Die einfachen Dinge sind halt meistens doch immer noch die besten Lösungen.
