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 - guenti_r

#31
Quote from: Seimus on October 25, 2024, 10:34:20 AM
By labels you mean the descriptions used by rules?
And what do you mean wrong? How they are wrong?

Yes, the description and if it is blocked or not, completely wrong.
For example, i have a rule that should allow something (with description/label), the firewall live view shows a wrong (other) rule and blocked instead of allowed, and vice versa.

Hopefully this is only a display-issue. This is a OPNsense-HA-Cluster in a datacenter, so when I saw that, I had a heart attack first.

We have alot of OPNsense´s out there, that´s the first time i saw this.
#32
Since upgrade to OPNsense 24.10_7-amd64 Business Edition, the labels in the firewall live view are completely wrong. Is there any known issue?

Hopefully this is only a display issue?

EDIT: issue persists also on community edition 24.7.7
#33
German - Deutsch / Re: Mehr als 255 VHIDs bei CARP?
June 25, 2024, 03:02:59 PM
Quote from: trixter on June 17, 2024, 11:25:50 AM
Das Sense nicht ideal im Thema Routing sind, sehen wir immer wieder, wenn es z.B. um VoIP und ähnliches zeitkritisches geht

Ist zumindest mir neu, in unserem RZ wäre mir da nichts davon aufgefallen...  ???
#34
German - Deutsch / Re: Mehr als 255 VHIDs bei CARP?
June 25, 2024, 02:51:18 PM
VHID LAN- oder WAN-Seitig?
#35
@mooh

Der ISP vergibt immer die gleiche Adresse, je nach Anschluss eben das dazugehörige Netz.

Den Fall, den du schilderst deckt sich mit meinen.... Lease noch gültig... Fühlt sich so an als würde der Provider zufallsbasiert aufhören zu routen, warum auch immer.
Wir haben je nach Location mit unterschiedlichsten Providern zutun (EU), daher ist es gerne mal ein Abenteuer.
Bisher war es bei Businessanschlüssen immer ein statisch zu konfigurierendes WAN, neuerdings (durch Fiber etc.) mehr und mehr über DHCP.
Letztes Abenteuer: Der Provider setzt einen ping via dessen Gateway auf die OPNSense, antwortet diese nicht (default), bricht das Providerseitige Routing ab. Da muss man erstmal draufkommen.

Was Kundenerziehung angeht, da rede ich lieber nicht drüber  :o
#36
Danke erstmal für eure Antworten.

Meine Schilderung -> "Modem ausgefallen" war wohl gelinde gesagt etwas amateurhaft, dafür entschuldige ich mich.

Auch ich vermute, dass das was mit dem ISP zutun hat bzw. deren Firmware am Modem.
Die "Ausfälle" sind schwer zu beschreiben; manchmal resynct sich das Modem neu ohne sich zu rebooten.
Manchmal verliert es einfach die Verbindung ohne ersichtlichen Grund (zeigt sich weiterhin synchron).
Die OPNSense bekommt davon nichts mit, die Gateway-Überwachung zeigt dann offline.

Sobald ich dann an der OPNSense das WAN-Interface neu starte, ist die Verbindung wieder da.
Manche Kunden von uns nehmen dann einfach die OPNSense vom Strom, womit ich da gar keine Freude habe.

Die Frage drängt sich bei mir auch deshalb auf, da wir mittlerweile immer mehr Kunden mit diesen "Modems" haben, wo der Provider nur mehr DHCP als WAN-Anschluss zur Verfügung stellt (DOCSIS, Fiber).

Zur Info, wir verwenden ausschliesslich lizensierte OPNSenses auf DECISO-Hardware.

Derzeit teste ich als Workaround ein Script, das bei längerem erfolglosen Ping am Provider-Gateway das WAN-Interface der OPNSense reloaded.
#37
Ich finde das eigentlich nicht so lustig..... aber jedem das seine.

