OPNsense Forum

International Forums => German - Deutsch => Topic started by: Oxygen61 on October 22, 2017, 01:11:54 am

Title: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: Oxygen61 on October 22, 2017, 01:11:54 am
Hallo Leute,

Hintergrund:
ich habe mal wieder VPN Probleme. (Oder immer noch? Oder immer wieder? :( )
In meinem Netzwerk ist per LACP die Verbindung von der Firewall zum "Core" Switch 4-fach Redundant.
An diesem Switch hängt ebenfalls über LACP 2-fach redundant mein NAS.
Weiterhin übernimmt die Firewall somit das Inter-VLAN-Routing zwischen den VLANs, die über das LAGG Interface getagged zum Trunk Port am HP 1920-24G Switch übertragen werden.
Laptop, Rechner, NAS, WLAN..... alles ist schön säuberlich per VLAN getrennt und per Firewall Rules geregelt.
Ich habe drei OpenVPN Verbindungen, die sich als Failover Group gegenseitig bei einem "member down" abwechseln sollen.

Problem:
Wenn Hohe Latenzen auf dem WAN Interface zustande kommen und/oder hohe Latenzen auf den VPN Verbindungen erscheinen, habe ich kurze Verbindungsabbrüche zur NAS, was sich darin äußert, dass der VLC Player beim abspielen (Laptop VLAN), die Datei nicht findet (NAS VLAN) und ich völlig entnervt vom Sofa aufstehen muss um den Player neuzustarten.
Warum zum Geier, wird der interne LAN Verkehr gestört, wenn mein ISP oder der VPN Probleme hat?
Die CPU Auslastung ist währenddessen durchschnittlich bei 10%.

Was ich schon probiert habe:
Das Problem verfolgt mich jetzt schon mehrere Monate und ich habe so ziemlich alle Layer-1 und Layer-2 Probleme gründlichst untersucht ohne was zu entdecken, wodurch ich mir ziemlich sicher bin, dass das Problem entweder bei der OPNsense selber liegt oder an meiner Unfähigkeit die Firewall richtig zu konfigurieren. :(
1. Ich habe den Switchport an den der Laptop hängt auf einen anderen Port gewechselt --> Kein Erfolg
2. Kabel getauscht --> Kein Erfolg
3. Switch, Firewall und auch Client NIC Treiber/Firmware geupdated --> Kein Erfolg
4. LAGG Fast timeout enabled --> Kein Erfolg
5. VLAN priority der NAS VLAN auf "Internetwork Control(6)" gestellt --> Kein Erfolg
6. NAS Log überprüft --> Keine Fehler
7. Switch Log überprüft --> Trunk Interface stabil ohne UP/Downs
8. Latency thresholds der VPN Interfaces und des WAN Interfaces auf 1500/2000 gestellt --> Kein Erfolg
9. Packet Loss thresholds der VPN Interfaces und des WAN Interfaces auf 70/80 gestellt --> Kein Erfolg
10. VLAN Einstellungen weiß ich wie oft schon überprüft auf der Firewall und auf dem Switch --> Keine Besserung

Meine Vermutung:
Ein paar Sachen sind komisch:
1) Und zwar meldet die OPNsense "Error Outs" bei den VLAN Interfaces. Nur 4-6 und die werden auch nicht mehr, aber gehen auch nicht auf 0, wenn ich die Firewall neustarte.
2) Der Gateway Status der VPN Interfaces bleibt nach einem Reboot auf "unknown", bis ich den "apinger daemon" neustarte. Dann werden die Gateways wieder erkannt.
3) Das Inter-VLAN-Routing wird vom VPN gestört. Wenn die VPN Interfaces down gehen und sich selber abwechseln und dann dabei der ganze VPN Failover down geht, weil die ISP Verbindung eine zu hohe Latenz aufweist, dann werden die WAN Interface und die VPN Interfaces ständig neugestartet. Warum auch immer funktioniert dann das Routing zum NAS VLAN nicht mehr.

Vor lauter Frust hätte ich mir vorhin fast nen 20€ Hub gekauft um NAS und Laptop einfach direkt miteinander zu verkabeln... Konnte mich aber noch beherrschen.. man will ja nicht aufgeben, aber das ist schon alles sehr frustrierend. :(
Hat irgendwer noch eine Idee? Dumme Frage aber angenommen, mein Outbound-NAT ist falsch konfiguriert, könnte das dafür sorgen, dass interner Verkehr nicht geroutet wird? Nein oder?

Schöne Grüße
Oxy

Ps.: sorry für den Rant. :-/
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: mimugmail on October 22, 2017, 07:29:18 am
Du hast noch vergessen in dem Moment wo die Verbindung abbricht das system.log auf der Firewall zu checken.
Poste das doch bitte mal.

Und bevor du verzweifelst und nen Hub kaufst, brich das VLAN / LACP auf und mach jedes LAN auf einem dedizierten Port. Das ist eventuell etwas weniger fehleranfällig.
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: Oxygen61 on October 22, 2017, 05:04:49 pm
Quote
Du hast noch vergessen in dem Moment wo die Verbindung abbricht das system.log auf der Firewall zu checken.
Gute Idee das mach ich. :)

