Messages

31

German - Deutsch / Re: APIPA-Adresse routen

« on: May 18, 2022, 02:32:06 pm »

Ja, den Port Forwarding Vorschlag würde ich gerne aufgreifen.
Das habe ich genau so versucht. Hat aber leider nicht funktioniert.

Wird jetzt noch eine Ausgehende NAT-Regel benötigt?

32

German - Deutsch / Re: APIPA-Adresse routen

« on: May 18, 2022, 12:13:00 pm »

Ausgendes NAT steht auf "Hybride Einstellungen". Eine separate Regel wurde für diesen Anwendungsfall bisher nicht angelegt.
Fehlt hier noch was?

Die 10er IP muss zur 169.254.2.2 werden.

Du meinst also die IP der Schnittstelle und der virtuellen IP tauschen? Das hatte ich bereits, hat aber keinen Unterschied gemacht.

/30 hätte ich auch nicht genommen sondern den offiziellen /16 da die andere Seite das ja wahrscheinlich auch hat.

Nachdem der Ping in der Konstellation mit /30 von der OPNsense funktioniert hatte, würde ich hier nicht das Problem vermuten.

33

German - Deutsch / Re: APIPA-Adresse routen

« on: May 18, 2022, 11:51:34 am »

Probier, die Sense statisch auf 169.254.2.2 einzustellen, am entsprechenden Port, und ob du von der Sense aus den Speedport anpingen kannst.

Anpingen von der Sense aus funktioniert schon mal.

Wenn ja, dann sollte ein Port-Forwarding-NAT (routet ja nicht) von einer regulären Adresse - z.B. eine virtuelle Adresse intern - auf die 169.254.2.1 möglich sein.

Damit hatte ich leider weniger Glück.
Habe die Schnittstelle zum Modem mit der IP-Adresse 10.10.11.1/30 versehen.
Dann eine virtuelle IP-Adresse 169.254.2.2/30 (Typ "IP Alias") angelegt und der Schnittstelle zum Modem zugewiesen.
Über die Regel zur NAT-Portweiterleitung habe ich dann festgelegt, dass alle Anfragen die an die 10.10.11.1 gehen an die 192.254.2.1 umgeleitet werden sollen.
Über die Firewall-Regeln habe ich dann noch festgelegt, dass ich von meinem Client aus überall hin zugreifen darf.
Von meinem Client habe ich dann versucht https://10.10.11.1 aufzurufen.
Es konnte aber leider keine Verbindung hergestellt werden.

Was mache ich falsch?

Kann mir jemand helfen die richtigen Regeln für mein Szenario anzulegen?

34

German - Deutsch / Re: APIPA-Adresse routen

« on: May 10, 2022, 01:12:06 pm »

Die Telekom hat zwischenzeitlich bestätigt, dass die vorgegebene IP-Adresse des Speedports nicht geändert werden kann.

Gibt es noch Ideen wie man auf die 169.254.2.1 hinter der OPNsense zugreifen könnte?

35

German - Deutsch / APIPA-Adresse routen

« on: April 28, 2022, 06:24:47 pm »

Hallo,

aus Kompatibilitätsgründen mit dem örtlichen DSLAM musste ich meinen Draytek Vigor 165, der als Modem für meinen VDSL-Anschluss diente, durch einen Speedport Smart 3 der Telekom ersetzen.

Dieser läuft, wie der Vigor zuvor auch schon, im reinen Modem-Betrieb.
Nun möchte ich gerne auf die Info-Seite des Speedports zugreifen können, um die Werte einsehen zu können mit denen der Anschluss synchron wird.
Dazu habe ich wie in der Anleitung auf den Seiten 293/294 beschrieben die OPNsense mit Port LAN1 verbunden.

Unglücklicherweise lässt sich die Statusseite des Speedports aber nur über die fest vorgegebene APIPA-Adresse 169.254.2.1 aufrufen.
Gemäß RFC-Spezifikation darf eine solche Adresse ja nicht geroutet werden.

