OPNsense verbindungs Issues

[guest50771]

Hi zusammen,

ich habe seit zwei Tagen eine virtualisierte OPNsense im Einsatz.

Die Virtualisierungsumgebung ist Proxmox, dort habe ich alles normal eingerichtet – das sollte passen. Die Netzwerkkarte reiche ich im RAW-Modus direkt an die VM durch, sodass Proxmox hier nicht ,,dazwischenfunken" kann.

Das generelle Setup sieht wie folgt aus:
Auf dem Dach habe ich ein Mikrotik ATL18LTE, welches die Internetverbindung bereitstellt. Diese Verbindung reiche ich per MAC-Match direkt an die OPNsense durch. Dazwischen befindet sich noch ein Switch, da ich im beruflichen Umfeld bei direkter Verbindung schon mehrfach Negotiation-Fehler erlebt habe. Der Switch hat die beiden Ports in einem portbasierten VLAN konfiguriert.

Die Netzwerkkarte ist eine HP NC365T.

Mein Problem:
Nach einiger Zeit (unbestimmter Zeitraum) funktionieren normale Webbrowser-Anwendungen nicht mehr richtig. Man kann weiterhin erfolgreich pingen und die DNS-Auflösung klappt auch, aber ein Traceroute kommt in vielen Fällen nicht durch. Normale Webseiten laden in dieser Phase gar nicht. Nach kurzer Zeit stabilisiert sich alles wieder und funktioniert problemlos.

Interessanterweise läuft beispielsweise ein Musik-Stream während dieser Ausfälle weiter – vermutlich, weil der State bestehen bleibt.

Was ich bisher versucht habe:

    Änderungen an der Buffersize.
    Den State von ,,normal" auf ,,conservative" umgestellt.
    Weitere kleinere Anpassungen, die jedoch keinen Erfolg gebracht haben.

Ich bekomme das System einfach nicht stabil hin. Die Netzwerkkarte selbst hat kein Problem, da ich mit iPerf stundenlang ohne Paketverlust Daten durchschaufeln kann.

Meine Vermutung:
Ich denke, es könnte etwas mit der MTU-Einstellung zu tun haben. Allerdings steht alles auf ,,Negotiation", sodass die Geräte die Parameter eigentlich automatisch aushandeln sollten.

Hat jemand eine Idee, wie ich dieses Problem beheben kann?
Im Log sehe ich leider keine Hinweise auf die Ursache.
Viele Grüße

[pioneer10]

Ich hatte ähnliche Probleme (siehe Tread von gestern hier im Forum), bei dem ich anscheinend vollkommen wirkürlich Verbindungsprobleme hatte, die aufgetaucht und nach einer Zeit wieder verschwunden sind und die Logs in der OPNsense nichts angezeigt haben,

Es stellte sich heraus, das ich ein IP-Adresskonflikt im Netzwerk hatte. Eventuell ist das ja bei dir ähnlich.

[vpx]

Nur um ein paar Informationen hinzuzufügen: Es handelt sich wohl um einen Intel Ethernet Server Adapter I340-T4 bzw. PRO/1000 PT, entsprechend dann ein Intel 82580 oder 82571 Controller-Chipsatz. Werden beide offiziell vom em(4) Treiber unterstützt.

https://man.freebsd.org/cgi/man.cgi?em(4)
https://www.reddit.com/r/PFSENSE/comments/juvvu4/conflicting_chip_info_on_intel_hp_nc365t_vs/

Letzterer ist aber deutlich älter und könnte für ein Hardware-Problem sprechen.

https://www.intel.de/content/www/de/de/products/sku/41280/intel-82580eb-gigabit-ethernet-controller/specifications.html
https://www.intel.de/content/www/de/de/products/sku/20720/intel-82571eb-gigabit-ethernet-controller/specifications.html

[meyergru]

Die Idee, die Netzwerkkarte durchzureichen, kann - je nach Anwendungsfall - nicht so gut sein, speziell, wenn der FreeBSD-Treiber problematisch ist.

[guest50771]

Hi Zusammen,

