Connection Loss - VLAN Routing und OpenVPN Probleme

[Oxygen61]

Also irgendwie .... läufts immer noch nicht. Gerade war wieder ein riesen VPN abfuck, der sich dann garnicht als VPN abfuck herrausstellte, als ich nachschaute wie die Latenzen sind und alles okay war beim VPN...

Beim Switch ging das Interface das zum VLAN Laptop geht (an dem ich Videos schau) 100 mal Up und Down

Die Firewall meldete mir 2000(!) Out Errors in Richtung VLAN Rechner2 und 2000(!) Out Errors in Richtung VLAN NAS zu dieser Zeit. Außerdem hatte die Firewall versucht WLAN DNS Traffic zum VLAN Laptop Subnetz zuschicken, anstatt an das Interface der Firewall im selbigen Subnetz....

Packetfilter Daemon neustarten brachte nichts.
Ich hatte dann die Firewall rebootet...
Jedoch hatte er dann angefangen HTTP und HTTPs Traffic zu blockieren in allen Subnetzen, bis ich auch hier wiedermal den Packet Filter Deamon neustartete. Dann funktionierte wieder alles.

Das ist echt kein Zustand und ich hab schon soviel getroubleshootet, dass ich den Überblick verloren habe woran es noch liegen könnte...

Ich kann nicht ausschließen, dass die Netzwerkkarte vom Laptop kaputt ist, besonders weil der auch schon 4-5 Jahre alt ist. Das wird dann wohl das nächste sein, das Teil durch einen neuen zu ersetzen um auch diese Fehlerquelle auszuschließen.

Gerade läuft wieder alles ruhig... spätestens diese Woche kann ich dann auch aber endlich schon mal sagen, ob das VPN die Verbindung zum NAS beeinträchtigt. OpenVPN ausschalten um den Fehler zu provozieren kann ich nur ganz selten machen, da immer wer im Netzwerk sitzt und irgendwas macht.

