Auch der Reboot löst das Problem mit der fehlenden IPv6 auf LAN nicht immer. Da bleibt wirklich nur auf 2.5 zu hoffen. I am ready! 🤞

@dex said in Routing zwischen Site to Site and Remote Access OpenVPN Server:

Lediglich das Tunnel Netz im Peer to Peer Client durfte nicht leer bleiben da sonst kein Tunnel aufgebaut wurde.

Wie erwähnt, das gilt nur für SSL/TLS-Server Mode, nicht für Shared Key.

Moin Moin,
schön dass es jetzt läuft!

Ich hatte ein ähnliches Phänomen schon einmal mit einem WireGuard-Tunnel.
Pings gingen durch, sonst nichts.
Lösung war ein Absenken der MTU des WG.
Es wurde scheinbar nicht sauber fragmentiert.

VF
Jan

@jegr said in Die ID:

Und wer es nicht will schaltet es in den Advanced Options aus.

Es ging um die Netgate ID. Die Übermittlung kann abgeschaltet werden. Advanced Options / Misc / Installation Feedback / Netgate Device ID

Das werdet ihr mir jetzt nicht glauben.

Also dieser Konsolbildschirm, diese Shell ist ziemlich kaputt, sprich buggy. ein paar Tastenkombinationen und schon hängt sich die ganze Kiste wieder auf. Das Ganze leider auch per SSH und Putty und daher kam auch die Verwirrung das die NMEA von Gerät cuaU0 nach gps0 fehlerhaft seien; waren sie aber nicht.

Wenn man die NTP Konfiguration ändert und sie sich selbst neu startet werden die Daten auf dieser pfSense Shell nicht mehr richtig dargestellt. Also zweite shell aufgemacht und mittels kill den Prozess abgeschossen und eine erneute Shell geöffnet und "cu -s 4800 -l /dev/gps0" wieder gestartet.

Die Daten waren definitiv richtig (ich mach das nicht zum ersten Mal), trotzdem keine Aktualisierung unter Status NTP.

