Messages

ich mach immer einen traceroute über das Gateway auf z.B. 1.1.1.1 und suche mir dann so den 2-4 Hop raus der vom Namen her auf etwas wie FRA/AMS etc. etwas über Peer schließen lässt. Dann kann es zwar immer noch sein das z.B. die Verbindung nur bis dorthin geht und dahinter eine Verbindung ins Internet nicht möglich ist und ich dadurch Störungen habe. Das kann ich aber auch anders herum haben wenn ich z.B. 1.1.1.1 als Monitoring setze und es Probleme bei deinem Provider zu cloudflare DNS gibt, der Rest des Internets aber geht. Ist dann auch ärgerlich, da bei Multi-WAN das Interface dann down geht obwohl fast alles geht und du auf eine evtl. langsamere Backup Leitung wechselst.

gleiches Setup hier, hab ich auch lange mit Probleme gehabt.
War aber ein Problem auf Layer 8.
Bei den CARP VIPs ist es wichtig das auch die richtige CIDR eingetragen ist, also nicht aus versehen /32.
Mit /32 geht so ziemlich alles andere auch ohne Probleme nur halt das DHCP nicht.
Unter Security im Distributed switch promisc, mac change, forge transmit erlauben.

Aber das entscheidende war die CIDR Range, die genauso wie beim Interface sein muss.
Wenn pfsync configuriert ist

wenn man per cron firmware check ausführt, wird unter /tmp/pkg_upgrade.json im dict upgrade_packages das package opnsense mit version und new_version geführt.
Über changelog mit firmware changelog über cron laden kann man unter /usr/local/opnsense/changelog/index.json den letzten eintrag aus der Liste auch die version auslesen.

Habe das für den checkmk Agenten so umgesetzt.
https://github.com/bashclub/check-opnsense/blob/main/opnsense_checkmk_agent.py#L226

bei der Changelog Variante die ein wenig sauberer erscheint ist aber leider kein Support für Hotfixes mit _X Version

Das würde ich auch so sehen. Du kannst das zwar über ein Bridge Interface machen und die User über Switch 802.1X oder Manuell zuordnen.
Siehe hier https://forum.opnsense.org/index.php?topic=5965.0

aber mach es nicht. Ist es nicht Wert. Du machst dir bei jedem Update in die Hose ob du mit ner Sonderlocke wieder durchkommst.

some news and screenshots https://forum.opnsense.org/index.php?topic=26594.0

noch ein Screenshot

Wir haben einen Standalone checkmk_agent gebaut, der nicht auf (x)inetd oder ähnliche angewiesen ist.
Es ist ein Python Daemon der neben den default FreeBSD dingen wie CPU/RAM/Disk etc auch noch folgendes mitbringt.
ACME Zertifikate (Alter/Last Update,letzter Status und Expire)
DHCP Pools: (leider aufgesetzt auf die default dhcp pools, die visuell nicht so schön sind)
Firmware: Alter und verfübarkeit (changelog muss über cron aktualisiert werden)
Gateways: rtt/rtts/loss
HAProxy: Frontends/Backends
Interfaces: mit opnsense Namen
IPSec Tunnel: (nur mit Tunneln getestet kein Roadwarrior im Einsatz)
OpenVPN: (je Server und bei Bedarf mittels Client Override auch je Client) incl. Traffic
Unbound:
Wireguard: je Endpoint

https://github.com/bashclub/check-opnsense (enthält noch nicht alle Plugins)
oder
bleeding Edge: https://nc.cloudistboese.de/index.php/s/8LmMSbXgDJMjCZr

derzeit startet das ganze über die syshook Funktionalität und noch nicht über ein Plugin

Moin,

also ich mag per default deny auch gerne. Aber warum machst du dir das leben so schwer. Gerade in einem privaten Netz.

Ich hab das bei mir folgendermaßen.
Alias: P_HIGHPORTS: 1024:65535
Alias: P_SAFE_PORTS: 21,22,43,80,110,119,143,443,465,554,563,587,993,995,P_HIGHPORTS

in Safeports sind alle in den priv Ports definierten Anwendungen die ich erlaube, bei HIGHPORTS eigentlich uninteressant es sei denn du willst explizit was wegfiltern.