Quote
Und bevor du verzweifelst und nen Hub kaufst, brich das VLAN / LACP auf und mach jedes LAN auf einem dedizierten Port. Das ist eventuell etwas weniger fehleranfällig.
Wie kann das eine Lösung für irgendwas sein? ??? Ich brech doch nich mein komplettes Security Konzept auf nur weil die Firewall nicht in der Lage ist unter hoher Auslastung Inter-VLAN-Routing zu machen. Mal ganz abgesehen davon, dass meine Firewall kein Switch ist und ich keine 10+ dedizierten LAN Ports für meine unterschiedlichen LANs besitze. Deswegen existieren ja Switche, genau weil man mit VLANs arbeiten möchte.  :)
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: mimugmail on October 22, 2017, 06:20:55 pm
Es war auch nicht ernst gemeint, so wie das mit dem Hub ;)
Poste einfach das system.log, dann kriegen wir das schon hin
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: NilsS on October 23, 2017, 08:16:16 am
Moin Oxy,

Quote
Ich habe drei OpenVPN Verbindungen, die sich als Failover Group gegenseitig bei einem "member down" abwechseln sollen.
das ist ein VPN für allen externen Traffic? (Airvpn? nur geraten Aufgrund der 3 Verbindungen)
Nutzt du deren DNS?

Ich habe einen ähnlichen Aufbau, hatte damals unter pfsense auch öfters Probleme damit. Die Dienste DNS und NTP starten bei Verbindungsabbrüchen neu, ich hab das Problem damals beseitigt indem ich die Dienste nicht auf ALL INTERFACES laufen lasse, sondern auf localhost und dann mittels NAT die Dienste in den benötigten Netzen zur Verfügung stelle.

Ich nutze zwei AIRVPN Verbindungen jedoch mit Failover High Latency, seit Umstellung auf OPNsense "noch" keine Probleme damit.

Ich hab jedoch um mir den Ärger mit dem Routing zu sparen meine VLANs mit einer Bridge verbunden. Hatte ich hier in einem anderen Schritt schon kurz beschrieben. Ich bin jedoch noch nicht so weit mit der Umstellung als das ich da detailliert was zu posten kann.
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: Oxygen61 on October 23, 2017, 10:22:17 pm
Moin ihr beiden :)

Quote
Es war auch nicht ernst gemeint, so wie das mit dem Hub ;)
Poste einfach das system.log, dann kriegen wir das schon hin
Ahhh Alles klar. Den hatte ich dann nicht verstanden sorry. Hehe :)
"Leider" war bis jetzt kein Ausfall mehr, aber das System Log schick ich sobald es wieder passiert. :)

Quote
das ist ein VPN für allen externen Traffic? (Airvpn? nur geraten Aufgrund der 3 Verbindungen)
Gut geraten aber nein, ich nutze Perfect Privacy und nutze den VPN für sämtlichen externen Traffic ja. Die drei Verbindungen kommen zustande, weil ich es für sehr unwahrscheinlich hielt, dass 3 Verbindungen gleichzeitig ausfallen können. 2 war mir daher zu wenig und 4 zu viel. :P

Quote
Nutzt du deren DNS?
Nein, ich nutze den Unbound DNS Resolver im Forward Modus und schicke alle Anfrage weiter zu 3 DNS Servern die ich mir von OpenNIC rausgesucht habe.
Network Interfaces ist auf "All" und Outgoing Network Interfaces sind auf die drei VPN Schnittstellen beschränkt, damit kein DNS Leak entsteht.
Zum Streamen und Dateien ablegen nutze ich CIFS (Port 445 / SMBv3)
Liegt da vielleicht der Hund begraben, weil er irgendwie nicht mehr den Hostnamen von der NAS auflösen kann, wenn das VPN abbricht und neu lädt? :o

Quote
Die Dienste DNS und NTP starten bei Verbindungsabbrüchen neu
Ist bei OPNsense seit den letzten Patches kein Problem mehr. Ich hatte da Franco solange genervt bis er den DNS so umprogrammiert hat, dass das VPN Interface neu laden kann ohne den Cache zu verlieren. Man merkt vom neuladen also nichts. Auch beim Failover abwechseln verliert Unbound nicht den Cache.

Quote
Ich nutze zwei AIRVPN Verbindungen jedoch mit Failover High Latency, seit Umstellung auf OPNsense "noch" keine Probleme damit.
So hatte ich das auch. Jedoch ist in meiner Gegend die Kabel ISP Verbindung extrem gestört, sodass immer ab 20 Uhr hohe Latenzen entstehen, die nicht nur das WAN Interface, sondern auch die VPN Verbindungen in die Knie zwingen (Latenz Spitzen von 600 ms). Deswegen hatte ich das ja manuell auf 1500/2000ms erhöht damit die Failover Gruppe sich nicht ständig abwechselt und unnötig Last erzeugt. Leider ist die Latenz manchmal so hoch, dass die gesamte Failovergruppe versagt und er dann als letzten Ausweg das WAN Interface neustartet.
Das wär für mich ja alles kein Problem, wenn nicht in der gleichen Zeit auch die NAS/CIFS Verbindung abbrechen würde.

Weiterhin habe ich bei den Outbound NAT Regeln das WAN Interface durch die VPN Interfaces ausgetauscht, damit kein IP Leak entsteht, was auch super funktioniert, wenn denn mal kein Internet da ist, wegen meinem ISP. Aber Outbound NAT kümmert sich doch nicht um internen Traffic Verkehr?  ???

Weiterhin habe ich alle FW Regeln die nach (! RFC1918) zeigen so eingerichtet, dass sie den Failover Verbund als Gateway nutzen.
Außerdem zeigt mein Traffic Shaper jetzt nicht zum WAN Interface sondern zu den VPN Interfaces, um Upload und Download in das interne Netz zu regulieren.