Könnt mich nur noch aufregen... man man man..  :-[

Schöne Grüße
Oxy

[NilsS]

kannst du mal gucken ob du sowas

Code Select Expand


OPNsense kernel: sonewconn: pcb 0xfffff800450ed870: Listen queue overflow: 2 already in queue awaiting acceptance (1 occurrences)

im systemlog hast?

Hab eigentlich den ganzen Offloading Kram ausgehabt (außer VLAN)
hab jetzt alles aus.
Ich hab (gefühlt seit 17.7.5?) da öfters Probleme das nix mehr geht an TCP Traffic.
OpenVPN (UDP) zur OPNsense geht ohne Probleme, aber z.B. nicht auf die GUI oder per SSH.
Geht aus allen Netzen nicht.
Werde die Tage mal auf Intel wechseln, ist derzeit ne Realtek.
Du hast AFAIR ja aber eh ein Intel Board mit Intel NICs oder?
Wäre interessant ob da beim Ausfall irgendwas im Systemlog steht.

[Oxygen61]

Hi NilsS,

tut mir Leid aber diesen Fehler hab ich im Log noch nie gesehen und ich gucke JEDES mal da rein um zu schauen,
was ihm denn nicht gefällt am System.
Meine Fehlermeldungen sind ausschließlich VPN Down, Failover Group Down und WAN Reload Meldungen wenn etwas schief geht.
Aber ja habe auch das Gefühl, dass der TCP Traffic generell viel problematischer ist als der UDP Traffic.
Nach einem WAN Reload oder Firewall Neustart spinnt der Packet Filter bei mir komplett.
Beim WAN Reload habe ich, auch im Bezug auf das NAS VLAN, dann immer beobachten können, dass der "Antwort-TCP Traffic" zurück zum User VLAN geblockt wird warum auch immer.
Da versucht dann die NAS auf TCP port 445 (als Source-Port wohl gemerkt)
in das User VLAN zurückzuschicken auf Destination-Port irgendwas über 10000+.
Das kam mir schon sehr ulkig vor bei einer Stateful Packet Inspection Firewall wie OPNsense.
Die Session wird ausschließlich beim User gestartet und die Antwort sollte ihren Weg von selber finden. (Anscheinend falsch gedacht)

Nach der NAT -Umstellung und den paar Häkchens, bei denen du meintest dass ich die setzen sollte, scheint nach einem WAN/VPN Down aber jetzt zu mindestens nicht mehr der Traffic auszufallen beim Streaming.
Zu mindestens hat seitdem keiner mehr gemeckert. Das scheint also irgendwie schon richtig gewesen zu sein.

Folgendes ist bei mir angehakt:

Code Select Expand

Kill states [X] Disable State Killing on Gateway Failure
Skip rules [X] Skip rules when gateway is down
Gateway switching [X] Allow default gateway switching
Sticky connections [ ] Use sticky connections
Shared forwarding [X] Use shared forwarding between packet filter, traffic shaper and captive portal
Disable force gateway [ ] Disable automatic rules which force local services to use the assigned interface gateway.

Das Disable Force Gateway hab ich mir noch aufgehoben, als nächsten Schritt, falls das Problem mit dem fehlerhaften Routing schlimmer geworden wäre.

Trotzdem gefällt mir das gar nicht, wie die Firewall sich verhält, wenn das WAN neu geladen werden muss, wenn die VPN Failover Group ausfällt. Schade auch, dass ein Neustart anscheinend nur alles schlimmer macht.

Wobei ich sagen muss, dass die Out Errors und Packet Filter Probleme bei einem Neustart neu für mich sind.
Arrangiert hatte ich mich mit NTP und dem Status des Apinger, der nach einem Restart der Firewall immer nochmal extra neugestartet werden musste um zu funktionieren.

Rein Hardware technisch bin ich aber sehr zufrieden mit diesem Schmuckstück:
http://www.lannerinc.com/products/x86-network-appliances/x86-desktop-appliances/fw-7525
Dort sind alle NICs Intel NICs. Das war mir damals beim Kauf ganz wichtig, weil ich schon ganz am Anfang von OPNsense immer von Problemen hörte, die nur dadurch zustande kamen, weil keine Intel NICs genutzt wurden.
Mit Intel NICs bist du bei den *sensen auf jeden Fall auf der sicheren Seite.

Schöne Grüße
Oxy

Wenn ich nach "OPNsense Kernel:" im Log suche ist Das das einzige was er findet:

Code Select Expand


Oct 31 18:27:36 kernel: igb1: Interface stopped DISTRIBUTING, possible flapping
Oct 31 18:27:36 kernel: igb3: Interface stopped DISTRIBUTING, possible flapping
Oct 31 18:27:36 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping
Oct 31 18:27:36 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping
Oct 31 14:26:09 kernel: igb1: Interface stopped DISTRIBUTING, possible flapping
Oct 31 14:26:09 kernel: igb3: Interface stopped DISTRIBUTING, possible flapping
Oct 31 14:26:09 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping
Oct 31 14:26:09 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping
Oct 30 22:02:20 kernel:
Oct 30 22:02:20 kernel:
Oct 30 22:02:20 kernel:
Oct 30 22:02:20 kernel:
Oct 30 22:02:20 kernel:
Oct 30 22:02:18 kernel: OK
Oct 30 22:02:17 kernel: config_aqm Unable to configure flowset, flowset busy!
Oct 30 22:02:17 kernel: Bump sched buckets to 256 (was 0)
. . . .
. . . .
usw.


Bei "sonewconn:" no result

[Oxygen61]

Heute kompletten Ausfall des Internets gehabt ab knapp 10 Uhr.
Konnte jedoch nicht handeln, weil ich auf Arbeit war.
Interne Verbindungen zur NAS z.b. funktionierten noch.

Zuhause angekommen sehe ich, dass mein WAN Gateway bei 100% Paket Loss eingefroren war und die VPN Interfaces auch alle Down waren.
"Renew" hatte beim WAN_DHCP Interface nicht geklappt. Erst nach einem Reboot ging es wieder.

Im Log is wie immer alles voll damit, dass das Failover kein Gateway mehr hat und down ist
"Reloading Filter" wird dann immer ausgeführt.

Bezüglich des WANs gibt es ein paar spannende Log Einträge, die mir aber nicht weiterhelfen:

Code Select Expand

Nov  2 10:50:40 OPNsense kernel: igb0: link state changed to DOWN
Nov  2 10:50:40 OPNsense configd.py: [---------------------------] Linkup stopping igb0
Nov  2 10:50:40 OPNsense opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan
Nov  2 10:50:40 OPNsense opnsense: /usr/local/etc/rc.linkup: Clearing states to old gateway <WAN IP>.
Nov  2 10:50:40 OPNsense kernel: arpresolve: can't allocate llinfo for <WAN IP> on igb0
. . . .
Nov  2 10:52:49 OPNsense configd_ctl.py: error in configd communication  Traceback (most recent call last):   File "/usr/local/opnsense/service/configd_ctl.py", line 65, in exec_config_cmd     line = sock.recv(65536) timeout: timed out

Die Failover Group geht im Sekunden Takt down und wieder UP laut dem Log.
Vielleicht ist auch das Modem hinüber. Das werde ich vielleicht mal auswechseln, einfach um auf der sicheren Seite zu sein.

Ein paar Dinge die ich noch gern geklärt hätte @NilsS
Bei dem Failover hab ich "WAN" mit dem Tier "Never" ausgestattet, währen die VPN Interfaces jeweils Tier 1, 2 oder 3 sind ..... ist das richtig oder muss WAN dabei sein?

Ich hatte gelesen, dass man den VPN Interfaces statische Monitor IP's geben muss fürs Failover wie z.b.: 8.8.8.8 oder 8.8.4.4, weil man da dann sicher sein kann, dass die Server immer online sind zum überprüfen. Wie hast du das mit dem Monitoring gelöst?

Schöne Grüße
Oxy

[Oxygen61]

Gerade noch ein paar Änderungen gemacht und das Log ist erschreckend ruhig geblieben.  :o

1. Die Externen IP's als Monitor IP's der VPN Gateways entfernt.
Wenn Das VPN Gateway z.b. die IP 10.2.70.1 hat, dann ist jetzt auch die Monitor IP 10.2.70.1

2. In den advanced Settings der drei VPN Clients folgendes hinzugefügt:

Code Select Expand

route 0.0.0.0 192.0.0.0 net_gateway
route 64.0.0.0 192.0.0.0 net_gateway
route 128.0.0.0 192.0.0.0 net_gateway
route 192.0.0.0 192.0.0.0 net_gateway

3. Bei Perfect Privacy in den Settings diese Einstellung entfernt:

Code Select Expand

Zufällige Ausgangs IP-Adresse benutzen
- Die meisten unserer VPN-Server besitzen mehrere IP-Adressen.
  Durch das Aktivieren dieser Option wird Ihnen bei jedem Verbindungsaufbau eine zufällige externe IP-Adresse
  zugewiesen.
  Diese Einstellung beeinflusst nur VPN Dienste,
  Proxy Server nutzen immer die Eingangs IP Adresse als Ausgangs IP Adresse.

*Drückt mir selber die Daumen* :D

[Oxygen61]

Notiz am Rande:

Da ich mir ziemlich sicher bin, dass die VPN Settings jetzt stimmen, ich aber trotzdem connection losses hatte und Verbindungsabbrüche zur NAS, während meine Gateways reloaden, habe ich alle Einstellungen die ich je für das VPN machte zurückgesetzt.
Ich habe also fast alles auf Default, mit WAN als Default Gateway ohne VPN, ohne Failover oder dergleichen und trotzdem Verbindungsabbrüche/Routing Errors zur NAS, wenn das WAN Interface neustartete.

Das habe ich tatsächlich in den Griff gekriegt indem man "Skip Rules" und "Disable state Killing on Gateway Failure" anhakt.
Es lag also tatsächlich nie am VPN, sondern schlicht weg an diesem einen Setting. Wenn mein ISP wieder von seinen 50% connection loss runterkommt, bin ich mir ziemlich sicher, dass das VPN dann sauber und stabil läuft. :)

Dazu gibt es jetzt mittlerweile auch ein Ticket von mir bei Github:
https://github.com/opnsense/core/issues/1912

Schöne Grüße
Oxy