Welche Möglichkeiten habe ich nun, um aus einem anderen Subnetz auf das Gerät zugreifen zu können?

36

German - Deutsch / Re: ACME Client - Zertifikat kann nicht für NGINX verwendet werden

« on: March 05, 2022, 03:35:37 pm »

Ja, die entsprechenden Regeln sind vorhanden und funktional.


"(Re-) Import certificate" hat das Problem beheben können 

37

German - Deutsch / ACME Client - Zertifikat kann nicht für NGINX verwendet werden

« on: March 03, 2022, 12:59:24 pm »

Hallo,

habe hier ein seltsames Problem.

Über das ACME-Client-Plugin lasse ich ein Wildcard-Zertifikat über eine DNS-01-Challange bei Letsencrypt erstellen.
Bisher war es so, dass ich dieses Zertifikat dann in den Einstellungen für die HTTP-Server in NGinx als TLS-Zertifikat auswählen konnte.

Jetzt steht das Zertifikat hier aber nicht mehr zur Auswahl.
Bei den bisher erstellten HTTP-Server ist in der Übersicht die Spalte "Zertifikat" jetzt leer.
Bei neu erstellten HTTP-Servern steht in der Übersicht in der Spalte "Zertifikat" "keiner".

Die bisher erstelleten HTTP-Server funktionieren weiterhin mit den Wildcard-Zertifikat.
Die neu erstellten HTTP-Server funktionieren hingegen nicht.


Daraufhin habe ich ein Renew für das Zertifikat über die GUI erzwungen. Laut Log ist das auch durchgelaufen.
Anschließend wurde NGinx auch neu gestartet.
Die bisher erstellten HTTP-Server nutzen jedoch weiterhin das alte Zertifikat.
Und weiterhin steht das Zertifikat nicht für die TLS-Verschlüsselung zur Auswahl.

Merkwürdig auch, dass in der Gui das Ausstellungs-/Erneuerungsdatum weiterhin auf dem Daten der letzten Erneuerung steht.
Auch unter "System" -> "Sicherheit" -> "Zertifikate" taucht das Zertifikat nicht auf.


Was ist hier die Fehlerursache?


OPNsense 22.1.2-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1m 14 Dec 2021

38

German - Deutsch / Re: Windows 10 verliert IPv6

« on: March 02, 2022, 12:52:07 pm »

@KHE
in meinem Fall sind die Windows-Clients in einem VLAN.
Das Parent Interface ist enabled, hat aber IPv4 aktiv und auch eine Globale IPv6-Adresse.


An einer anderen Stelle habe ich davon gelesen, dass die Problematik auch im speziellen mit Unifi-Geräten auftreten würde. Finde leider den Beitrag nicht mehr.

Die Anpassung der Werte in den RouterAdvertisements musste ich jedenfalls wieder rückgängig machen, nachdem ich meinen Unifi-Controller vorgestern auf die neueste Version aktualisiert hatte.

39

German - Deutsch / Re: Unbound - error: SSL_handshake syscall: Connection reset by peer

« on: March 02, 2022, 10:38:10 am »

Ja. So sieht das bei mir aus und hatte bisher wunderbar funktioniert:

40

German - Deutsch / Re: Unbound - error: SSL_handshake syscall: Connection reset by peer

« on: March 02, 2022, 09:31:02 am »

Der Fehler ist nach wie vor vorhanden:

Code: [Select]

2022-03-02T08:30:11 Error unbound [27216:1] error: SSL_handshake syscall: Connection reset by peer

41

German - Deutsch / Re: Unbound - error: SSL_handshake syscall: Connection reset by peer

« on: March 01, 2022, 08:14:41 pm »

Hallo Franco,

Vielleicht seit 22.1?

ja, das dürfte hinkommen.

42