Also anhand meines Wissens fehlt da nichts oder habe ich was grundsätzlich falsch gemacht und störe dadurch das Inter-VLAN-Routing? ???

Quote
Ich hab jedoch um mir den Ärger mit dem Routing zu sparen meine VLANs mit einer Bridge verbunden.
Sowas wollte ich halt von Anfang an vermeiden, ganz genau, weil ich halt eine extrem Leistungsstarke FW habe von der Hardware her und auch einen Switch für ein Einsatzgebiet von ~300 Leuten besitze. Also alles absichtlich etwas oversized, um keine Performanceeinbuße verzeichnen zu müssen. Ich wollte schon beim klassischen LACP/Inter-VLAN-Routing Schema bleiben, gerade auch weil es so unglaublich gut funktioniert.
(Außer halt wenn dann plötzlich die NAS nicht mehr gefunden wird. :P :P)

Schöne Grüße
Oxy

Ich schreibe das System Log wenn wieder ein Ausfall ist.... kann vielleicht etwas dauern.. :/
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: NilsS on October 24, 2017, 09:12:56 am
Quote
auch einen Switch für ein Einsatzgebiet von ~300 Leuten besitze
bzgl. Leistung oder Anzahl der Ports xD

Quote
(! RFC1918)
vergibt pp private IPs und NATed oder bekommst du direkt eine öffentliche?

Ich NATe auf den VPN Interfaces mit dem Alias N_LOCALNETS in dem ich alle lokalen IP Netze habe mit
SOURCE N_LOCALNETS DEST !N_LOCALNETS

Ich bin vom Routing auch nicht deshalb weg, sondern wegen Multicast, Broadcasts und IGMP.

bzgl. DNS nutzt das System auch den unbound ( Do not use the DNS Forwarder/Resolver as a DNS server for the firewall )

schreibt der Switch was ins Log? LACP events, UP/DOWN events ....

ist "Disable State Killing on Gateway Failure" der Haken gesetzt
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: Oxygen61 on October 24, 2017, 10:50:50 pm
Hi NilsS :)

Quote
bzgl. Leistung oder Anzahl der Ports xD
Schön wärs. Hehe. Leistung.. nur Leistung. 300 Ports brauch ich "noch" nicht. Vielleicht ändert sich das irgendwann mal mit Smart Home, wenn mein Bett ne LAN Verbindung für den Wecker braucht. :D

Quote
vergibt pp private IPs und NATed oder bekommst du direkt eine öffentliche?
Ich hab die VPN Clients so eingerichtet:
Server Mode: Peer to Peer
Device Mode: tun
Interface: WAN
Remote server: <Standort>.perfect-privacy.com Port 1149
Infinitely resolve remote server: haken gesetzt
Dann halt noch die Crypto Einstellungen und Nutzer/Passw und die advanced Settings für OpenVPN

Mein Gateway für das jeweilige VPN Interface hingegen (und ich glaube darauf willst du hinaus) steht auf "dynamic", was bedeutet, dass ich dynamisch eine private IP Adresse aus dem 10.0.0.0/8 Netz bekomme.

Quote
Ich NATe auf den VPN Interfaces mit dem Alias N_LOCALNETS in dem ich alle lokalen IP Netze habe mit
SOURCE N_LOCALNETS DEST !N_LOCALNETS
oh okay. Das unterscheidet sich noch etwas von meinem NATing.
Nur damit ich das richtig verstehe... wir reden vom "Outbound NAT" was man bei OPNsense auf "Manual outbound NAT rule generation" stellen kann richtig? :)
Ich erklär kurz wie die OutboundNAT Regeln bei mir aussehen. Vielleicht ist ja da wirklich der Knackpunkt.
...
Beim erstellen, hatte ich immer zwischen "Automatic outbound NAT rule generation" und "Manual" gewechselt.
Die automatisch Erstellten Regeln sehen so aus, beispielsweise für VLAN_User:

VPN_PP_<Standort>   192.168.X.X/24    *   *   500   VPN_PP_<Standort> address   *   YES   Auto created rule for ISAKMP - VLAN_USER -> WAN
       
VPN_PP_<Standort>   192.168.X.X/24    *   *   *   VPN_PP_<Standort> address   *   NO   Auto created rule - VLAN_USER -> WAN

usw. und sofort für alle privaten VLAN Interfaces und auch für 127.0.0.0/8 , alles insgesamt 3 mal für alle 3 VPN Interfaces. :)

Quote
Ich bin vom Routing auch nicht deshalb weg, sondern wegen Multicast, Broadcasts und IGMP.
Hmm okay, da gibts/gab es bei mir jedoch noch kein Einsatzgebiet für.
Spotify und bestimmte Streams kriegt man aber anders nicht in den Griff hab ich mir sagen lassen, richtig?

Quote
bzgl. DNS nutzt das System auch den unbound ( Do not use the DNS Forwarder/Resolver as a DNS server for the firewall )
Sorry, aber versteh da grade nich worauf du hinaus willst. :D Meinst du, ob ich den Haken bei "Do not use the DNS Forwarder/Resolver as a DNS server for the firewall" gesetzt habe?
Der ist bei mir NICHT angehakt. :)

