"Recent posts
#81
General Discussion / Re: Console Access/Protectli V...
Last post by OPNenthu - December 30, 2025, 03:09:45 PMI have the V1410 (same family) but no current issues with serial console. In earlier releases (24.7 or early 25.1) there was an issue with a FreeBSD update that broke serial on these devices and a tunable was needed, but that was reverted I think. I'm not using any tunable work-around currently. Protectli also recently released a coreboot v0.9.4 update that addresses it.
For me, enabling the VGA Console caused failure to boot. Maybe I would need to reinstall OPNsense from the VGA image for that, but in any case I have it off. The other relevant settings look the same.
FWIW, I use PuTTY but screen also works.
EDIT: the tunable that needed to be set then was hint.uart.0.at="isa"
For me, enabling the VGA Console caused failure to boot. Maybe I would need to reinstall OPNsense from the VGA image for that, but in any case I have it off. The other relevant settings look the same.
FWIW, I use PuTTY but screen also works.
EDIT: the tunable that needed to be set then was hint.uart.0.at="isa"
#82
German - Deutsch / Caddy + ACME Client mit HTTP-0...
Last post by viragomann - December 30, 2025, 02:49:17 PMHallo,
auf meiner Heiminstallation von OPNsense habe wollte ich nun Caddy versuchen, weil es hier im Forum vielfach als einfach zu konfigurierender Reverse-Proxy bejubelt wird und meinen Anforderungen hier wohl genügt.
Bislang macht mein primärer Webserver (Apache) den Reverse-Proxy für die wenigen Anfragen, die auf andere Hosts gehen sollen. Und auf diesem läuft auch der ACME-Client. Funktioniert eigentlich alles zu gut, als dass ich mich allzu lange mit Alternativen beschäftige. Aber jetzt ist gerade Zeit und auf der OPNsense wäre das auch vielleicht schöner gelöst.
Mit dem Reverse-Proxy muss aber auch der ACME-Client auf die OPNsense übersiedeln. Doch der Client meldet einen Timeout beim Versuch, ein Zertifikat anzufordern.
Mir auch nicht klar, wie HTTP-01 Challenge zusammen mit Caddy überhaupt funktionieren soll. Dieser bekommt ja die HTTP Anfragen und müsste sie dahin weiterleiten, wo der ACME-Client die Challenge deponiert. Hinweise darauf, dass das auch passiert, konnte ich nicht finden.
Nun der ACME-Client bietet hierfür nur "OPNsense Web Service (automatic port forward)". Anders als das HAproxy Plugin stellt Caddy hier ja kein eigenes Service bereit.
Wie soll das nun funktionieren? Ist hier eine entsprechende Weiterleitung manuell in Caddy zu konfigurieren? Wenn ja, wie?
Im Web konnte ich dazu nichts finden. Ich bin nur mehrfach auf Loblieder gestoßen, dass Caddy alles automatisch machen würde. So dachte ich mir, vielleicht trifft das hier auch zu, ist ja wohl keine seltene Herausforderung, und habe mal versucht, ein Zertifikat anzufordern, aber da kommt nichts.
Der ACME-Client loggt
Und Hinweise im Web deuten meist auf ein Firewall-Problem hin, das hier wohl nicht zutrifft. Die Firewall-Regeln habe ich überprüft, Geo-Blocker habe ich deaktiviert und auch den Zugriff von außen getestet.
Letztendlich habe ich während der Zertifikatsanforderung Pcap am WAN laufen lassen. Da sehe ich die Pakete von Let's Encrypt auf meine WAN-IP Port 80 mit der Länge 0, es kommt aber keine Antwort.
Rufe ich selbst den o.g. Pfad von außen auf, sehe ich die Antwortpakete.
Ja, das riecht nach Geo-Blocking. Die Regel hatte ich aber deaktiviert. Die Qell-IP (USA) sollte ohnehin nicht im Alias enthalten sein.
Was ist es dann??
Ich habe das Logging sämtlicher Regeln am WAN aktiviert, ebenso das der Default-Deny Regel und sehe den versuchten Zugriff nicht im Log.
So stellt sich die Frage, was kann die Pakete nach dem Pcap und vor den Filter-Regeln blockieren?
Was mir in diesem Zusammenhang auch ziemlich seltsam erscheint: Caddy beantwortet jede Anfrage auf http://host.mydomain.tld/<egal-was> mit 200.
Die Zusatzfrage wäre also: Kann vielleicht jemand den Sinn dieses erklären?
Vielleicht sollte ich auch noch erwähnen: Caddy funktioniert ansonsten offenbar. Services, die nicht TLS nutzen, habe ich bereits vor Tagen migriert und sind von intern und extern erreichbar. Diese laufen auf Port 80, was mir sagt, dass dieser auf Caddy ankommt. Den zuständigen Reverse-Proxy auf meinem Webserver habe ich deaktiviert.
Hat jemand eine Erklärung für dieses Phänomen?
Grüße
auf meiner Heiminstallation von OPNsense habe wollte ich nun Caddy versuchen, weil es hier im Forum vielfach als einfach zu konfigurierender Reverse-Proxy bejubelt wird und meinen Anforderungen hier wohl genügt.
Bislang macht mein primärer Webserver (Apache) den Reverse-Proxy für die wenigen Anfragen, die auf andere Hosts gehen sollen. Und auf diesem läuft auch der ACME-Client. Funktioniert eigentlich alles zu gut, als dass ich mich allzu lange mit Alternativen beschäftige. Aber jetzt ist gerade Zeit und auf der OPNsense wäre das auch vielleicht schöner gelöst.
Mit dem Reverse-Proxy muss aber auch der ACME-Client auf die OPNsense übersiedeln. Doch der Client meldet einen Timeout beim Versuch, ein Zertifikat anzufordern.
Mir auch nicht klar, wie HTTP-01 Challenge zusammen mit Caddy überhaupt funktionieren soll. Dieser bekommt ja die HTTP Anfragen und müsste sie dahin weiterleiten, wo der ACME-Client die Challenge deponiert. Hinweise darauf, dass das auch passiert, konnte ich nicht finden.
Nun der ACME-Client bietet hierfür nur "OPNsense Web Service (automatic port forward)". Anders als das HAproxy Plugin stellt Caddy hier ja kein eigenes Service bereit.
Wie soll das nun funktionieren? Ist hier eine entsprechende Weiterleitung manuell in Caddy zu konfigurieren? Wenn ja, wie?
Im Web konnte ich dazu nichts finden. Ich bin nur mehrfach auf Loblieder gestoßen, dass Caddy alles automatisch machen würde. So dachte ich mir, vielleicht trifft das hier auch zu, ist ja wohl keine seltene Herausforderung, und habe mal versucht, ein Zertifikat anzufordern, aber da kommt nichts.
Der ACME-Client loggt
Code Select
Invalid status. Verification error details: <WAN IP>: Fetching http://host.mydomain.tld/.well-known/acme-challenge/yvQjtqi_r-FZsC6gsmn1QWQx389QJ3OkCFsbJOk0MHU: Timeout during connect (likely firewall problem)Auch im 'debug 2' Level findet sich kein genauerer Anhaltspunkt.Und Hinweise im Web deuten meist auf ein Firewall-Problem hin, das hier wohl nicht zutrifft. Die Firewall-Regeln habe ich überprüft, Geo-Blocker habe ich deaktiviert und auch den Zugriff von außen getestet.
Letztendlich habe ich während der Zertifikatsanforderung Pcap am WAN laufen lassen. Da sehe ich die Pakete von Let's Encrypt auf meine WAN-IP Port 80 mit der Länge 0, es kommt aber keine Antwort.
Rufe ich selbst den o.g. Pfad von außen auf, sehe ich die Antwortpakete.
Ja, das riecht nach Geo-Blocking. Die Regel hatte ich aber deaktiviert. Die Qell-IP (USA) sollte ohnehin nicht im Alias enthalten sein.
Was ist es dann??
Ich habe das Logging sämtlicher Regeln am WAN aktiviert, ebenso das der Default-Deny Regel und sehe den versuchten Zugriff nicht im Log.
So stellt sich die Frage, was kann die Pakete nach dem Pcap und vor den Filter-Regeln blockieren?
Was mir in diesem Zusammenhang auch ziemlich seltsam erscheint: Caddy beantwortet jede Anfrage auf http://host.mydomain.tld/<egal-was> mit 200.
Die Zusatzfrage wäre also: Kann vielleicht jemand den Sinn dieses erklären?
Vielleicht sollte ich auch noch erwähnen: Caddy funktioniert ansonsten offenbar. Services, die nicht TLS nutzen, habe ich bereits vor Tagen migriert und sind von intern und extern erreichbar. Diese laufen auf Port 80, was mir sagt, dass dieser auf Caddy ankommt. Den zuständigen Reverse-Proxy auf meinem Webserver habe ich deaktiviert.
Hat jemand eine Erklärung für dieses Phänomen?
Grüße
#83
German - Deutsch / Re: Anbindung an die Telematik...
Last post by magicas - December 30, 2025, 02:49:16 PMHi !
So wie ich das verstanden habe hast du vorher im LAN einen "echten" Konnektor gehabt und nun auf einen HK (Highspeedkonnektor) per VPN gewechselt.
Dann drängt sich mir als erstes auf, hast du die "alten" routen auf den jeweiligen Geräten Mac´s gelöscht ?
und dann die neuen gesetzt?
sind die Ports entsprechend angelegt worden? siehe PDF
So wie ich das verstanden habe hast du vorher im LAN einen "echten" Konnektor gehabt und nun auf einen HK (Highspeedkonnektor) per VPN gewechselt.
Dann drängt sich mir als erstes auf, hast du die "alten" routen auf den jeweiligen Geräten Mac´s gelöscht ?
und dann die neuen gesetzt?
sind die Ports entsprechend angelegt worden? siehe PDF
#84
General Discussion / Console Access/Protectli V1211...
Last post by dgrns - December 30, 2025, 02:43:06 PMI'm having a strange issue when trying to access the console on a protecli V1211 (2 port firewall with corebios) running Opnsense 25.7.10
I'm able to connect from a linux host using `screen /dev/tty<name> 115200` However characters are randomly dropped from the output and many times not echoed when typed. Boot messages are garbled and only parts of the opnsense-shell are shown. I am able to type `8` to get to the shell and run commands (with the same dropped character issues).
My current console settings are in the screencap. An example of the corrupted output is:
```
# ls -al
30 08:08 .history
-rw------- 1 root wheel 20 Dec 29 03:03 .wheel 1174 Dec 17 02:56 .shrc
drwx------ 3 root wheel 4 De
```
and partial/truncated opnsense-shell default menu
```
FreeBSD/amd64 (fw) (ttyu0)
::: :::
| Code: https://github.com/opnsense root@fw:~ #
```
I've tried the sc console driver, tried the usb setting, etc. Nothing seems to change the behavior.
Any ideas/thoughts on next steps to troubleshoot this?
Observations:
- I don't remember seeing the dropped character issues on the factory installed 25.7 version. I booted, confirmed connectivity, then applied 25.7.10. My next console access had the issue.
- I also had this on the VP6650 with ami bios. I never was able to get usb-c console working. I was able to use the rj45 console instead, but the V1211 does not have one.
- I've also opened a ticket with Protectli. Will update here if any progress on that front.
I'm able to connect from a linux host using `screen /dev/tty<name> 115200` However characters are randomly dropped from the output and many times not echoed when typed. Boot messages are garbled and only parts of the opnsense-shell are shown. I am able to type `8` to get to the shell and run commands (with the same dropped character issues).
My current console settings are in the screencap. An example of the corrupted output is:
```
# ls -al
30 08:08 .history
-rw------- 1 root wheel 20 Dec 29 03:03 .wheel 1174 Dec 17 02:56 .shrc
drwx------ 3 root wheel 4 De
```
and partial/truncated opnsense-shell default menu
```
FreeBSD/amd64 (fw) (ttyu0)
::: :::
| Code: https://github.com/opnsense root@fw:~ #
```
I've tried the sc console driver, tried the usb setting, etc. Nothing seems to change the behavior.
Any ideas/thoughts on next steps to troubleshoot this?
Observations:
- I don't remember seeing the dropped character issues on the factory installed 25.7 version. I booted, confirmed connectivity, then applied 25.7.10. My next console access had the issue.
- I also had this on the VP6650 with ami bios. I never was able to get usb-c console working. I was able to use the rj45 console instead, but the V1211 does not have one.
- I've also opened a ticket with Protectli. Will update here if any progress on that front.
#85
25.7, 25.10 Series / Re: NAT reflection rules being...
Last post by vimage22 - December 30, 2025, 02:16:52 PMI also had a trouble with DNS after doing a fresh install a couple of week ago. When looking at
"Firewall: Log Files: Live View" and "Firewall: Diagnostics: States:"
I noticed it was complaining about this setting:
Interfaces: [WAN] > Block private networks
I executed "Firewall: Diagnostics: States: Actions: Reset state table".
Everything works great now, but resetting this table has become a very important step when setting up or making changes to the Firewall settings.
"Firewall: Log Files: Live View" and "Firewall: Diagnostics: States:"
I noticed it was complaining about this setting:
Interfaces: [WAN] > Block private networks
I executed "Firewall: Diagnostics: States: Actions: Reset state table".
Everything works great now, but resetting this table has become a very important step when setting up or making changes to the Firewall settings.
#86
25.7, 25.10 Series / Re: Upgrade version discrepanc...
Last post by Maurice - December 30, 2025, 01:55:25 PMAll your packages (including opnsense core itself) are up-to-date, but kernel and base (the underlying FreeBSD system) are not. So you are in fact on the latest OPNsense version, but need to update kernel and base.
You may have connectivity issues, it even fails to fetch the changelog. You might want to try a different mirror.
Cheers
Maurice
You may have connectivity issues, it even fails to fetch the changelog. You might want to try a different mirror.
Cheers
Maurice
#87
General Discussion / Re: Simple Port Forward Failin...
Last post by viragomann - December 30, 2025, 11:55:44 AMIn a port forwarding rule you should state a certain destination address instead of any, WAN address in this case.
However, according to the log, the forwarded traffic is passed out on the MGMT interface. You can sniff the traffic on the interface with the pacekt capture tool (Interfaces > Diagnostic) to investigate this.
Possibly your webserver blocks access from outside of its subnet and you have to allow the access in its firewall.
However, according to the log, the forwarded traffic is passed out on the MGMT interface. You can sniff the traffic on the interface with the pacekt capture tool (Interfaces > Diagnostic) to investigate this.
Possibly your webserver blocks access from outside of its subnet and you have to allow the access in its firewall.
#88
Virtual private networks / OPENVPN Export Archive 0 bytes
Last post by myksto - December 30, 2025, 11:52:29 AMOPNsense 25.7.10-amd64
I tried to export OpenVPN archive in VPN -> OpenVPN -> Client Export but every user I try to export is a 0 byte zip file.
How can I solve this?
Thanks,
Michele.
I tried to export OpenVPN archive in VPN -> OpenVPN -> Client Export but every user I try to export is a 0 byte zip file.
How can I solve this?
Thanks,
Michele.
#89
German - Deutsch / OPNsense -> SQUID -> PBR -> Mu...
Last post by Elleven - December 30, 2025, 11:45:44 AMHi,
ich habe an meiner OS zwei WANs, die zunächst gleichberechtigt im Lastenausgleich laufen sollen. Über Policy based Routing kann ich in den einzelnen FW-Regeln recht gut steuern, über welche WAN-Schnittstelle bestimmte Dienste laufen sollen. Ist deshalb gewollt, weil Bandbreiten als auch Latenz der beiden WANs unterschiedlich ist. Zudem ist ein WAN weniger vertrauenswürdig, weil's über den schrägen ELON läuft ;-)
Was ich jetzt aber noch nicht hinbekommen habe, dass schnöde Webzugriffe (HTTP, HTTPS / 80/443), die durch den SQUID als transparenten Proxy laufen sollen, irgendwie auch auf gezielte Wege mittels PBR geschickt werden können. Im ersten Schritt werden die Anfragen auf 80 /443 an die Proxy-Ports genattet. Nach dem SQUID scheinen die Anfragen bereits an einer der WAN-Schnittstellen ausgehend zu sein, d.h. da scheint PBR bereits zu spät. In der NAT-Regel kann ich augenscheinlich nichts zum Thema Gateway mitgeben und die Regel zwischen NAT und SQUID hat ja als Ziel den LOCALHOST, also kann man hier ja gar nicht sonnvoll eingreifen.
Irgendwie müssten die ausgehenden Pakete des SQUID gedanklich erstmal an eine interne Schnittstelle als Pseodo-Gateway gehen, auf der man dann PBR-Regeln festlegen könnte. D.h. der ganze Salmon geht dann doppelt durch die OS.
Gibt es eine Musterlösung dazu? Welche Optionen hätte man?
ich habe an meiner OS zwei WANs, die zunächst gleichberechtigt im Lastenausgleich laufen sollen. Über Policy based Routing kann ich in den einzelnen FW-Regeln recht gut steuern, über welche WAN-Schnittstelle bestimmte Dienste laufen sollen. Ist deshalb gewollt, weil Bandbreiten als auch Latenz der beiden WANs unterschiedlich ist. Zudem ist ein WAN weniger vertrauenswürdig, weil's über den schrägen ELON läuft ;-)
Was ich jetzt aber noch nicht hinbekommen habe, dass schnöde Webzugriffe (HTTP, HTTPS / 80/443), die durch den SQUID als transparenten Proxy laufen sollen, irgendwie auch auf gezielte Wege mittels PBR geschickt werden können. Im ersten Schritt werden die Anfragen auf 80 /443 an die Proxy-Ports genattet. Nach dem SQUID scheinen die Anfragen bereits an einer der WAN-Schnittstellen ausgehend zu sein, d.h. da scheint PBR bereits zu spät. In der NAT-Regel kann ich augenscheinlich nichts zum Thema Gateway mitgeben und die Regel zwischen NAT und SQUID hat ja als Ziel den LOCALHOST, also kann man hier ja gar nicht sonnvoll eingreifen.
Irgendwie müssten die ausgehenden Pakete des SQUID gedanklich erstmal an eine interne Schnittstelle als Pseodo-Gateway gehen, auf der man dann PBR-Regeln festlegen könnte. D.h. der ganze Salmon geht dann doppelt durch die OS.
Gibt es eine Musterlösung dazu? Welche Optionen hätte man?
#90
German - Deutsch / Web-Kategorien (SQUID + ACLs) ...
Last post by Elleven - December 30, 2025, 10:51:41 AMHi,
irgendwie werden mir zu geladenen ACLs im SQUID keinerlei Kategorien angezeigt. Im Internet findet man dazu zwar endlos viele Beiträge und das eigentlich auch schon seit vielen Monaten, aber irgendwie keine vernüftige Lösung, außer über das CLI irgendein Index neu aufzubauen. Ich hätte da meine Sorge, dass man das dann nach jedem Update der Listen neu machen darf. Es wird auch von anderen Lösungen berichtet, die aber nicht funktionieren (z.B. SQUID oder gleich die OS neu starten). Man könne auch die einzelnen Listen (bei UT 1 z.B.) kategoriebezogen runterladen und dann hätte man es ja!?!?
Mich wundert etwas, dass dieses Problem schon länger zu bestehen scheint, aber dennoch keinerlei nachhaltige Lösung existiert. Meine Version ist die 25.10.1).
Mache ich hier irgendwas banales falsch oder ist das jetzt wirklich so? D.h. die Kategorien scheinen komplett nicht nutzbar zu sein. Auch hab ich noch nicht herausgefunden, wo ich die Kategorien nachher dann individuell für einzelne Clients aktivieren kann, wenn sie denn dann funktionieren täten.
irgendwie werden mir zu geladenen ACLs im SQUID keinerlei Kategorien angezeigt. Im Internet findet man dazu zwar endlos viele Beiträge und das eigentlich auch schon seit vielen Monaten, aber irgendwie keine vernüftige Lösung, außer über das CLI irgendein Index neu aufzubauen. Ich hätte da meine Sorge, dass man das dann nach jedem Update der Listen neu machen darf. Es wird auch von anderen Lösungen berichtet, die aber nicht funktionieren (z.B. SQUID oder gleich die OS neu starten). Man könne auch die einzelnen Listen (bei UT 1 z.B.) kategoriebezogen runterladen und dann hätte man es ja!?!?
Mich wundert etwas, dass dieses Problem schon länger zu bestehen scheint, aber dennoch keinerlei nachhaltige Lösung existiert. Meine Version ist die 25.10.1).
Mache ich hier irgendwas banales falsch oder ist das jetzt wirklich so? D.h. die Kategorien scheinen komplett nicht nutzbar zu sein. Auch hab ich noch nicht herausgefunden, wo ich die Kategorien nachher dann individuell für einzelne Clients aktivieren kann, wenn sie denn dann funktionieren täten.