German - Deutsch / Unbound - error: SSL_handshake syscall: Connection reset by peer

« on: March 01, 2022, 06:06:27 pm »

Mein Unbound-Log wird seit einiger Zeit von diesen Meldungen gefüllt:

Code: [Select]

error: SSL_handshake syscall: Connection reset by peer
Die DNS-Abfragen dauern auch außergewöhnlich lange.
Über nslookup werden bei Abfragen häufig erst zwei Timeouts ausgegeben, bevor die IP abgerufen werden kann.

Als DNS over TLS sind die 4 Adressen der Digitalen-Gesellchaft.ch eingetragen.
Andere DNS-Server sind nirgends hinterlegt.

OPNsense läuft in der aktuellsten Version 22.1.2.

Weiß jemand wie diese Fehler behoben werden können?

43

German - Deutsch / Re: Windows 10 verliert IPv6

« on: February 28, 2022, 03:28:42 pm »

Hallo,

das Problem war mir nach dem Upgrade auf v22.1 auch aufgefallen.
Unter Windows 10 konnten stellenweise keine IPv6-Adressen bezogen werden, bzw. kein IPv6-DNS-Server.
Zusätzlich haben Android-Clients nach einer gewissen Zeit die IPv6-Konfiguration verloren.
Auch hier half (temporär) nur Neustart von RA und DHCPv6.

Zumindest unter Windows konnte ich das Problem lösen indem ich die folgenden Werte in den Router-Advertisements angepasst habe:

• AdvDefaultLifetime: 9000
• AdvPreferredLifetime: 7200
• AdvRDNSSLifetime: 1800
• AdvDNSSLLifetime: 1800
• AdvRouteLifetime: 1800

Bei Android hat sich der Fehler dadurch gebessert, aber früher oder später verlieren sich die IPv6-Adressen dann doch wieder.


Außerdem aufgefallen ist mir, dass nach einem Neustart der OPNsense der DHCPv6-Dienst nicht gestartet werden kann.
Manuell kann ich ihn dann aber starten.
Gleiches gilt für Wireguard-go.

Es scheint fast wie ein Timing-Problem, bei dem vom System zu früh versucht wird die Dienste zu starten und notwendige Abhängigkeiten noch nicht bestehen.

Kann mir jemand sagen, wie ich einen Cron-Job anlegen kann, der DHCPv6 und Wireguard-go sagen wir 1 Minute nach dem Systemstart automatisch startet?

44

German - Deutsch / Re: DHCPv6 WAN, SLAAC LAN - Android IPv6

« on: February 23, 2022, 09:22:36 am »

das Lustige bei mir: DNSv6 ist das Einzige, was ich zugewiesen bekomme.

Dieses Verhalten hatte ich nach dem Upgrade auf v22.1 auch.
Eine Anpassung der folgenden Werte in den Router-Advertisements hat Abhilfe gebracht:

• AdvDefaultLifetime: 9000
• AdvPreferredLifetime: 7200
• AdvRDNSSLifetime: 1800
• AdvDNSSLLifetime: 1800
• AdvRouteLifetime: 1800

45

German - Deutsch / Re: Einstellungen für schreibgeschützten Zugriff auf Weboberfläche

« on: February 23, 2022, 09:15:20 am »

Danke, das hat funktioniert.
Ich habe noch nicht alle Funktionen mit der Einstellung testen können, aber bisher scheint es so zu klappen wie ich mir das vorgestellt hatte.

Ich war nur zuerst etwas irritiert, da von dem "view-only"-Benutzer weiterhin Einstellungen getroffen werden konnten und auch die "Speichern"-Schaltfläche weiterhin vorhanden war.
Nur dass eben nach einer Anpassung beim Klicken auf "Speichern" die Änderungen wieder verworfen werden, bzw. nicht übernommen.
Auch dass der "view-only"-Benutzer noch Dienste starten und stoppen kann hat mich etwas verwundert.