Messages

Neuigkeiten.

Also, wie gehabt. LAN Rule ausgehend - alles erlaubt.
Notebook geht über den transp. Proxy problemlos ins Internet.

Raspi kann 8.8.8.8 nicht pingen und keine Namen auflösen.
Raspi Zero mit frischem Raspbian und WLAN kann auch nicht ins Internet.
FireTV Stick können Netflix und co nicht erreichen.

Doch eher ein grundlegendes Problem. :(

Das muss ich morgen noch Mal testen.
Opn läuft derzeit noch auf einer vm zum testen.
Reiche ich nach :)

Ja, eth0 und feste IP (welche auch reserviert ist) ist mit der richtigen Subnetz Maske eingetragen.

Gleiches Subnetz.
Die fw regeln zum testen auf any allow. Dennoch ohne Erfolg.
Die clients kommen ins Internet.

Ja das passt, ist korrekt.
Lan intern geht's, im Log sieht es auch gut aus.

Dankeschön.
Statisch war es in der dhcpd.conf eingetragen. Ging nicht. Habe es dann auskommentiert, reboot. Leider auch nicht besser.

Merkwürdig finde ich, dass es genau so mit ipfire funktioniert. Auch pihole.

Hallo zusammen,

die reguläre Clients erreichen das Internet (mit und ohne Proxy)
Aufgrund des Troubleshootings ist die ausgehende Regel any allow.

Auf meinem Raspi läuft noch Pihole. Der DNS ist der Primäre für Clients.
Der Raspi ist über DNS Name und IP im LAN erreichbar.
Jedoch scheint der Raspi nicht in das Internet zu kommen.
Weder DNS noch eine einfache aktualisierung des Betriebssystems (apt-get update...) funktioniert.

Laut Live Log der OPN wird die Verbindung vom Raspi zugelassen. Aber es passiert nichts.

Das ganze konstrukt funktioniert unter meiner bisherigen Umgebung mit IPfire problemlos.
Daher denke ich, dass der Fehler im OPN zu suchen ist, aber ich weiß einfach nicht mehr wo.

p.s.
der Raspi erhält seine feste IP per DHCP (reserviert) und wird im DHCPv4 auch als Online gemeldet.

Wenn WIR  :) das zum laufen bekommen, kann ich endlich umschwenken von IPF auf OPN... ;D

Dort habe ich den TOTP und die lokale Database eingetragen, funktioniert dennoch leider nicht.
In welchem Log könnte man auf die Suche gehen?

Hat niemand die 2FA laufen?
:(

Puh, das wird ja richtig kompliziert.
Scheint also gar nicht so erstrebsam zu sein, den SSL Verkehr zu durchsuchen, weil die Hälfte am Ende nicht mehr funktioniert?!

echt, ist dies ein MUSS? ich habe gedacht (ok mein Fehler  ;) ) dass man dies, wie bei üblichen selbstsignierten Zerts mit einer Warnung bestätigen kann und dennoch zugreift.
Hier jedoch schein FF so intelligent zu sein, dass es einen vermeintlichen man-in-the-middle Angriff erkennt.

Wäre das Problem umgehbar, wenn man z.B. Lets Encrypt Zertifikate verwendet? Sofern dies überhaupt möglich ist.

[edit]
scheint ein ähnliches Fehlerbild gehabt zu haben:
https://forum.opnsense.org/index.php?topic=11008.0

Kann eigentlich nur der ca geschuldet sein, oder?
Ich probiere Mal weiter.
Aber dir vielen Dank für deine Unterstützung, bin dadurch schon deutlich weiter gekommen. :)

hier die beiden verschiedenen Fehlermeldung, trotz gleicher Einstellung.

Übrigens, wenn der Haken bei SNI eingeschaltet ist, dann funktioniert es. Dann wird jedoch auch das reguläre Zertifikat verwendet.
Eine Untersuchung auf Viren etc. ist dann nicht möglich

Aufrufen ja, es erscheint jedoch bei HTTPS immer eine Warn oder Fehlermeldung. Je nach Ziel lässt sich diese im Firefox umgehen oder er sagt, es ist ein man in the middle.
Intelligenz von FF?
Bei der Masse an HTTPS Seiten wird diese jedoch wie im screenshot nicht korrekt wiedergegeben.

Läuft derzeit als Test noch auf einer Oracle VM Box auf einem i7 System

Das Subnetz ist auch erlaubt.
Eine HTTPS Webseite habe ich sogar gefunden, die etwas länger zum laden benötuigt, aber dann auch regulär angezeigt wird.