Die Idee, die Netzwerkkarte durchzureichen, kann - je nach Anwendungsfall - nicht so gut sein, speziell, wenn der FreeBSD-Treiber problematisch ist.

danke für die hilfe bisher ich versuche es gerade mal mit dem virtio driver von Proxmox und schau wie stabil das ganze jetzt läuft :D

Ich hatte ähnliche Probleme (siehe Tread von gestern hier im Forum), bei dem ich anscheinend vollkommen wirkürlich Verbindungsprobleme hatte, die aufgetaucht und nach einer Zeit wieder verschwunden sind und die Logs in der OPNsense nichts angezeigt haben,

Es stellte sich heraus, das ich ein IP-Adresskonflikt im Netzwerk hatte. Eventuell ist das ja bei dir ähnlich.

Den IP-Addresskonflikt kann ich eig. ausschließen denn dann würde der dhcp von vodafone der mir die CGNAT addr gibt kaputt sein oder zumindest nicht das tun wozu er da ist.

Nur um ein paar Informationen hinzuzufügen: Es handelt sich wohl um einen Intel Ethernet Server Adapter I340-T4 bzw. PRO/1000 PT, entsprechend dann ein Intel 82580 oder 82571 Controller-Chipsatz. Werden beide offiziell vom em(4) Treiber unterstützt.

https://man.freebsd.org/cgi/man.cgi?em(4)
https://www.reddit.com/r/PFSENSE/comments/juvvu4/conflicting_chip_info_on_intel_hp_nc365t_vs/

Letzterer ist aber deutlich älter und könnte für ein Hardware-Problem sprechen.

https://www.intel.de/content/www/de/de/products/sku/41280/intel-82580eb-gigabit-ethernet-controller/specifications.html
https://www.intel.de/content/www/de/de/products/sku/20720/intel-82571eb-gigabit-ethernet-controller/specifications.html

Ich habe laut der hardware info den CHIP 82580 bei meiner HP karte.
Wiederum habe ich das ganze auch baremetal versucht gleiches spiel :D


Ich werde berichten wie es sich jetzt verhält mit proxmox virtio netzwerk adaptern

[guest50771]

Hi Zusammen,

also so wie es eben ausschaut ist es eher sogar noch eine verschlächterung wenn ich die karte nicht durchschleife in jeglicher hinsicht.

Die buffer size habe ich erhöht per sript beim start proxmox durchgepustet aber das hilft nix.

Ich kann alles machen und auf einmal weg :D

Update:

wenn ich ein tcpdump mache schmeißt der kernel extrem viel weg da liegt der fehler aber wenn ich das interface hernehme und eine ubuntu vm laufen lass und mir viele daten hole da ist es nicht so (es wird auf der ebene von proxmox gedropped).

Das verstehe ich nicht ganz dann kann es ja nur der mikrotik router sein aber wenn ich die firewall nicht verwende gehts internet normal und auch werden keine packete im großen stil gedropped :D

[guest50771]

Hi zusammen,

ich habe weiter recherchiert und glaube, dass ich eine mögliche Ursache gefunden habe.

Wenn ich ein tcpdump auf meinem Client-Gerät laufen lasse, sehe ich jede Menge TCP-Retransmissions und Dup-ACK-Flags. Das deutet darauf hin, dass beim Handshake eine andere Zeit (Timeout) vereinbart wurde, als tatsächlich eingehalten werden kann. Ich muss jetzt genauer untersuchen, wie ich das Problem beheben kann, aber das scheint definitiv die Ursache für die Verbindungsverluste zu sein – oder zumindest ein Symptom davon.

Hatte jemand von euch schon einmal ein ähnliches Problem?

Viele Grüße

[Patrick M. Hausen]

Wenn ich ein tcpdump auf meinem Client-Gerät laufen lasse, sehe ich jede Menge TCP-Retransmissions und Dup-ACK-Flags. Das deutet darauf hin, dass beim Handshake eine andere Zeit (Timeout) vereinbart wurde, als tatsächlich eingehalten werden kann.

TCP vereinbart keinen Timeout zwischen den beiden Endpunkten.