Soweit so schlecht :-(

Also mir einen Wolf gelesen, eine Nachtschicht eingelegt und ich war noch immer nicht schlauer :-(

Der entscheidende Hinweis fand ich auf dieser Seite:

http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html

Da muss man erst mal drauf kommen :-(((

Also die GPS Maus, weil es so schön praktisch war, an der Rückseite des Computers in den nächstbesten freien USB Port gesteckt.
Ist ja kein Problem, das Teil wurde erkannt auf Gerät /dev/cuaU0 und mittels cu -s 4800 -l /dev/cuaU0 konnte man ja auch die Daten auslesen.
Dann herausgefunden, das diese Daten auf Gerät /dev/gps0 umgelegt wurden und miitels cu -s 4800 -l /dev/gps0 konnte man die ja auch auslesen.

Also alles paletti ?!? Denkste!

Aus irgend einem vollkommen beknackten Grunde kann gemäß obige Seite NTP nur bis zum COM Port 3 !!!!!! die Daten lesen.
Was für eine Schei..... ist das denn bitteschön?

Und auf der Hilfe Seite:
https://docs.netgate.com/pfsense/en/latest/services/ntpd/gps.html

steht nicht die Bohne was von dieser Einschränkung!

Zumal gemäß obige Webseite auch nicht jeder dieser drei COM Ports funktioniert, was ich bestätigen kann; ich habe die Maus in jeden USB Port eingesteckt um zu sehen, welcher im Bereich von COM 1-3 liegt und bei mir funktionierte auch nur USB-Port zwei.

Fazit, falls die GPS-Maus mal nicht will, aber sollte, bitte den USB-Port als erstes überprüfen!

Junge, Junge, was für ein Blödsinn.

Jetzt läuft´s :-)

Ja. Du schreibst ja auch nichts falsches. Auch wenn ich gleich noch nachschaue, ob deine Zeile zu dem gleichen Ergebnis führt wie das was ich anschliessend herausfand.

Allgemein, bevor sich ein realer Eindruck einstellt - und dafür braucht es imho eine längere Zeit als unsere bisher - daß jemand nicht fleißig und/oder belastbar genug ist, sollte man den Leuten erstmal zugestehen, daß sie AB UND ZU vielleicht grad nur auf dem Schlauch stehen.

Das Thema ist für Nichtschwimmer die sich in den Atlantik mit erst nur einem Gummiboot hineinstürzen, komplex genug. Wird noch (!)

Periodisch leicht dusselig sollte auf jeden Fall weit über faul und lustlos bewertet werden ;-)

mfG.

@nocling Heute habe ich die pfSense komplett neu installiert. Also via USB Medium neu installiert. Nach der Installation habe ich nichts geändert, sondern alles bestätigt was vorgeschlagen war.

#WAN auf DHCP (hab den Router direkt am WAN Port angesteckt)
#LAN auf DHCP (hab den Client direkt am LAN Port der pfSense angesteckt)
#also keine sonstige Hardware dazwischen

eMail Versand / Empfang funktioniert nicht:
3364a5e0-2984-479d-b275-e9d57797835a-grafik.png

Auch beim "surfen" via Webbrowser muss ich wieder mehrmals auf "F5" Taste drücken, damit die Seite aufgebaut wird.

Habe nun als DNSe wieder den von Cloudflarenet eingestellt unter General Setup. Also 1.0.0.1 und 1.1.1.1 --> nun funktioniert das "surfen" wieder auf anhieb. Der eMail Versand / Empfang leider nicht. Das geht wie bereits erwähnt nun am Laptop nicht. Hab dann die pfSense wieder in mein Netzwerk eingebunden und der Versand / Empfang funktioniert auch auf allen anderen Clienst nicht (gmx, gmail)
417e8998-e165-411d-b784-9601230f2c3e-grafik.png

Gibt´s da noch Ideen, wie ich das Ding zum Laufen bekomme? Danke!

@jegr

100% zustimmung

@viragomann

danke !
war etwas verwirrend wegen den RAID optionen ... !
Danke ergo [solved]

@JeGr
Nein. Das war nicht meine Sorge. (Beitrag wegen "mit 2.5 nicht einverstanden")

Ich sehe bisher eins. Die 2.4 hat einen ziemlich Ochsenweg hinter sich, bis sie endlich bei 2.4.5p1 landen konnte.
An der Stelle natürlich auch vielen vielen Dank, daß der auch gegangen wurde :) Keine Kritik also.

Das gleich gilt wie gesagt für den externen Großzulieferer Sprich, FreeBSD. Auch hier Vielen Dank, daß man da so hinterher war (und ist), aber ein de Raadt würde davon wohl nen Schlaganfall erleiden...

Als Grünschnabel macht man sich halt andere Gedanken. Z.B. daß man die 2.4.5p1 irgendwann diesjahr komplett asp hinbekommt wie gedacht, dann aber doch noch was nachladen will, und das Rep dann sagt, du suchst hier mit 2.4.5, update auf 2.5 dann gibts packages.
Ich will das aber erstmal nicht. Daher auch die Sorge.

Grundsätzlich sehe ich erstmal bei der 2.5 eine nicht nur neue, sondern veränderte Codebasis, und das mit einer erhöhten Komplexität. Die ganzen early adopter Geschichten steht ein Grünschnabel nicht durch.

Ich bräuchte erstmal Ruhe und Zeit mit dem Altbewehrten, mit seinen allseits bekannten Problemchen. Jenes bedeutet schnellen unkomplizierten Support aus der Community (oder es reicht auch nur eine Suchmaschine).

Der Gedanke also, daß man alte Zöpfe langsam wegschnibbelt, wenn die Zeit reif ist und nicht ggf. direkt eine Glatze schneiden sollte.

mfG.

@apietsch
Könnte sein, dass das SYN Paket immer über die VPN läuft, aber weitere nicht.
Um weiterzukommen würde ich entweder das Masquerading mal einrichten, ist eine simple NAT Regel, oder den Traffic dahingehend untersuchen. Letzteres wird aber aufwendiger sein.

Was ist das denn genau für ein Modem, also Modell und Firmware?

Was zeigt die pfSense denn beim Monitoring von System und Quality WAN?
Also Latenz, Paketloss usw.

@anohles said in LAN und IPSEC als Failover?!?:

Ich habe ein Routing um den P2P anzusprechen und dachte in meinem jugendlichen Wahn, dass ich einfach eine Gateway Gruppe mit dem P2P und dem IPSEC bilde. Aber Pustekuchen, ich kann kein IPSEC Gateway für eine Gruppe erstellen, weil mir die Konfig Möglichkeit nicht gegeben wird.

Das liegt schlicht daran, dass Standard IPsec mit Phase 2 Policies KEIN Routing via Gateways, sondern via Policies macht. Wenn du ein Routing mit Gateways willst und an der Stelle brauchst, müsstest du einen IPsec Tunnel via VTI in Phase 2 machen. Dann wird lediglich eine Art Transfernetz wie auch bei OVPN angelegt und du kannst über das Gateway der jeweils anderen Seite ganz reguläre Systemrouten und dann auch Gateway Gruppen erstellen. Stichwort ist VTI in der IPsec Dokumentation :)

Ansonsten geht das aber auch via OpenVPN mit zugewiesenem Interface oder mit dem neuen Wireguard ebenfalls mit zugewiesenem Interface.

Cheers
\jens

@slu
wireguard macht schon nen nahezu always-on vpn. durch die extrem kurzen verbindungszeiten und on-demand funktionen der wireguard app funktioniert das ziemlich prima. akkuverbrauch ist vertretbar.
ich hatte bisher immer ein openvpn zu einem hetzner server mit installiertem pihole, um unterwegs dennoch die vorzüge von "ad free" zu nutzen. ich habe am we mal auf dem hetzner wireguard installiert und am iphone ondemand connect eingestellt. das heißt, wenn ich mich zu hause im wlan befinde ist der tunnel deaktiviert. sobald ich das wlan verlasse baut sich der tunnel auf. komme ich in der firma an, wo sich das telefon ins wlan einwählt, ist kein wirklich spürbarer zeitverzug zu spüren und der tunnel ist ebenfalls
aufgebaut.
also für solche einsatzzwecke ist das schon top. bedenken habe ich eher bei diversen öffentlichen wlan's wo des öfteren udp ports gesperrt sind.

@viragomann said in OpenVPN (pf ist Client) bleibt über Nacht getrennt:

Diesen Job sollte das Watchdog-Package weitaus gezielter erledigen können. Es überwacht die VPN und startet den Service ggf. neu.

Jein, das überwacht ja lediglich den Service Status und wenn der Server Up ist wird da auch nichts neu gestartet, weil der Prozess ja läuft. Mich wundert eher, dass da der Client die Verbindung nicht wieder aufbaut, denn dafür ist das Keepalive Statement zuständig und das funktioniert im Normalfall problemlos egal auf welcher Plattform.