Quote
schreibt der Switch was ins Log? LACP events, UP/DOWN events ....
Leider sehr HP typisch schreibt er immer UP und Down events rein, wenn die Rechner/Laptops hoch und runter fahren. Geht dann zweimal Down und zweimal UP und bleibt auf up. Bezüglich LACP stehen am 22. Oct Einträge von LACP UP/Down Meldungen im Switch. Da hatte ich auch einen Ausfall gehabt, der etwas "heftiger" war, hatte dann da abends auch einfach OPNsense geupdated als es dann wieder ruhig war das Netz.
Ein paar Auszüge aus dem Log vom Switch sind folgende:
(VLan-interface1 ist das Default VLAN was nicht getagged wird und nur untagged auf den Interfaces ist)
(VLAN-interface10 ist das Management VLAN wo alle Web Interface Schnittstellen sind)


Code: [Select]
Oct 22 00:11:36:534 2017 IFNET Error LINK_UPDOWN GigabitEthernet1/0/2 link status is UP.
Oct 22 00:11:36:431 2017 IFNET Error LINK_UPDOWN GigabitEthernet1/0/1 link status is UP.
Oct 22 00:11:36:107 2017 IFNET Error LINK_UPDOWN GigabitEthernet1/0/4 link status is UP.
Oct 22 00:11:36:003 2017 IFNET Error LINK_UPDOWN GigabitEthernet1/0/3 link status is UP.
Oct 22 00:11:33:998 2017 RM Error RMLOG The default route has been changed or deleted, protocol is Static, nexthop address is 192.168.X.1, output interface is Vlan-interface10
Oct 22 00:11:33:998 2017 IFNET Notification LINEPROTO_UPDOWN Line protocol on the interface Vlan-interface10 is DOWN.
Oct 22 00:11:33:998 2017 IFNET Error LINK_UPDOWN Vlan-interface10 link status is DOWN.
Oct 22 00:11:33:998 2017 IFNET Notification LINEPROTO_UPDOWN Line protocol on the interface Vlan-interface1 is DOWN.
Oct 22 00:11:33:997 2017 IFNET Error LINK_UPDOWN Vlan-interface1 link status is DOWN.
Oct 22 00:11:33:989 2017 IFNET Error LINK_UPDOWN Bridge-Aggregation1 link status is DOWN.
Oct 22 00:11:33:983 2017 LAGG Notification LAGG_INACTIVE_PHYSTATE Member port GigabitEthernet1/0/2 of aggregation group BAGG1 becomes INACTIVE because the port's physical state (down) is improper for being attached.
Oct 22 00:11:33:982 2017 LAGG Notification LAGG_INACTIVE_PHYSTATE Member port GigabitEthernet1/0/1 of aggregation group BAGG1 becomes INACTIVE because the port's physical state (down) is improper for being attached.
-----------------------------
Oct 22 00:11:33:588 2017 LAGG Notification LAGG_INACTIVE_PHYSTATE Member port GigabitEthernet1/0/4 of aggregation group BAGG1 becomes INACTIVE because the port's physical state (down) is improper for being attached.
Oct 22 00:11:33:587 2017 LAGG Notification LAGG_INACTIVE_PHYSTATE Member port GigabitEthernet1/0/3 of aggregation group BAGG1 becomes INACTIVE because the port's physical state (down) is improper for being attached.

Es fallen also alle Interfaces der gesamten LAGG Gruppe aus (warum auch immer)... die ganze Bridge ist dann down und es kann nicht mehr geroutet werden. (Logisch, weil kein Interface mehr die Bridge aufrechterhalten kann). Zu mindestens deute ich das so. :o
Außerdem muss man sagen, dass auf dem Switch neben dem Default VLAN Interface, was nicht geroutet und nicht getagged wird halt das Administrative Management VLAN Interface angelegt wurde,
mit folgender static Default Route:
Code: [Select]
Destination Mask Protocol Priority Next Hop Interface
0.0.0.0       0.0.0.0 Static             60        192.168.X.1 Vlan-interface10

Quote
ist "Disable State Killing on Gateway Failure" der Haken gesetzt
Gateway Monitoring
 Kill states    Disable State Killing on Gateway Failure [Haken NICHT gesetzt]

Soll ichs mal anhakern? :P

Vielen Dank dir NilsS für die unermüdliche Hilfe schon bis hierher. :)

Schöne Grüße
Oxy
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: NilsS on October 25, 2017, 08:55:54 am
Quote
was bedeutet, dass ich dynamisch eine private IP Adresse aus dem 10.0.0.0/8 Netz bekomme
Sind die Netze je VPN Server ([standort].perfect-privacy.com) unterschiedlich?
Also vergibt der eine Server die 10.10.x.x der andere z.B. 10.11.x.x sodass die Netze zu unterscheiden sind.
Das ist auch für den apinger nötig, da wenn du auf allen Interfaces die gleiche Gateway IP hast, wird schwer zu unterschieden sein welches Gateway Probleme hat. Bei AirVPN kann man über die verwendeten Ports 53/80/443/1194 etc. beeinflussen welches IP Netz man bekommt. Vielleicht gibt es da ja bei PP auch Möglichkeiten.

Quote
Nur damit ich das richtig verstehe... wir reden vom "Outbound NAT" was man bei OPNsense auf "Manual outbound NAT rule generation" stellen kann richtig
Ja genau.
Nur um mir x NAT Regeln zu sparen nutze ich halt je WAN und ausgehendem VPN nur eine Regel mit dem Alias alles was lokal ist und nach NICHT lokal will wird genated.

Die static Port Regeln für ISAKMP brauchst du nicht auf den VPN interfaces, es sei denn du willst IPSEC über VPN machen.

was evtl. dein Problem sein könnte. Du willst eigentlich Policy Routing verwenden, hast aber gleichzeitig auch die Defaultroute auf die VPNs.

