"Recent posts
#1
German - Deutsch / HA Cluster - keine Web-Verbind...
Last post by Flar69 - Today at 12:36:36 PMHallo Gemeinde,
wir haben 2 baugleiche Opensense erfolgreich eingerichtet und am Laufen.
Die Konstellation:
Ein MultiWan-Router für 2 ISP. Dieser hält auch die Zugangsdaten.
Am Router habe ich auch für jedes Wan ein zugeordnetes Lan zur Opensense. So kann ich das Failover auf der Sense machen.
Dazwischen ein L3 Switch mit Portisolation für jedes Netz (Wan1, Wan2, Lan, WLAN, usw.)
HA Cluster erfolgreich eingerichtet (Alle Ports stehen auf Master bzw. Backup)
Nach erfolgreicher Synchronisation bekomme ich aber keine Verbindung mehr vom Backup zum Router bzw. ins Web.
Beide Gateways sind down.
Mit ist klar, dass die Carp-Adressen ja down sind zwecks Backup.
Aber die eigentlichen Netzwerk-Adressen sollten ja noch funktionieren?
Die Lan-Adresse der Backup-Sense ist ja auch erreichbar.
Habe hier den Tipp gelesen, einfach noch ein weiteres Gateway zur Master zu erstellen.
Aber bei der nächsten Synchronisation wird mir das wieder gelöscht.
Die Frage ist, ob das Verhalten normal ist?
Und wenn ja, wie mache ich dann Firmwareupdates auf der Backup ohne Wan?
Mit bestem Dank im Voraus
Ralf
wir haben 2 baugleiche Opensense erfolgreich eingerichtet und am Laufen.
Die Konstellation:
Ein MultiWan-Router für 2 ISP. Dieser hält auch die Zugangsdaten.
Am Router habe ich auch für jedes Wan ein zugeordnetes Lan zur Opensense. So kann ich das Failover auf der Sense machen.
Dazwischen ein L3 Switch mit Portisolation für jedes Netz (Wan1, Wan2, Lan, WLAN, usw.)
HA Cluster erfolgreich eingerichtet (Alle Ports stehen auf Master bzw. Backup)
Nach erfolgreicher Synchronisation bekomme ich aber keine Verbindung mehr vom Backup zum Router bzw. ins Web.
Beide Gateways sind down.
Mit ist klar, dass die Carp-Adressen ja down sind zwecks Backup.
Aber die eigentlichen Netzwerk-Adressen sollten ja noch funktionieren?
Die Lan-Adresse der Backup-Sense ist ja auch erreichbar.
Habe hier den Tipp gelesen, einfach noch ein weiteres Gateway zur Master zu erstellen.
Aber bei der nächsten Synchronisation wird mir das wieder gelöscht.
Die Frage ist, ob das Verhalten normal ist?
Und wenn ja, wie mache ich dann Firmwareupdates auf der Backup ohne Wan?
Mit bestem Dank im Voraus
Ralf
#2
25.7, 25.10 Series / Re: Unable to get Multiwan Loa...
Last post by apunkt - Today at 12:15:05 PMDid you set in the LAN default any to any rule the WAN_GROUP as Gateway?
It points to the default gateway in default settings.
It points to the default gateway in default settings.
#3
General Discussion / Re: caddy, dmz and web apps
Last post by caplam - Today at 11:59:30 AMThank you for your answers.
I have only one docker host; but now when i create a bridge network for a stack i bind it to a particular subinterface of the host as per default docker listen to all interfaces. For compose stacks i put the webserver in a macvlan (if it's more convenient) or a bridge in the dmz vlan and the others containers in another vlan network.
My authentik stack authenticates apps for lan or internet users and also apps only accessible from lan. For now its listening interface is in the lan but i wonder if i should move it to dmz. I'm also trying to force all apps through caddy and authentik to have an authentication and use the same hostname to access it whether i'm inside or outside.
The same goes for caddy. If i understood correctly caddy process is listening on all interfaces. But i think i don't really get the path of a packet.
Caddy listen on ports 80&443.
If the request comme from outside, it arrives on wan interface which caddy listens to. Then it processes the request to upstream server or forward the request to authenticating server depending on the authentication type (oauth or proxy).
For this request to be actually effective you need a firewall rule on wan interface to pass the pack to "this firewall".
If the request comes from the inside on the interface (LAN for now) where the user is. Then the request is processed as in the first case.
For this request to be actually effective you need a firewall rule on lan interface (or the interface on vlan where users resides) to pass the pack to "this firewall".
So if i'm correct when the reverse proxy is on the firewall itself you can't really put it in the dmz. The only thing i can do is move authentik to dmz and eventually change my users vlan from lan to another one.
Another thing i need to take care of is that the app with oidc provider need to contact the authentik server. For now as authentik is in the lan i have a firewall rule passing request from apps in the dmz with oidc provider to authentik server (not sure about that one as i don't which container of the stack actually makes the request).
For example i have a jellyfin docker in dmz which can't authenticate without such a rule (it's only one container).
But i have a nextcloud-aio (13 containers in a vlan bridge and the apache one in dmz bridge) which can authenticate without the rule.
Forget about that my authentik stack is still in a bridge network that is not bound to a particular interface so it listens to all. I consider this as a security hole and i have to modify my authentik bridge network so that it listens to only one interface.
I guess it's the danger to have a docker host with several interfaces.
I have only one docker host; but now when i create a bridge network for a stack i bind it to a particular subinterface of the host as per default docker listen to all interfaces. For compose stacks i put the webserver in a macvlan (if it's more convenient) or a bridge in the dmz vlan and the others containers in another vlan network.
My authentik stack authenticates apps for lan or internet users and also apps only accessible from lan. For now its listening interface is in the lan but i wonder if i should move it to dmz. I'm also trying to force all apps through caddy and authentik to have an authentication and use the same hostname to access it whether i'm inside or outside.
The same goes for caddy. If i understood correctly caddy process is listening on all interfaces. But i think i don't really get the path of a packet.
Caddy listen on ports 80&443.
If the request comme from outside, it arrives on wan interface which caddy listens to. Then it processes the request to upstream server or forward the request to authenticating server depending on the authentication type (oauth or proxy).
For this request to be actually effective you need a firewall rule on wan interface to pass the pack to "this firewall".
If the request comes from the inside on the interface (LAN for now) where the user is. Then the request is processed as in the first case.
For this request to be actually effective you need a firewall rule on lan interface (or the interface on vlan where users resides) to pass the pack to "this firewall".
So if i'm correct when the reverse proxy is on the firewall itself you can't really put it in the dmz. The only thing i can do is move authentik to dmz and eventually change my users vlan from lan to another one.
For example i have a jellyfin docker in dmz which can't authenticate without such a rule (it's only one container).
But i have a nextcloud-aio (13 containers in a vlan bridge and the apache one in dmz bridge) which can authenticate without the rule.
Forget about that my authentik stack is still in a bridge network that is not bound to a particular interface so it listens to all. I consider this as a security hole and i have to modify my authentik bridge network so that it listens to only one interface.
I guess it's the danger to have a docker host with several interfaces.
#4
25.7, 25.10 Series / Re: Adding a VLAN takes 26 cli...
Last post by Monviech (Cedrik) - Today at 11:59:14 AMI guess this mostly falls into the Macro/Wizard dicussion.
Technically a vlan, layer 3 interface and dhcp are different technologies. So the GUI does not intermingle them for maximum flexibility.
Since all new components are API enabled, crafty individuals could build their own workflows (e.g a script that does exactly what they want with all assumptions their environment requires)
These could also have their own GUIs as the plugin system is very advanced and can hook into existing models.
For more inspiration check out the new system wizard.
Technically a vlan, layer 3 interface and dhcp are different technologies. So the GUI does not intermingle them for maximum flexibility.
Since all new components are API enabled, crafty individuals could build their own workflows (e.g a script that does exactly what they want with all assumptions their environment requires)
These could also have their own GUIs as the plugin system is very advanced and can hook into existing models.
For more inspiration check out the new system wizard.
#5
25.7, 25.10 Series / Re: Adding a VLAN takes 26 cli...
Last post by meyergru - Today at 11:53:54 AMAnd how would you actually go about that?
I often pointed to the obvious fact that along with great flexibility and functionality, "easy going" for end-users goes out the window. I accept the fact that OpnSense is an expert tool.
As a simple example, take the fact that ISC DHCPv4 is a part of the initial rant (while that did not even include the firewal setup or IPv6). And at this point, we have no less than three (!) DHCP daemons, namely ISC, Kea and DNSmasq. Which would you choose if the process was indeed more streamlined?
The only approach I could imagine was a set of some kind of "helpers for common tasks", but these would have to be on top of the fine-grained settings menus. Also, they would be prone to break pre-existent settings, just because they have to be limited to default settings (which ones, BTW?) instead of the wide variety of potential settings.
I can already picture upcoming forum discussions about how the default X of helper Y "does not suit my needs, can we change it or at least make it selectable?".
I often pointed to the obvious fact that along with great flexibility and functionality, "easy going" for end-users goes out the window. I accept the fact that OpnSense is an expert tool.
As a simple example, take the fact that ISC DHCPv4 is a part of the initial rant (while that did not even include the firewal setup or IPv6). And at this point, we have no less than three (!) DHCP daemons, namely ISC, Kea and DNSmasq. Which would you choose if the process was indeed more streamlined?
The only approach I could imagine was a set of some kind of "helpers for common tasks", but these would have to be on top of the fine-grained settings menus. Also, they would be prone to break pre-existent settings, just because they have to be limited to default settings (which ones, BTW?) instead of the wide variety of potential settings.
I can already picture upcoming forum discussions about how the default X of helper Y "does not suit my needs, can we change it or at least make it selectable?".
#6
Virtual private networks / Re: FR: Will OPNsense adopt th...
Last post by Monviech (Cedrik) - Today at 11:46:30 AMReading the reviews link it does not seem like that commit is in FreeBSD 14. Which means this will not hit the OPNsense kernel for a while if its not backported. So this looks more like it takes well into 2026-27 and FreeBSD 15 based OPNsense.
#7
Virtual private networks / Re: FR: Will OPNsense adopt th...
Last post by cdine - Today at 11:29:58 AMJust replying to also voice my desire and support of this feature.
The Tailscale team has done some great work with this upstream in FreeBSD/pf with the FreeBSD Foundation's support. They called out OPNSense by name, so I do hope this makes its way in to OPNSense once it makes its way in to FreeBSD stable. From the looks of things, it is not yet there - see discussion in the review link below.
There appears to have also been an issue opened in the OPNSense repo asking for support of this, but it was auto-closed.
Links:
The Tailscale team has done some great work with this upstream in FreeBSD/pf with the FreeBSD Foundation's support. They called out OPNSense by name, so I do hope this makes its way in to OPNSense once it makes its way in to FreeBSD stable. From the looks of things, it is not yet there - see discussion in the review link below.
There appears to have also been an issue opened in the OPNSense repo asking for support of this, but it was auto-closed.
Links:
- Review thread with (well, sort of) recent discussion: https://reviews.freebsd.org/D11137
- Parent bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219803
- Project page for the work: https://www.freebsd.org/status/report-2024-07-2024-09/eim-nat/
- Tailscale blog post about the work as shared by TheDragon: https://www.freebsd.org/status/report-2024-07-2024-09/eim-nat/
- OPNSense GitHub issue asking for support of this feature: https://github.com/opnsense/core/issues/8384
#8
25.7, 25.10 Series / Re: Adding a VLAN takes 26 cli...
Last post by bimbar - Today at 11:18:10 AMThis might best be part of a wider discussion about usability, which, in my opinion, is not necessarily the top priority in opnsense development.
I think more focus on this would be beneficial.
I think more focus on this would be beneficial.
#9
General Discussion / Re: [Help Needed] Block outgoi...
Last post by meyergru - Today at 10:04:48 AMIn practice, this makes little sense, because, unless you explicitely disallow any traffic, you will not be safe against exfiltration anyway:
Consider any other type of traffic being allowed, like HTTPS - since you cannot break up that encrypted connection, you know jack about what is in it. And this is even true for outbound connections. Of course, any IP connection can be used in any direction regardless of the direction it was initially started in.
The only reason why this is psychologically threathening is that because ICMP ping is usually not a real connection, it looks somewhat sneaky.
Consider any other type of traffic being allowed, like HTTPS - since you cannot break up that encrypted connection, you know jack about what is in it. And this is even true for outbound connections. Of course, any IP connection can be used in any direction regardless of the direction it was initially started in.
The only reason why this is psychologically threathening is that because ICMP ping is usually not a real connection, it looks somewhat sneaky.
#10
25.7, 25.10 Series / Re: Wireguard & LAN-LAN SMB
Last post by chemlud - Today at 09:59:07 AMJust an idea: NAS only allowing access from LAN IPs?
