Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - MikeyMike

#1
21.7 Legacy Series / ACME client problems
December 19, 2021, 02:08:21 PM
Hi,

i have the following problems with ACME. I think it´s because of a second entry in the ACME Scheduling Tab (which is not possible anymore because of the new ACME client?!?). I can´t edit or delete this second job because the GUI opens automatically only the first "Renewal" schedule entry and jumps back to the main GUI Page after pressing Save or Cancel (see https://forum.opnsense.org/index.php?topic=20160.0). How can i solve this issue?


PHP Errors:

[19-Dec-2021 10:56:49 Europe/Berlin] PHP Fatal error:  Uncaught Error: Call to a member function init() on null in /usr/local/opnsense/mvc/app/library/OPNsense/AcmeClient/LeCertificate.php:608
Stack trace:
#0 /usr/local/opnsense/mvc/app/library/OPNsense/AcmeClient/LeCertificate.php(401): OPNsense\AcmeClient\LeCertificate->runAutomations()
#1 /usr/local/opnsense/scripts/OPNsense/AcmeClient/lecert.php(170): OPNsense\AcmeClient\LeCertificate->issue()
#2 /usr/local/opnsense/scripts/OPNsense/AcmeClient/lecert.php(199): main()
#3 {main}
  thrown in /usr/local/opnsense/mvc/app/library/OPNsense/AcmeClient/LeCertificate.php on line 608
[19-Dec-2021 10:59:31 Europe/Berlin] PHP Fatal error:  Uncaught Error: Call to a member function init() on null in /usr/local/opnsense/mvc/app/library/OPNsense/AcmeClient/LeCertificate.php:608
Stack trace:
#0 /usr/local/opnsense/mvc/app/library/OPNsense/AcmeClient/LeCertificate.php(401): OPNsense\AcmeClient\LeCertificate->runAutomations()
#1 /usr/local/opnsense/scripts/OPNsense/AcmeClient/lecert.php(170): OPNsense\AcmeClient\LeCertificate->issue()
#2 /usr/local/opnsense/scripts/OPNsense/AcmeClient/lecert.php(199): main()
#3 {main}
  thrown in /usr/local/opnsense/mvc/app/library/OPNsense/AcmeClient/LeCertificate.php on line 608
[19-Dec-2021 11:22:44 Europe/Berlin] PHP Fatal error:  Uncaught Error: Call to a member function init() on null in /usr/local/opnsense/mvc/app/library/OPNsense/AcmeClient/LeCertificate.php:608
Stack trace:
#0 /usr/local/opnsense/scripts/OPNsense/AcmeClient/lecert.php(188): OPNsense\AcmeClient\LeCertificate->runAutomations()
#1 /usr/local/opnsense/scripts/OPNsense/AcmeClient/lecert.php(199): main()
#2 {main}
  thrown in /usr/local/opnsense/mvc/app/library/OPNsense/AcmeClient/LeCertificate.php on line 608


caused by:

2021-12-19T13:09:07 api[70788] [2021-12-19T13:09:07+01:00][error] AcmeClient: HAProxy integration is complete
2021-12-19T13:04:12 api[43950] [2021-12-19T13:04:12+01:00][error] AcmeClient: HAProxy integration is complete
2021-12-19T12:02:32 opnsense[72604] AcmeClient: issue/renewal not required for certificate: yyy.de
2021-12-19T12:02:32 opnsense[72604] AcmeClient: issue/renewal not required for certificate: xxx.de
2021-12-19T12:02:32 api[67250] [2021-12-19T12:02:32+01:00][error] AcmeClient: HAProxy integration is complete
2021-12-19T11:56:47 api[67250] [2021-12-19T11:56:47+01:00][error] AcmeClient: HAProxy integration is complete
2021-12-19T11:56:46 config[22842] [2021-12-19T11:56:46+01:00][error] [OPNsense\AcmeClient\AcmeClient:settings.UpdateCron] Related cron not found.
2021-12-19T11:33:45 api[22842] [2021-12-19T11:33:45+01:00][error] AcmeClient: HAProxy integration is complete
2021-12-19T11:33:37 api[22842] [2021-12-19T11:33:37+01:00][error] AcmeClient: HAProxy integration is complete
2021-12-19T11:22:44 opnsense[7281] AcmeClient: automation not supported: restart_haproxy (7457e177-cf26-4ad0-b8c8-7f3007f42f6d)
#2
Auch nach nach tagelanger Fehlersuche und dem Einspielen eines Backups ist die alte Situation nicht wieder herzustellen. Dementsprechend muss ich aktuell davon ausgehen, das sich in den letzten zwei Updates, die ich direkt hintereinander gemacht habe, sich etwas geändert hat.

Damit ich über OpenVPN Clients überhaupt wieder auf die IPSecClients zugreifen kann musste ich die 10er IPSEC Tunneladresse ebenfalls in den Bereich 192.168.x.x versesetzen.

Kann mir denn niemand wirklich helfen oder einen Tipp geben?
#3
German - Deutsch / Re: Visualisierung der Events
September 12, 2021, 05:13:10 PM
Der Firewall Livelog bietet ja schon einiges.
Für eine detaillierte Übersicht der Verbindungen etc. einfach mal das Plugin os-ntopng installieren.

Alternativ sende ich mir den firewall log noch über telegraf an einen graylog server. Dort wird der log dann zerpflückt und mit geoip Daten in eine Datenbank geschrieben. Das visualisiere ich dann wiederum mittels Grafana. Dieses Konstrukt ist aber recht aufwändig.
#4
German - Deutsch / Routing Probleme / Verständnisproblem
September 12, 2021, 04:52:14 PM
Hallo zusammen,

nachdem ich mittlerweile meine Firewall bei der Fehlersuche ziemlich zerschossen habe brauche ich mal etwas Hilfe um wieder auf die ,,Spur" zu kommen. Um das ganze nicht soweit ausufern zu lassen versuche ich Step by Step meine Probleme zu beschreiben.

Das erste Problem geht um das Thema Routing. Hier meine aktuelles Problem:

Externer Router [192.168.8.1/24] ist via OpenVPN [10.1.1.0/24] mit der opnsense verbunden.
Aus diesem externen Netz kann ich problemlos auf die ,,Hardware" Interfaces [192.168.x.y/16] der opnsense zugreifen.
Ein Traceroute ergibt:

Quotetraceroute to 192.168.30.1 (192.168.30.1), 30 hops max, 60 byte packets
1  192.168.8.1 (192.168.8.1)  0.671 ms  0.642 ms  0.716 ms
2  10.1.1.1 (10.1.1.1)  27.318 ms  27.508 ms  27.842 ms
3  192.168.30.1 (192.168.30.1)  28.091 ms  29.027 ms  29.376 ms

Problem:
Aus diesem externen Netz [192.168.8.1/24] möchte ich ebenfalls auf eine IP [192.168.181.1] zugreifen, welche via IPSEC verbunden ist. Randinfo: Der IPSEC-Tunnel erlaubt nur [192.168.0.0/16] als Source.

Eine Traceroute aus dem externen Netz [192.168.8.1/24] auf diese IP ergibt:
Quotetraceroute to 192.168.181.1 (192.168.181.1), 30 hops max, 60 byte packets
1  192.168.8.1 (192.168.8.1)  0.700 ms  0.615 ms  0.657 ms
2  10.1.1.1 (10.1.1.1)  55.723 ms  64.693 ms  73.057 ms
xyz.dip0.t-ipconnect.de (x.x.x.x)  77.596 ms !N  78.446 ms !N  78.643 ms !N

Frage: Warum leitet die opnsense das ganze auf mein WAN Gateway?

Auf der opensense erscheint folgendes:
QuoteOPNVPNTunnel      Sep 12 12:04:57   10.1.1.2:43098   192.168.181.1:33441   udp      
   OPNVPNTunnel      Sep 12 12:04:57   10.1.1.2:37089   192.168.181.1:33440   udp      
   OPNVPNTunnel      Sep 12 12:04:57   10.1.1.2:33534   192.168.181.1:33439   udp      
   OPNVPNTunnel      Sep 12 12:04:57   10.1.1.2:51400   192.168.181.1:33438   udp      
   OPNVPNTunnel      Sep 12 12:04:57   10.1.1.2:55097   192.168.181.1:33437   udp      

Anbei meine Routes der opnsense:

QuoteDestination        Gateway            Flags     Netif Expire
default            62.155.x.x      UGS      pppoe0
10.1.1.0/24        10.1.1.2           UGS      ovpns1
10.1.1.1           link#12            UHS         lo0
10.1.1.2           link#12            UH       ovpns1
46.81.94.x       link#13            UHS         lo0
62.155.x.x      link#13            UH       pppoe0
127.0.0.1          link#8             UH          lo0
192.168.8.0/24     10.1.1.2           UGS      ovpns1
192.168.10.0/24    link#2             U          igb1
192.168.10.254     link#2             UHS         lo0
192.168.20.0/24    link#3             U          igb2
192.168.20.254     link#3             UHS         lo0
192.168.30.0/24    link#4             U          igb3
192.168.30.254     link#4             UHS         lo0
192.168.180.0/24   62.155.x.x      US       pppoe0
192.168.181.0/24   62.155.x.x      US       pppoe0
192.168.182.0/24   62.155.x.x      US       pppoe0
217.237.148.x     62.155.x.x      UGHS     pppoe0
217.237.151.x    62.155.x.x      UGHS     pppoe0

Frage: Warum gehen keine Pakete in das Zielnetz? Ist die statische route die automatisch gesetzt wird korrekt? Wie und wo kann ich weitersuchen?

Das Ganze hat mal funktioniert bis zum Zeitpunkt x. Hierzu hatte ich zusätzlich noch eine Outbound NAT Rule angelegt, die den Datenverkehr dann via statischem Port und als Translation LAN Adress mappt, damit dieser auch durch den ipsec Tunnel geht. Die Regel greift aber nicht mehr lt. Livelog– siehe log.

Im anderen Forum hatte ich bereits vorgestern mal gepostet, da hielt ich das ganze aber für ein Problem mit Wireguard. Mittlerweile funktioniert aber selbst das hier nicht mehr.
#5
Actually i got it "temporary" running.

I changed the internal Wireguard Subnet 10.x.x.x/24 into the allowed ip range of my IPSEC Tunnel 192.168.x.x/16.
There´s no problem anymore that my wireguard client can reach the ips behind the ipsec tunnel.

But i want to understand what i need to do to get wireguard back into the ip range 10.x.x.x/24 and get snat working. Would be nice if someone can help to find my failure because i like to understand the routing and what´s going wrong here.

Thanks.
#6
Hi,

i have a problem and can´t find any solutions or my network skills are too bad to get it working.

My Problem is i can´t reach a IPSEC IP-Range via Wireguard with Oubound NAT via Translation / target "LAN".
The source natting with static port is needed because only the LAN IP-Range is allowed to pass the IPSEC tunnel.

The "same" construct works via OpenVPN without problems (OpenVPN<->Opensense<->IPSEC Clients)

The Outbound NAT Rules seem to work because the way Wireguard to OpenVPN works also with a rule. The only thing is theres no need to change the source address. I can reach all IPs behind the OpenVPN Network. Internet traffic is working without any Outbound NAT rule.

Maybe someone have some tips for me
Part of my setup:

- 1x WAN
- IPSEC LAN2LAN
- OpenVPN LAN2LAN
- WireGuard with 2 interfaces wg0 (Road Warrior) and wg1 (lan2lan).
- Wireguard Rules are empty
- Wireguard Interface Rules WG0 has a ANY rule

The rules in the WG0+WG1 interface are working.

In the livelog i see that there are incoming pakets from my WG0-Interface with the destination to the IP behind the IPSEC tunnel. The difference between wireguard and openvpn is there is no "nat" in the livelog.
The outbound nat rule with rewriting the source don't seem to work:

Interface: IPSEC - Source: WireguardWG0IF - Destination: ANY - Translation/Target: LAN

I also tried a bit around to install a "dynamic" gateway and disabled routing in the wireguard config. The same behavior. I can´t reach the IP behind the ipsec tunnel.
Do i need a dynamic Gateway? OpenVPN has a Gateway with a fixed address. That´s the only difference i can find.


09:14:13.190215 IP 10.1.2.2.42874 > 192.168.179.1.80: Flags [S], seq 2893322969, win 65535, options [mss 1240,sackOK,TS val 2552133579 ecr 0,nop,wscale 9], length 0
09:14:13.194603 IP WAN-IP > 10.1.2.2: ICMP net 192.168.179.1 unreachable, length 36
09:14:13.214869 IP 10.1.2.2.42876 > 192.168.179.1.80: Flags [S], seq 3959809269, win 65535, options [mss 1240,sackOK,TS val 2552133616 ecr 0,nop,wscale 9], length 0
09:14:13.218739 IP WAN-IP > 10.1.2.2: ICMP net 192.168.179.1 unreachable, length 36




#7
Hallo zusammen,

ich habe mir einen graylog Server mit elasticsearch inkl. grafana aufgesetzt und möchte dementsprechend alle Filterlog Nachrichten loggen und visualisieren und weiter auswerten.

Um die Filterlog via UDP zu erhalten habe ich Anfangs erfolglos versucht die neue Funktion unter Logging / targets zu verwenden. Hier sind nach entsprechendem Eintrag UDP auf den Graylog Server jedoch keine Nachrichten angekommen.  Lt. Anzeige unter Logging / targets -> Statistik wurden jedoch Pakete bearbeitet. Ein zusätzlicher Test mit nxlog von meinem Laptop Richtung graylog funktionierte jedoch tadellos.

Nach viel hin und her habe ich die Weiterleitung unter Logging / targets wieder deaktiviert und habe die Funktion "Entfernter Protokollserver" verwendet. Hier funktionierte erstmal der Protokollempfang der Filterlog auf anhieb.
Mir viel jedoch auf das viele Filterlogeinträge überhaupt nicht versendet werden und unter graylog fehlen.
Das hier UDP Pakete auf dem Weg verloren gehen kann ich mir nicht vorstellen.

Zudem gibt es hier evtl. Probleme in den Configs. Obwohl ich die Weiterleitung unter Protokollierung und Logging / target deaktiviert habe hat mein Graylog Server weiterhin Nachrichten von der opnsense erhalten. Auch ein Neustart etc. der Dienste syslogd und syslog-ng (über die GUI) hat nichts gebracht. Weiterhin wurden Logeinträge gesendet obwohl beides deaktiviert war. Sind hier irgendwie die Configs im Eimer?
Mittlerweile empfange ich zwar wieder Filterlogs, jedoch fehlen erneut viele Pakete die ich in der Live-Anzeige bzw. in der "Originalansicht" sehe die aber scheinbar nicht versendet werden.

Ist es zudem normal, das sich die Dienste syslog-ng und syslogd immer gemeinsam stoppen wenn ein einzelner Dienst von beiden gestoppt wird?

Vielen Dank schonmal.


#8
Hallo zusammen,

nachdem ich mit der OPNsense via WAN Port an einen Port an die FritzBox ran bin und mit dem Notebook an den LAN Port der OPNsense ging ebenfalls nichts. Danach habe ich nochmal ein Reset auf Factory Setting gemacht. Die OPNsense hat sich eine IP geholt etc. und das gleiche Szenario.

Als ich unter Windows ein ipconfig /renew gemacht habe und das ganze hängen blieb habe ich mal das Notebook neu gestartet. Funktionierte dann auf anhieb. Connect, Internet geht. Daraufhin habe ich alles wieder auf meine erste Anfangskonfiguration mit PPPOE gesetzt mit VLAN7... lief ebenfalls auf anhieb  :o

Letztendlich habe ich mich mehr als einen Tag damit rumgeschlagen und es lag an meinem Notebook. Hammer. Irgendwie hat sich unter Windows 10 das Netzwerk aufgehängt. Interessant nur, dass ich die ganze Zeit über den Port auf die OPNSense gekommen bin.  Gateway etc. stimmte alles. Unerklärlich.

Die Fritz hängt jetzt erstmal mit ihrem WAN Port als Router mit eigenem DHCP in der DMZ damit erstmal alles wieder rennt. Da kann man dann langsam nach und nach alles in Ruhe auf die OPNsense umhängen.

Vielen Dank an euch alle für die Vorschläge zur Fehlersuche.

Nachtrag: Jemand anderes hat bzgl. des o. g. "Bugs" ebenfalls mal geschrieben das es irgendwann nach einem de- und reaktivieren der Netzwerkkarte unter Windows etc. das ganze auf einmal funktionierte. Also irgendeine Konstellation während der Installation scheint Windows nicht zu mögen ...
#9
Mahlzeit,

ja die Zuweisung läuft komplett automatisch. Eigentlich sollte genau hier ein funktionsfähiges LAN/WAN Konstrukt raukommen mit Port 80 und 443 von LAN auf WAN. Anfangs hatte ich bei der Installation die Netzwerkschnittstellen über die Konsole manuell zugewiesen: igb0=WAN, igb1=DMZ, igb2=LAN, igb3=WLAN (Reserve).
Um hier ein Problem auszuschließen habe ich die Opnsense auf Factory Settings zurückgesetzt und das automatische Setup versucht igb0=WAN, igb1=LAN. Hat aber auch nichts geändert.

Soweit ich den "Bug" verstanden habe, routet das Default Gateway nicht auf den virtuellen PPPOE Adapter sonder direkt auf die Schnittstelle igb0.

Ich wüsste jetzt nur im Augenblick nicht was mir die Kombi mit der 7590 hilft?
Du meinst also die 7590 als Router lassen und dahinter die Opnsense testen in der WAN/LAN Kombi ohne PPPOE?
#10
Hallo zusammen!

Ich bin im Moment leider mit meinem Latein am Ende und würde mich über etwas Hilfe freuen.
Ich versuche mich kurz zu fassen:

Mein neues Setup: VDSL Telekom <--> Vigor 165 (Full Bride Modus) <--> APU4C4 mit Opensense <--> LAN / WAN

Das Vigor und die APU inkl. Opensense sind für mich komplett Neuland (voher nur 7590). Ich habe am Freitag mein Equipment bekommen und es gestern soweit parametriert, das ich via PPPOE über Opensense inkl. VLAN Tag 7  theoretisch! ins Netz kommen könnte.

Ab diesem Punkt hat das Scheitern dann leider angefangen. Ich komme nicht von meinem Notebook (LAN Port) über den WAN Port ins Internet. Nach stundenlangem Probieren, googeln und scheitern bin ich auf folgenden "Bug" gestoßen: https://github.com/opnsense/core/issues/2186

Wenn ich das jetzt alles soweit richtig verstanden habe, besteht das Problem seit Ewigkeiten das in diesem Fall die WAN Schnittstelle falsch geroutet wird wenn man PPPOE benutzt. Da frage ich mich: Habe ich so ein exostische Setup? Kann doch nicht sein?!? Das Vigor als "Router" zu verwenden mit doppeltem NAT kann doch nicht die Lösung sein. Was machen denn alle anderen?

Stand aktuell: PING/Internet über Console /WebIf funktioniert. Es wird jedoch nichts aus dem LAN oder sonstigen Ports über die WAN Schnittstelle geroutet.

Ich bin jetzt nicht wirklich der Netzwerspezi, also habt bitte etwas Nachsicht. Ich muss mich natürlich noch ordentlich einarbeiten bevor ich hier mit anderen Fragen ankomme. Aber so ein einfaches Setup ohne komplizierte Rules etc. sollte doch irgendwie drin sein.

Sehe ich hier den Wald vor lauter Bäumen nicht oder ist es einfach nicht mein Tag?

Würde gerne den Sonntag noch Sinnvoll nutzen und hoffe es kann mir hier jemand über den Berg helfen ;-)