Ich habe in den VPN Optionen unter advanced noch ein "route-nopull" drin stehen, damit eben nicht das Default Gateway gesetzt wird. OPNsense geht immer über WAN (Das kann in deinem Fall jedoch auch Probleme mit sich bringen, da ich mir nicht sicher bin ob du so dafür sorgen kannst das unbound seinen Traffic über VPN schickt. Das gleiche gilt für Squid - falls du den nutzt. Ob es da je eine Änderung geben wird, das man localhost traffic per policy routen kannst must du @franco fragen. Da gibt es diverse Issues die das betreffen)

Also evtl. nur zu Testzwecken (Immer mit https://ipleak.net/ https://www.dnsleaktest.com/ http://witch.valdikss.org.ru/ https://browserleaks.com/ip testen)

Den Haken bei "Disable State Killing on Gateway Failure" solltest du setzen.
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: NilsS on October 25, 2017, 03:17:00 pm
Muss mich noch mal korrigieren bzgl. kein OpenVPN default gateway. Das ging anders
Code: [Select]
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

Unter Firewall -> Settings -> advanced:
 Kill states    [ x ] Disable State Killing on Gateway Failure
Skip rules    [ x ] Skip rules when gateway is down


Alias N_DONTROUTE enthällt  (https://en.wikipedia.org/wiki/Reserved_IP_addresses)
Code: [Select]
0.0.0.0/8
10.0.0.0/8
100.64.0.0/10
127.0.0.0/8
169.254.0.0/16
172.16.0.0/12
192.0.0.0/24
192.0.2.0/24
192.168.0.0/16
198.18.0.0/15
198.51.100.0/24
203.0.113.0/24
224.0.0.0/4
240.0.0.0/4
255.255.255.255
::/96
::1
::ffff:0.0.0.0/96
100::/64
2001:10::/28
2001:db8::/32
fc00::/7
fe80::/10
fec0::/10
ff00::/8

Alias N_LOCALNETS enthällt meine lokalen Netze
[/img]
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: Oxygen61 on October 25, 2017, 10:42:06 pm
Hi NilsS,

puuhh okay da kommen gleich ein paar richtig dumme Fragen von mir wegen deinem NAT, weil ich das gern so umsetzen würde wie du, aber noch Fragen habe..... also Achtung. :D

Aber zuerst das hier:
Quote
Sind die Netze je VPN Server ([standort].perfect-privacy.com) unterschiedlich?
Jep sind sie, zwar alle ausm 10.0.0.0/8 Netz aber ja, jedes Gateway hat eine andere IP,
z.b.: 10.0.50.1 ; 10.0.90.1 und 10.2.224.1

Quote
Nur um mir x NAT Regeln zu sparen nutze ich halt je WAN und ausgehendem VPN nur eine Regel mit dem Alias alles was lokal ist und nach NICHT lokal will wird genated.
Genau. Das klingt ja auch clever, aber dann sehe ich deine NAT Regeln und.... hä? :D Das sieht bei dir dann doch noch etwas "mehr" aus.
Vielleicht kannst du das ja für mich nochmal etwas aufschlüsseln, was ich denn davon bräuchte, da ich ja nur ein WAN Interface habe.
Sämtlicher Traffic nach Extern(Internet) soll durch die VPN Interfaces durch und fertig.

Quote
Die static Port Regeln für ISAKMP brauchst du nicht auf den VPN interfaces, es sei denn du willst IPSEC über VPN machen.
Stimmt. Dann kann ich die weghauen. Ich werd bei OpenVPN bleiben.

Quote
was evtl. dein Problem sein könnte. Du willst eigentlich Policy Routing verwenden, hast aber gleichzeitig auch die Defaultroute auf die VPNs.
Genau, also stimmt ja mein NAT nicht. Das meintest du doch doch mit Default Gateway oder?
Ich meine unter System > Gateways > All ist mein Interface WAN_DHCP immer noch mit (default) gekennzeichnet. Da hatte ich kein Default Gateway vom WAN weggesetzt.

Quote
OPNsense geht immer über WAN (Das kann in deinem Fall jedoch auch Probleme mit sich bringen, da ich mir nicht sicher bin ob du so dafür sorgen kannst das unbound seinen Traffic über VPN schickt.
hmm naja doch. Soweit ich das verstanden hatte kann man ja bei Unbound das "Outgoing Interface" festlegen. Da hatte ich dann nur die VPN Interfaces angehakt und eben NICHT das WAN.... Vielleicht denk ich da zu einfach? :D

Quote
Das gleiche gilt für Squid - falls du den nutzt.
Hab ich "leider" auch noch vor umzusetzen demnächst, wenn das Problem hier gelöst ist. Bis jetzt läuft aber noch kein Squid.

Quote
Ob es da je eine Änderung geben wird, das man localhost traffic per policy routen kannst must du @franco fragen. Da gibt es diverse Issues die das betreffen)
Wenn ich das richtig verstehe, hast du das Problem mit deinen  NAT Regeln umgangen richtig? Oder gibt es dafür einfach schlicht keine Lösung?

Quote
Muss mich noch mal korrigieren bzgl. kein OpenVPN default gateway. Das ging anders
Okay... den Part musst du mir nochmal erklären, steh da auf dem Schlauch....
Die routen sind Optionen die ich unter advanced eintrage? Oder wo sollen die hin? "route-nopull"  schreib ich also nicht rein, sondern stattdessen:
Code: [Select]
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
???
Ausgesprochen also .. route alles im Netz 0.0.0.0 nach 192.0.0.0 und nutze.. das.. net_gateway ?
Das net_Gateway ist in diesem Falle dann was? Das virtuelle lokale VPN Gateway was ich zugewiesen bekomme oder das WAN Gateway?

Quote
Skip rules when gateway is down
omg... das ist bei mir auch nicht angehakt. Wie konnte mir das nur entgehen. Wenn ich die Info dazu richtig lese, schreit das ja förmlich nach IP-Leak, wenn das VPN Failover Gateway down ist bei meinen Firewall Regeln.
Witziger Weise, habe ich jedoch nie IP oder DNS-Leaks... Mein Netz ist dann lieber kurzzeitig down, weil nichts mehr genNATted werden kann. :D

Okay und jetzt nochmal ein paar Fragen zu deinem NAT-Regelaufbau, weil mir der immer noch nicht in den Kopf geht. Sorry! :D

Alias N_DONTROUTE sind alle reservierten IPs die du nicht routen möchtest..... okay
Alias N_LOCALNETS wären in meinem Fall alle privaten VLAN Subnetze, die ich verwende..... okay

Die ersten zwei Regeln sind Localhost Netz vom WAN Interface zur WAN Adresse... okay bis hier hin

Die dritte Regel versteh ich nicht. Die Lokalen Privaten Adressen werden zu allen externen Adressen über das WAN Interface geNATed? Dadurch hast du doch einen IP-Leak oder nicht?
Die 4te und 5te Regel beziehen sich dann auf die beiden VPN Interfaces und du NATest von privat auf alles was NICHT ein reservierter Bereich ist, also quasi das Internet.
Warum NATest du bei der dritten Regel nicht auch zu !DONTROUTE ? warum da plötzlich nur !LOCALNETS ? Damit NATest du doch eben auch ein paar reservierte Adressen über das WAN?

Soo viele Fragen tut mir wirklich leid, aber der Teufel steckt im Detail und wenn ich am Wochenende dann die Umstellungen mache und irgendwas geht nicht, krieg ich aufn Deckel und das Geheule ist groß. :P

Schöne Grüße und Danke wie immer :)
Oxy
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: NilsS on October 26, 2017, 09:01:11 am
Quote
Sämtlicher Traffic nach Extern(Internet) soll durch die VPN Interfaces durch und fertig.
da hast du dann schon das erste Problem, denn du kannst nur ein default gateway haben und Traffic der auf der OPNsense generiert wird nutzt das. Auf der OPNsense funktioniert policy routing nicht mit localhost traffic (unbound/squid ...) Das "Outgoing Interface" in unbound hat auch folgenden Text in der Hilfe
Quote
Note that setting explicit outgoing interfaces only works when they are statically configured.
inwieweit das denn dann auch genutzt wird wenn keine default route für das Interface gesetzt ist, kann ich dir nicht sagen aber ich tippe mal eher auf geht nicht.

Derzeit bekommst du bei jeder Verbindung mit einem der 3 VPNClients per push eine neue defaultroute gesetzt (heißt dein ausgehender Traffic - zumindest der von der OPNsense direkt - wechselt beim Neuverbinden eines VPNclients seine Route und damit auch seine externe IP) Die Failover Gatewaygroup wird für lokalen Traffic nicht verwendet, da du für diesen Traffic ja keine Regeln anlegen kannst.

Heißt bei einem Member Down Ereignis (egal ob nun gerade aktiv genutzt oder nicht) wird die Verbindung direkt wieder versuchen sich zu verbinden und bei Erfolg also wieder dein Routing anfassen.

Quote
Genau, also stimmt ja mein NAT nicht. Das meintest du doch doch mit Default Gateway oder?
NAT hat nichts mit Routing zu tun.

Die NAT-Regeln sorgen ja nur dafür das Traffic der über das jeweilige Interface läuft mit seiner ursprünglichen IP oder mit der IP des Interface das selbige verlässt.

Quote
Bis jetzt läuft aber noch kein Squid.
spätestens da hast du dann NUR noch das default Gateway und nicht mehr die Gateway-Group

Quote
Wenn ich das richtig verstehe, hast du das Problem mit deinen  NAT Regeln umgangen richtig?
Nein, das Problem besteht nach wie vor. Ich nutze nur gerade kein Squid und den unbound habe ich mit
Code: [Select]
forward-zone:
    name: *
    forward-addr: 10.50.0.1
    forward-addr: 10.40.0.1
dazu gezwungen die AirVPN Server zu nutzen, die ja im gleichen Subnetz liegen wie die VPN Clients und daher kein Gateway brauchen.

Quote
Die routen sind Optionen die ich unter advanced eintrage? Oder wo sollen die hin? "route-nopull"  schreib ich also nicht rein, sondern stattdessen:
Code:
Code: [Select]
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
Ausgesprochen also .. route alles im Netz 0.0.0.0 nach 192.0.0.0 und nutze.. das.. net_gateway ?
Nein das siehst du falsch. Die 192.0.0.0 ist die Subnetzmaske das Gateway ist net_gateway, das kommt nicht von mir https://community.openvpn.net/openvpn/wiki/IgnoreRedirectGateway
Methode 1 ging aus irgendwelchen Gründen nicht (kann micht nicht mehr dran errinern was es war)

Quote
Skip rules when gateway is down
omg... das ist bei mir auch nicht angehakt. Wie konnte mir das nur entgehen. Wenn ich die Info dazu richtig lese, schreit das ja förmlich nach IP-Leak, wenn das VPN Failover Gateway down ist bei meinen Firewall Regeln.
Witziger Weise, habe ich jedoch nie IP oder DNS-Leaks...
Wenn alle Gateways (VPNs down sind) sollte der Traffic über WAN gehen (aber wenn du keine WAN NAT Rules für das Netz angelegt hast, geht es halt nicht sehr weit ;-) )