Alias: N_DONTROUTE: 0.0.0.0/8,10.0.0.0/8,100.64.0.0/10,127.0.0.0/8,169.254.0.0/16,172.16.0.0/12,192.0.0.0/24,192.0.2.0/24,192.168.0.0/16,198.18.0.0/15,198.51.100.0/24,203.0.113.0/24,224.0.0.0/4,240.0.0.0/4,255.255.255.255/32,::/128,::1/128,::ffff:0:0/96,::/96,100::/64,2001:10::/28,2001:db8::/32,fc00::/7,fe80::/10,fec0::/10,ff00::/8


Jetzt legst du ne Firewallregel für LAN an
Quelle: LAN_NETZWERK
Ziel: N_DONTROUTE (Ziel invert

• )
  Zielports: P_SAFEPORTS
  
  Damit hast du z.B. sowas wie CIFS/SMB verboten aber alles andere geht raus wenn es denn außerhalb privater IP Adressen ist.
  DNS Musst du evtl. noch beachten, das ist da jetzt nicht drin, ebenso wie NTP.
  Beides ist bei mir auf der Sense nur lokal erlaubt und daher eine zusätzliche regel die das mit Ziel THIS_FIREWALL erlaubt.
  

Das Script ist derzeit auf --start parameter dauer eingestellt, damit es über den syshook Ordner einfach mitstartet.

Es sind aber eigentlich alle Funktionen die AFAIK für einen Dienst unter OPNsense benötigt werden vorhanden --start,--stop,--status, daher sollte eine Migration zu einem Plugin leicht möglich sein. CC @mimugmail wenn du vielleicht Lust zu helfen hättest.

we created a small python daemon implements a checkmk_agent

https://github.com/bashclub/check-opnsense

no additional package requirements

Installation

Code Select Expand

fetch -o /usr/local/etc/rc.syshook.d/start/99-checkmk_agent https://github.com/bashclub/check-opnsense/raw/main/opnsense_checkmk_agent.py
chmod +x /usr/local/etc/rc.syshook.d/start/99-checkmk_agent
/usr/local/etc/rc.syshook.d/start/99-checkmk_agent


current state is near to beta

current features

age of current Firmware/new Version available
Interfaces with opnsense names
Gateways
OpenVPN Server/Client
OpenVPN per client (can be configured through Client Specific Overrides only add an empty entry name common name from cert or username/ the description field can be used to change the service name)

Moin,

falls da noch jemand Interesse hat. Wir haben da so ein bisschen was gebaut.

https://github.com/bashclub/check-opnsense

Hat keine Abhängigkeiten.
Installation

Code Select Expand

fetch -o /usr/local/etc/rc.syshook.d/start/99-checkmk_agent https://github.com/bashclub/check-opnsense/raw/main/opnsense_checkmk_agent.py
chmod +x /usr/local/etc/rc.syshook.d/start/99-checkmk_agent
/usr/local/etc/rc.syshook.d/start/99-checkmk_agent


Status so fast Beta.

Derzeit implementiert

Firmware alter aktuelle Version/neue Version verfübar
Interfaces (mit Namen aus Description)
Gateways
OpenVPN Server/Client
OpenVPN je Client (kann über Client Specific Overrides konfiguriert werden ... nur common name des Zertifikats oder Username angeben / Description kann benutzt werden um den Servicenamen zu ändern)

ok quick fix
edit
uncomment the leap line in /usr/local/etc/raddb/mods-enabled/eap

Code Select Expand


       #leap {
        #}



same here

Date
Process
Line
2021-06-17T08:00:58       Error: /usr/local/etc/raddb/mods-enabled/eap[15]: Instantiation failed for module "eap"   
2021-06-17T08:00:58       Error: rlm_eap (EAP): Failed to link rlm_eap_leap: Cannot open "/usr/local/lib/freeradius-3*/rlm_eap_leap.so"   
2021-06-17T08:00:58       Info: Debugger not attached

Hi,

if you choose localhost on both machines then changes of the interfaces (or HA Failover) do not interupt the openvpn daemon. Portforward on both machines from VIP Interface:1194 to 127.0.0.1:1194

Use localhost as Interface on OpenVPN Server and User Portforwarding on WAN (carp) to 127.0.0.1