"Recent posts
#81
General Discussion / Re: Managing the HA passive no...
Last post by viragomann - Today at 01:37:54 PMQuote from: Zugschlus on Today at 12:14:44 PMHow bad do you find the idea of NATting the Home Office addresses of the admins to the active nodes' internal address when accessing the passive node?This is the recommended way to workaround this issue.
#82
25.7, 25.10 Series / Re: Firewall: Log Files: Live ...
Last post by Kayakero - Today at 12:54:19 PMok, thanks. applied both.
wasted space seems the same but now I least I can resize, I'm happy with that.
wasted space seems the same but now I least I can resize, I'm happy with that.
#83
German - Deutsch / Re: Wireguard - Externe Verbin...
Last post by viragomann - Today at 12:45:23 PMQuote from: Cpt_Wonderful on Today at 12:28:16 PMWenn ich die Gruppenregeln entferne, funktioniert der Tunnel nicht mehr.Auch keine Verbindung vom Client ins Internet?
Quote from: Cpt_Wonderful on Today at 12:28:16 PMDie Letzte Regel hatte ich für den Handshake drin (IN) - Unnötig?Ich habe von Wireguard keine Ahnung. Ich denke aber nicht, dass eine solche Regel nötig ist. Die betrifft eigentlich Verbindungen innerhalb des Tunnels und sollte mit dem Aufbau nichts zu tun haben.
Quote from: Cpt_Wonderful on Today at 12:28:16 PMUnd was mach eich bzgl. des Problems dass die VPN Clients nicht das ProtonVPN als 'exit-node' nutzen?Die letzte Gruppen-Regel entfernen.
Okay, etwas detaillierter:
Wie geschrieben, musst du die Policy-Routing Regel auf ausgehende Verbindungen beschränken. Sonst erreicht der Client keine lokalen Ziel, was vermutlich auch erwünscht ist.
Für diesen Zweck ist es ratsam, einen Alias für RFC 1918 Netze (private Netzwerkbereiche ) anzulegen. Ich nenne ihn RFC1918 und füge
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
hinzu.
Diesen musst du dann in der Policy-Routing Regel als Ziel zusammen mit einem Haken bei "Invert" verwenden. Damit trifft diese Regel nur noch auch Ziel außerhalb der privaten Netze zu.
Du kannst zu Testen mal hinter dieser Regel eine Allow-any Regel stellen. Dann sollte eigentlich alles funktionieren.
#84
25.7, 25.10 Series / Re: Firewall: Log Files: Live ...
Last post by franco - Today at 12:31:47 PMEasy with the fatalism there.
# opnsense-patch https://github.com/opnsense/core/commit/c11efa62bda8a
You may also like
# opnsense-patch https://github.com/opnsense/core/commit/d698b4e5a
# opnsense-patch https://github.com/opnsense/core/commit/c11efa62bda8a
You may also like
# opnsense-patch https://github.com/opnsense/core/commit/d698b4e5a
#85
German - Deutsch / Re: Wireguard - Externe Verbin...
Last post by Cpt_Wonderful - Today at 12:28:16 PMDanke dir für die Ausführung. Wenn ich die Gruppenregeln entferne, funktioniert der Tunnel nicht mehr.
Die Letzte Regel hatte ich für den Handshake drin (IN) - Unnötig?
Und was mach eich bzgl. des Problems dass die VPN Clients nicht das ProtonVPN als 'exit-node' nutzen?
Die Letzte Regel hatte ich für den Handshake drin (IN) - Unnötig?
Und was mach eich bzgl. des Problems dass die VPN Clients nicht das ProtonVPN als 'exit-node' nutzen?
#86
25.7, 25.10 Series / Re: Firewall: Log Files: Live ...
Last post by Kayakero - Today at 12:27:19 PMI just updated today.
Live view is horrible now. Fixed columns, wasted space in some columns and text truncated in others like time for example without even be able to resize.
Live view is horrible now. Fixed columns, wasted space in some columns and text truncated in others like time for example without even be able to resize.
#87
General Discussion / Managing the HA passive node o...
Last post by Zugschlus - Today at 12:14:44 PMHi,
given an OPNsense HA installation in a datacenter that only protects servers. The administrators use OpenVPN to connect to the site that terminates on the OPNsense cluster as well¹. This works for the active node, but the passive node cannot be access since the passive node has OpenVPN running as well with the routes to the OpenVPN clients pointing into the (inactive) tunnel. Thus, there is no reverse route and communication cannot happen.
Is there a gold standard to solve this? How bad do you find the idea of NATting the Home Office addresses of the admins to the active nodes' internal address when accessing the passive node? Or is it just recommended to always use the management network?
Greetings
Marc
¹ there is out of band access and a dedicated management network that can be accessed through a different channel, but that's clumsy to access.
given an OPNsense HA installation in a datacenter that only protects servers. The administrators use OpenVPN to connect to the site that terminates on the OPNsense cluster as well¹. This works for the active node, but the passive node cannot be access since the passive node has OpenVPN running as well with the routes to the OpenVPN clients pointing into the (inactive) tunnel. Thus, there is no reverse route and communication cannot happen.
Is there a gold standard to solve this? How bad do you find the idea of NATting the Home Office addresses of the admins to the active nodes' internal address when accessing the passive node? Or is it just recommended to always use the management network?
Greetings
Marc
¹ there is out of band access and a dedicated management network that can be accessed through a different channel, but that's clumsy to access.
#88
25.7, 25.10 Series / Ntopng - high CPU utilization
Last post by GreenMatter - Today at 12:04:41 PMI would like to keep using ntopng as a general overview of data flow but it causes high CPU (N100) utilization when transfer speeds starts reaching 400 Mb/s (Opnsense runs as VM in Proxmox). It wasn't the case when I was using Zenarmor...
Is there a way to set ntopng to be less resource hungry?
Is there a way to set ntopng to be less resource hungry?
#89
Dutch - Nederlands / Probleem met DNS-resolutie op ...
Last post by sakbari - Today at 12:04:33 PMIk ondervind een probleem met OPNsense 25.7.8-amd64: DNS-resolutie werkt niet op bepaalde VLANs.
De clients kunnen wel pingen naar het internet.
Clients krijgen correct hun IP-adres en DNS-server toegewezen via ISC DHCPv4.
Een nmap-scan laat zien dat poort 53 open staat.
Ik heb drie VLANs aangemaakt: VLAN 50, 60 en 70. VLAN 50 werkt correct, maar VLAN 60 en 70 kunnen geen DNS-resolutie uitvoeren.
Unbound DNS is geconfigureerd en alle interfaces zijn actief.
Heeft iemand een idee wat er mis kan zijn met de DNS-resolutie op VLAN 60 en 70?
De clients kunnen wel pingen naar het internet.
Clients krijgen correct hun IP-adres en DNS-server toegewezen via ISC DHCPv4.
Een nmap-scan laat zien dat poort 53 open staat.
Ik heb drie VLANs aangemaakt: VLAN 50, 60 en 70. VLAN 50 werkt correct, maar VLAN 60 en 70 kunnen geen DNS-resolutie uitvoeren.
Unbound DNS is geconfigureerd en alle interfaces zijn actief.
Heeft iemand een idee wat er mis kan zijn met de DNS-resolutie op VLAN 60 en 70?
#90
German - Deutsch / Re: Wireguard - Externe Verbin...
Last post by viragomann - Today at 12:03:26 PMHallo,
Und die letzte da erlaubt jeglichen Traffic der Clients auf das Standardgateway, also WAN.
Du benötigst eigentlich überhaupt keine Regeln auf der Grupppe.
Aber es sollte auch reichen, einefach die letzte Regel zu entfernen. Alle anderen betreffen nur ausgehenden Traffic, wofür die auch immer sind.
Doch wenn die Wireguard Clients auch lokale Ziele erreichen können sollen, musst du noch die Policy-Routing Regel auf externe Ziel beschränken.
Quote from: Cpt_Wonderful on Today at 10:26:46 AMFW-Rules - Wireguard (Group) -> Anscheinend werden die rules aus der Gruppe angewendet?!Ja, Gruppen-Regeln haben Vorrang gegenüber Interface-Regeln.
Und die letzte da erlaubt jeglichen Traffic der Clients auf das Standardgateway, also WAN.
Du benötigst eigentlich überhaupt keine Regeln auf der Grupppe.
Aber es sollte auch reichen, einefach die letzte Regel zu entfernen. Alle anderen betreffen nur ausgehenden Traffic, wofür die auch immer sind.
Doch wenn die Wireguard Clients auch lokale Ziele erreichen können sollen, musst du noch die Policy-Routing Regel auf externe Ziel beschränken.