Quote
Die dritte Regel versteh ich nicht. Die Lokalen Privaten Adressen werden zu allen externen Adressen über das WAN Interface geNATed? Dadurch hast du doch einen IP-Leak oder nicht?
Ja, aber bei mir nutzen nicht alle Netze das VPN. Wer dann wohin mit welchem Gateway(group) darf wird über die Rules geregelt.

Quote
Warum NATest du bei der dritten Regel nicht auch zu !DONTROUTE ? warum da plötzlich nur !LOCALNETS ? Damit NATest du doch eben auch ein paar reservierte Adressen über das WAN?
Yep, war eigentlich auch mal so. Hab ich übersehen - ich hab es letztens kurz geändert um auf das Kabelmodem zu kommen (192.168.100.1) das wäre bei DONTROUTE nicht genated worden und dann kommt da nix vom Modem. Eigentlich müsste auch dort N_DONTROUTE rein.

Quote
und wenn ich am Wochenende dann die Umstellungen mache und irgendwas geht nicht, krieg ich aufn Deckel und das Geheule ist groß.
Kenn ich das Problem
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: Oxygen61 on October 26, 2017, 10:40:44 pm
Hey NilsS,

langsam wirds für mich ein wenig undurchsichtig und zuviel. Deshalb versuch ich das mal jetzt zusammenzufassen.
Also was ich jetzt schon umgesetzt hab, war erstmal dein NATing, mit dem source: localnet zu Dest: !Dontroute, im Grunde zu kopieren. Das hat schon mal geklappt. Siehe Bild:

(https://img1.picload.org/image/drgiawwr/unbenannt.png)

Was ich noch gemacht hab ist folgendes: (Was genau muss noch angehakt werden dort?)

(https://img1.picload.org/image/drgiogai/unbenannt.png)


Der nächste Schritt hin zum Ziel ist es also, als nächstes das VPN Default Gateway aufzulösen und wieder das WAN als Default Gateway arbeiten zu lassen, richtig?
Wer was darf im Netz, hab ich ja auch durch FW-Regeln und dem Setzen eines Gateways festgelegt.
Wobei die ersten Regel ohne Gateway sind. Regeln wie Erlaube VLAN User (192.168.X.X/24) nach VLAN User Gateway (192.168.X.1) auf Port 53 oder 123 für NTP.
Das Gateway hab ich immer nur dann gesetzt wenn es Richtung Internet geht.

Hier auch mal meine OpenVPN advanced Settings:
Code: [Select]
persist-remote-ip
tun-mtu 1500
fragment 1300
mssfix
#float
hand-window 120
tran-window 3600
inactive 604800
mute-replay-warnings
ns-cert-type server
redirect-gateway def1
reneg-sec 3600
resolv-retry 60
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-RSA-WITH-AES-256-CBC-SHA
tls-timeout 5
key-direction 1
auth-nocache
auth-retry interact

Kriegst du für mich vielleicht nochmal kurz zusammengefasst, was ich jetzt noch als nächstes einrichten muss um das VPN Gateway Problem in den Griff zu kriegen, bzw. irgendwie zu "workarounden" :P ?
- NAT
- OpenVPN Client Konfig.
- DNS

Wie immer vielen vielen Dank :)
Schöne Grüße
Oxy
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: NilsS on October 27, 2017, 08:46:07 am
Quote
Regeln wie Erlaube VLAN User (192.168.X.X/24) nach VLAN User Gateway (192.168.X.1) auf Port 53 oder 123 für NTP.
Das kannst du ja mit recht simplen Regeln erlauben.

Action: Pass
Interface: VLAN_USER
TCP/IP Version: IPv4
Protocol: UDP
Source: VLAN_USER NET
Destination: This Firewall
Destination port range: DNS/NTP
Gateway: bleibt auf default


Quote
sticky connections
brauchst du nur wenn du in der Gatewaygroup alle Gateways als Tier1 anlegst.

wozu hast du das shared forwarding aktiviert? nutzt du traffic shaper oder captive portal?

Quote
Hier auch mal meine OpenVPN advanced Settings:
hier sind mein
Code: [Select]
mssfix 1379; ## try to hide OpenVPN
sndbuf 393216; ## try 0 for TCP
rcvbuf 393216; ## try 0 for TCP
fast-io; ## only for UDP
explicit-exit-notify 4; ## only UDP
server-poll-timeout 10;
mlock;
key-direction 1;
key-method 2;
keysize 256;
prng SHA512 64;
remote-cert-tls server;
tls-version-min 1.2;
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384;
reneg-sec 3600;
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

Quote
um das VPN Gateway Problem in den Griff zu kriegen
kannst du das denn auch provozieren?
also streaming über LAN mit VLC und dann händisch OpenVPN Client neu starten
oder geht das nur wenn die Verbindung abbricht.
Bricht die VPN Verbindung denn so oft ab?
Ist dein WAN so schlecht oder PP?
Ich habe die VPN Tunnel oft über mehrere Tage offen und habe eigentlich nie Probleme mit Latenz oder Geschwindigkeit. Durchschnitt so 40-60ms Ping und 50-140Mbit Down und ~20Mbit up Leitung ist 200/25 Werte Speedtest.net mit VPN Servern .de und .cz (Werte weichen kaum voneinander ab)

Durchschnitts Ping über WAN (ohne VPN) auf 8.8.8.8 liegt so bei 27ms

Ich nutze zwei IPsec Tunnel zu remote Sites (über WAN direkt) die keine Abbrüche verzeichnen sollte irgendeine der OpenVPN Tunnel zusammenbrechen.

Default Gateway switching könnte wenn du denn bei deiner jetzigen Konfig bleibst (damit dein lokaler unbound auch die VPN Tunnel nimmt) ein Option sein.

Der untersterste Punkt "Disable force Gateway" könnte dafür auch noch eine Option werden, aber da kann ich dir noch nix zu sagen (werde da aber - sofern Zeit - mal testen) https://forum.opnsense.org/index.php?topic=6242.0
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: Oxygen61 on October 28, 2017, 12:15:48 am
Quote
Das kannst du ja mit recht simplen Regeln erlauben.
Genau so mach ich das ja auch schon :)
Die Rules die für intern sind ohne Gateway und für extern dann halt mit VPN Failover gateway