Habe nun ein script zusammengebastelt, das dieses Problem löst.
#38
Weiss wer zufällig so ein Script, das ich über Monit laufen lassen kann?
Das Problem besteht weiterhin und ist ärgerlich.
Und ja, die OPNSense hängt direkt am Modem; da gibt es bei Ausfall keinen Link-Down-Event.
DOCSIS mit echter öffentlicher WAN-IP/DHCP.
#39
Danke für für Antworten.



#40
Hallo,

Folgendes Setup:
Schnittstellen nur WAN & LAN, kein VLAN etc.
WAN ist via DHCPv4 angebunden, angeschlossen ist ein Cablemodem, das mir eine öffentliche (fixe) WAN IP per DHCP bereit stellt.

Soweit alles gut, nur wenn mal das Modem ausfällt/rebootet etc, macht die OPNSense kein reconnect mehr.

Was hilft, ist die WAN-Schnittstelle neu zu starten oder die ganze OPNSense.

Gibt es da eine Lösung?
#41
Sehr cool, DANKE!  ;D
#42
Oh, Fehler gefunden!

Caddy reloaded/restarted sich nicht gerne über die GUI  :-\

Man drückt reload/restart, im Glauben es wäre so...
Dann geht man davon aus, die Änderungen wären durch. Aber dem ist dann nicht so.
Manuelles restarten über die CLI und plötzlich funktioniert alles einwandfrei!

Somit bin ich also ohne es zu wissen ins offene Messer gerannt.

@Monviech, DANKE!

EDIT: Eben dein Edit übersehen. Ja, das könnte nicht schaden.
#43
Ich sagte ja schon, über die GUI funktioniert es nicht, weil im Handler eine IP anzugeben ist und keine Domain.
Habe im vorherigen Post das funktionierende Besipiel abgebildet.

Manuelles editieren des Caddy-Files geht sofort.
Man benötigt dann auch keine Header Manipulation mehr.

Szenario:
Eine öffentliche WAN-IP mit mehreren gepointeten Domainnamen (www.beispiel1.com, www.beispiel2.com etc...).

OPNSense mit Caddy grundlegend eingerichtet.
Im LAN zB. eine Cloudpanel-VM mit mehreren gehosteten Webseiten (zB: 192.168.1.100).
Im Caddy die gewünschten Domains anlegen.

Für diese Domains KEINE Handlers oder Headers einrichten.

Im Caddyfile die dazugehörigen Einträge folgend abändern:
www.beispiel1.com {
handle {
reverse_proxy 192.168.1.100:443 {
transport http {
tls_server_name www.beispiel1.com
}
}
}

abort
}


und

www.beispiel2.com {
handle {
reverse_proxy 192.168.1.100:443 {
transport http {
tls_server_name www.beispiel2.com
}
}
}

abort
}


Caddy restarten und es funktioniert.

https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#tls_server_name

VORSICHT: Das hier ist experimentell anzusehen  ;)



#44
Leider nein, sobald ich nach einer internen upstream domain gehe, bekomme ich "remote error: tls: unrecognized name"

Extern geht es ohne Probleme.

Hier habe ich was gefunden und angewendet:

https://caddy.community/t/caddy-reverse-proxy-to-multiple-sites-on-port-80/17263/4
#45
UPDATE:

Konnte es mit manuellem editieren hinbekommen, anscheinend geht das noch nicht über die GUI.

Szenario:
Hinter dem Caddy liegt eine lokale Cloudpanel-VM mit der IP 192.168.1.205.
Wenn ich eine neue Website mit einer Beispiel-Domain anlegen will (mit self-signed Cert) dann muss man im Caddyfile folgendes abändern:

www.beispieldomain.at {
   handle {
      reverse_proxy https://192.168.1.205 {

         transport http {
            tls_server_name www.beispieldomain.at
         }
      }
   }


Ist hier nur experimentell; über die GUI funktioniert es so (noch) nicht.