Connection Loss - VLAN Routing und OpenVPN Probleme

[Oxygen61]

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. :-/

[mimugmail]

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.

[Oxygen61]

Du hast noch vergessen in dem Moment wo die Verbindung abbricht das system.log auf der Firewall zu checken.

Gute Idee das mach ich.

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. 

[mimugmail]

Es war auch nicht ernst gemeint, so wie das mit dem Hub
Poste einfach das system.log, dann kriegen wir das schon hin

[NilsS]

Moin Oxy,

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.

[Oxygen61]

Moin ihr beiden

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.

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.

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?

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.

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?

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. )

Schöne Grüße
Oxy

Ich schreibe das System Log wenn wieder ein Ausfall ist.... kann vielleicht etwas dauern.. :/

[NilsS]

auch einen Switch für ein Einsatzgebiet von ~300 Leuten besitze

bzgl. Leistung oder Anzahl der Ports xD

(! 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

[Oxygen61]

Hi NilsS

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.

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.

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.

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?

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. 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.

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.
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

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?

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

Schöne Grüße
Oxy

[NilsS]

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.

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.

[NilsS]

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]

[Oxygen61]

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.

Aber zuerst das hier:

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

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ä? 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.

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.

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.

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?

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.

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?

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?

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.

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

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ß.

Schöne Grüße und Danke wie immer
Oxy

[NilsS]

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

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.

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.

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

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.

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)

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 ;-) )

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.

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.

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

[Oxygen61]

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:


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



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" ?
- NAT
- OpenVPN Client Konfig.
- DNS

Wie immer vielen vielen Dank
Schöne Grüße
Oxy

[NilsS]

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

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?

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


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

[Oxygen61]

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

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

Juti. Also brauch ich das nicht.

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?

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

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.

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.

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.

"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.