Quote
brauchst du nur wenn du in der Gatewaygroup alle Gateways als Tier1 anlegst.
Juti. Also brauch ich das nicht.

Quote
wozu hast du das shared forwarding aktiviert? nutzt du traffic shaper oder captive portal?
Ja ich nutze Traffic Shaping, weil ich nicht möchte, dass wenn jemand aus dem Netz plötzlich irgendwas runterläd, ich meinen Stream nicht mehr schauen kann usw.. Beim Traffic Shaping habe ich dann wie gesagt anstatt des WAN Interfaces für Upload und Download, für jedes VPN Interface 2 Shaping Regeln erstellt.
Kann das zum Problem werden, dieses "Feature" angehakt zu haben?
An dieser Stelle sei vielleicht auch gesagt, dass ich unter System > Settings > General die DNS Server ohne Gateway (none) angegeben habe. Müsste ich da dann doch noch das Gateway eintragen bei meinem Konfigurationsaufbau?

Quote
Quote
Hier auch mal meine OpenVPN advanced Settings:
hier sind mein
Cool. Das muss ich mir mal anschauen, was du da so eingetragen hast. mlock; ist interessant und fast-io

Quote
kannst du das denn auch provozieren?
also streaming über LAN mit VLC und dann händisch OpenVPN Client neu starten
Ich werd morgen mal versuchen das zu provozieren. Ich hab bloß die leise Ahnung das das nicht klappen wird.
Ich geb dir dann morgen bescheid. :)

Quote
Bricht die VPN Verbindung denn so oft ab?
Ist dein WAN so schlecht oder PP?
Nein eigentlich nicht. Aber so von 19:00 - 0:00 Uhr habe ich starke Latenzspitzen bis zu 600 ms, die aber von meinem ISP ausgehen. Sofern also nicht gerade die ganze Nachbarschaft ins Internet will, bleibt alles sehr sauber, schnell und stabil. (Ping auf 8.8.8.8 mit 25ms)
Am Wochenende kann ich mir fast immer sicher sein, dass es zu Abbrüchen kommt.
Vielleicht muss ich gar nichts provozieren. :P

Quote
Default Gateway switching könnte wenn du denn bei deiner jetzigen Konfig bleibst (damit dein lokaler unbound auch die VPN Tunnel nimmt) ein Option sein.
Alles klar hab ich auch mal angehakt.

Aber jetzt auch im Bezug auf Squid und generell dem local Host verkehr (unbound).... gibt es denn gar keine Möglichkeit wie ich bei meiner Konfig bleiben kann, aka. alles durch den VPN tunneln per NAT?
Alle IPleak und DNS Leak tests zeigen nie, dass ich auch nur irgendwas leake...
Ich meine dafür muss es doch einen Weg geben oder?
Laut Franco ist das ja alles noch nicht geklärt. Kann man nur hoffen, dass sich das bald ändert. :(

Quote
"Disable force Gateway"
Hab ich mich jetzt noch nicht getraut anzuhaken. Falls doch wieder Abbrüche beim Routing sind, werde ich das aber mal anhaken.

Schöne Grüße
Oxy

Ps.: ich hab seit gestern keine Chance mehr jdownloader.org per DNS aufzulösen (alle anderen DNS Auflösungen klappen). Ist dir da zufällig was bekannt? Hab schon mehrere DNS Server ausprobiert und die Standorte gewechselt. Wenn ich z.B. per HideMyAss Proxy in die USA gehe oder nach Deutschland, komm ich wieder rauf auf die Seite. Wenn ich aber nen VPN Server nutze der in Deutschland steht, komme ich trotzdem nicht hin. Also alles ganz kurios heute mal wieder. :D :D
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: Oxygen61 on October 30, 2017, 10:31:37 pm
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
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: NilsS on November 01, 2017, 11:03:50 am
kannst du mal gucken ob du sowas
Code: [Select]
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.
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: Oxygen61 on November 01, 2017, 09:49:25 pm
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]
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]
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
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: Oxygen61 on November 02, 2017, 07:17:58 pm
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]
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
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: Oxygen61 on November 02, 2017, 09:22:36 pm
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]
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]
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
Title: Re: Connection Loss - VLAN Routing und OpenVPN Probleme
Post by: Oxygen61 on November 04, 2017, 05:52:08 pm
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