Messages

Hello,

I've configured "Services -> DHCPv4 -> [Interface] -> NTP servers" with one IP.

A packet analysis with Wireshark shows that OPNsense DHCPv4 do not send out this NTP-server, option 42 is missing in DHCP-packet. Why is that?

Udo

Hallo zusammen,

wir nutzen OPNsense + Suricata an mehreren Standorten und möchten die am Hauptstandort gemachten Suricata-Regeleinstellungen auf alle weiteren Standorte automatisiert übertragen (z.B. via SSH).

(konkret die Konfiguration "Services" -> "Intrusion Detection" -> "Policy" -> "Rule adjustments" im Webinterface)

In /usr/local/etc/suricata/rules.config stehen exakt diese Informationen, es genügt allerdings nicht, diese Datei einfach auf die anderen FWs via SSH zu übertragen. Im Webinterface (o.g. Pfad) wird auch nach einem Suricata-Dienstneustart die Konfiguration aus der eingefügten rules.config nicht angezeigt.

Muss die rules.config noch über einen Suricata-Befehl manuell eingelesen werden?

Viele Grüße

Udo

Hi Franco,

Wie dem auch sei: die Mailing Liste ist wegen angreifbaren Spam-Lücken (die leider auch aktiv ausgenutzt wurden) seit 2021 nicht mehr aktiv.

schade, die announce Mailingliste war immer sehr hilfreich zur Ankündigung des neuen Release inkl. Changelog. :(

Vielleicht lassen sich die Spam-Lücken schließen (moderierte Liste, nur Freigabe Deiner Posts?) und announce reaktivieren? Bin mir sicher, dass viele Abonneten der Liste Deine Ankündigungen vermissen.

Viele Grüße

Udo

Mit "ifconfig-push 192.168.X.X 255.255.255.0;" unter "VPN: OpenVPN: Client Specific Overrides" kann ich sicherstellen, dass der entsprechende VPN-Account, für den es konfiguriert ist, immer die gleiche IP-Adresse zugewiesen bekommt.

Erfolgt eine VPN-Einwahl mit dem Account (Homeoffice-Nutzer), erhält dieser immer die mit "ifconfig-push" konfigurierte IP für seinen Endpunkt. Auf dieser IP basierend kann ich dann die Firewallregeln erstellen, z.B. welche IPs, Netze und Dienste der VPN-Nutzer über die OPNsense erreichen darf (u.a. auch ein Zulassen nur auf seinen Dienstrechner (RDP) in der Firma, statt dem gesamten Netz).

Diese Konfiguration wird mehrfach im Netz genannt und ist bei mir bereits ein Jahr erfolgreich im Einsatz.

Angenommen die "Advanced Options" werden irgendwann doch mal aus dem GUI entfernt (wie bereits im Hinweistext des Feldes angekündigt), welche alternative Möglichkeit gibt es, die o.g. Konfiguration über das GUI einzustellen?

Viele Grüße

Udo

@franco:

Vielen Dank für Deine hilfreiche Antwort!

Ich war mir unsicher, ob mit dem Changelog-Eintrag nicht die "Advanced Options" gemeint sind, zumal ja bereits der Hinweis dort steht, dass diese in Zukunft entfernt werden. Falls die mal entfernt werden, bitte im Changelog zum Release erwähnen.

War übrigens erstaunt, dass ich diesmal via announce@lists.opnsense.org noch keine Ankündigung zum Release erhalten habe (weder auf meiner dienstlichen, noch auf meiner privaten Mailadresse), sondern nur via heise.de heute davon erfuhr. ;)

Viele Grüße

Udo

@JeGr:

Mit "ifconfig-push 192.168.X.X 255.255.255.0;" unter "VPN: OpenVPN: Client Specific Overrides" kann ich sicherstellen, dass der entsprechende VPN-Account, für den es konfiguriert ist, immer die gleiche IP-Adresse zugewiesen bekommt.

Erfolgt eine VPN-Einwahl mit dem Account (Homeoffice-Nutzer), erhält dieser immer die mit "ifconfig-push" konfigurierte IP für seinen Endpunkt. Auf dieser IP basierend kann ich dann die Firewallregeln erstellen, z.B. welche IPs, Netze und Dienste der VPN-Nutzer über die OPNsense erreichen darf (u.a. auch ein Zulassen nur auf seinen Dienstrechner (RDP) in der Firma, statt dem gesamten Netz).

Viele Grüße

Udo

Hallo zusammen,

im Changelog zu OPNsense 21.1 steht:

openvpn: hide "openvpn_add_dhcpopts" fields when not parsed via the backend

Was bedeutet das konkret?

Ich nutze derzeit:

VPN: OpenVPN: Client Specific Overrides

Advanced
ifconfig-push 192.168.X.X 255.255.255.0;

(This option will be removed in the future due to being insecure by nature. In the mean time only full administrators are allowed to change this setting.)

Ist diese Funktionalität in OPNsense 21.1 nicht mehr möglich?

Falls ja, wie realisiere ich alternativ, dass den VPN-Clients eine eindeutige/feste IP-Adresse zugewiesen wird?

Ich habe pro VPN-Client individuelle Firewall-Regeln konfiguriert und benötige daher eine eindeutige Zuordnung der IP-Adresse.

Viele Grüße

Udo

Hallo,

ich nutze auch unter "VPN" -> "OpenVPN" -> "Client Specific Overrides" -> "Advanced" die Option "ifconfig-push 192.168.XXX.XXX 255.255.255.0;", um den VPN-Usern eine eindeutige IP-Adresse zuzuweisen.

Wie kann das zukünftig realisiert werden, wenn die "Advanced"-Option wegfällt?

"This option will be removed in the future due to being insecure by nature. In the mean time only full administrators are allowed to change this setting."

Ist bereits bekannt, wann konkret diese Option wegfällt?

Viele Grüße

Udo

OPNsense 20.1.3-amd64
FreeBSD 11.2-RELEASE-p17-HBSD
OpenSSL 1.1.1d 10 Sep 2019

Hallo zusammen,

ich habe ein OPNsense HA-Cluster mit Multi WAN-Setup (u.a. eine GW-Group mit 4x Tier1), wo es immer mal wieder vorkommt, dass ein Gateway (nicht immer das gleiche GW) für einen längeren Zeitraum ungenutzt bleibt. (siehe Screenshots im Anhang)

Gateway Log für den Zeitraum:

2020-03-31T20:29:14   dpinger: GATEWAY ALARM: SK_PTP_GWv4 (Addr: 1.1.1.1 Alarm: 0 RTT: 18555ms RTTd: 15416ms Loss: 16%)
2020-03-31T20:29:14   dpinger: SK_PTP_GWv4 1.1.1.1: Clear latency 18555us stddev 15416us loss 16%
2020-03-31T20:29:02   dpinger: GATEWAY ALARM: SK_PTP_GWv4 (Addr: 1.1.1.1 Alarm: 1 RTT: 20255ms RTTd: 15715ms Loss: 22%)
2020-03-31T20:29:02   dpinger: SK_PTP_GWv4 1.1.1.1: Alarm latency 20255us stddev 15715us loss 22%

General Log:

2020-03-31T20:30:55   monit[43991]: 'gateway_alert' status failed (1) -- MONITOR: SK_PTP_GWv4 has packet loss, removing from routing group WANGWGROUP MONITOR: SK_PTP_GWv4 has packet loss, removing from routing group WANGWGROUP_SK
2020-03-31T20:29:02   opnsense: /usr/local/etc/rc.filter_configure: Ignore down inet6 gateways : SK_PTP_GWv4
2020-03-31T20:29:02   opnsense: /usr/local/etc/rc.filter_configure: Ignore down inet gateways : SK_PTP_GWv4

Das Gateway SK_PTP_GWv4 hat aktuell im Webinterface den Status "Online" und auf allen anderen drei Interfaces/GWs ist ganz normal Traffic.

Was könnte die Ursache dafür sein? Wie kann ich das Problem weiter analysieren?

Manchmal behebt sich das Problem scheinbar von allein, d.h. das GW wird z.B. nach 1-2 Tagen wieder genutzt, es sollte aber eine dauerhafte Lastverteilung auf alle GWs (4x Tier1) stattfinden.

Heute ab 16:30 Uhr gings auf einmal wieder, ich hatte zuvor neue VPN-Zugänge eingerichtet, Firewallregeln angepasst und abschließend unter "System: High Availability: Status" alle Dienste neugestartet. Im Log kann ich aber bezüglich des betroffenen GWs zu der Zeit keine Meldung entdecken.

Auch nach einem Neustart des HA-Clusterknoten, werden erstmal wieder alle GWs korrekt genutzt, nur das kann ja nicht die Lösung sein... ;)

Viele Grüße

Udo

Hallo zusammen,

ich möchte gern OPNsense an mehreren Außenstandorten einsetzen und bin
auf der Suche nach einer zentralen Verwaltungslösung. Im Forum stieß ich auf
OPNcentral. Gibt es noch weitere Lösungen für die zentrale Verwaltung mehrerer
OPNsense?

Welche Möglichkeiten bietet OPNcentral?
Bis jetzt habe ich dazu leider keine genauen Informationen gefunden.

Ich suche eine Möglichkeit für folgende Funktionen:

zentrale Verwaltung...

- der Firewall-Aliase
- der Firewall-Regeln (gleiche Interfaces auf den Geräten vorausgesetzt)
- der IDS/IPS-Regeln (Suricata)
- der Updates
- der Backups

Quasi ein Webinterface, wo alle betreffenden Geräte markiert werden können und
eine der o.g. Aktionen dann für die ausgewählten Geräte durchgeführt wird.

Viele Grüße

Udo

Hallo zusammen,

ich habe auf zwei Servern OPNsense 19.7 installiert und die neusten
Updates eingespielt. Auf beiden Servern (identische HW) wurden in
der gleichen Reihenfolge die Interfaces angelegt und identisch
zugeordnet (gleiche Benennung). Zudem habe ich ein HA-Cluster (CARP)
inkl. der VIPs konfiguriert.

FW1:
PFSYNC = 192.168.1.1/24
LAN (VLAN) = 192.168.150.1/24 (VIP 192.168.150.3/24)
WAN1 = 37.X.114.66/28 (VIP 37.X.114.68/28)
WAN2 = 37.X.116.66/28 (VIP 37.X.116.68/28)

FW2:
PFSYNC = 192.168.1.2/24
LAN (VLAN) = 192.168.150.2/24 (VIP 192.168.150.3/24)
WAN1 = 37.X.114.67/28 (VIP 37.X.114.68/28)
WAN2 = 37.X.116.67/28 (VIP 37.X.116.68/28)

Firewall -> NAT -> Outbound -> "Manual outbound NAT rule generation"
1. WAN1; (Source: LAN net); (Translation / target: 37.X.114.68/28)
2. WAN2; (Source: LAN net); (Translation / target: 37.X.116.68/28)

Die beiden Gateways der zwei WAN-Verbindungen habe ich als WANGWGROUP
zusammengefasst (MultiWAN). Dabei sind beide GWs als Tier1 (Loadbalance)
konfiguriert und haben ansonsten auch die gleichen Prioritäten.

Firewall -> Settings -> Advanced
- Sticky Connections ist aktiviert
- Shared forwarding ist aktiviert

In der Firewall ist in der LAN-Rule (Default-Rule) als Gateway die
WANGWGROUP zugewiesen.

Der HA-Cluster funktioniert einwandfrei, wie die Tests zeigten.

Ich sah nun im packet capture auf WAN1 und WAN2, dass sehr häufig die
VIP des anderen WAN-Interfaces für Pakete (LAN -> WAN*) genutzt wird,
worauf dann natürlich keine Antwortpakete kommen!
Manchmal wird aber auch die korrekte Absenderadresse verwendet.

Ich ging eigentlich davon aus, dass durch die o.g. NAT-Outbound Rules
die abgehende Source-IP klar definiert ist.

Mein Verdacht war, dass es am HA-Setup liegt, daher habe ich HA für
die WAN-Interfaces deaktiviert und die VIPs gelöscht.

Firewall -> NAT -> Outbound -> "Automatic outbound NAT rule generation"

Ich habe nun erwartet, dass jetzt nur noch die dem WAN-Interface zugeordnete
IP-Adresse als Absenderadresse verwendet wird.

Der Fehler trat weiterhin auf und packet capture zeigte, dass nun
sehr häufig statt zuvor der VIP, die IP des anderen WAN-Interfaces für
(LAN -> WAN*) als Absenderadresse verwendet wird. Hierauf können
natürlich auch keine Antworten kommen, da es eine andere Leitung mit
einem eigenen Subnetz ist. Es wird aber manchmal auch die korrekte
Absenderadresse verwendet.

Eine Internetrecherche brachte mich zu folgendem Beitrag:

https://github.com/opnsense/core/issues/2376

Daraufhin habe ich unter Firewall -> Settings -> Advanced

- Shared forwarding deaktiviert

Das Problem ist damit deutlich besser und wesentlich seltener geworden!
Allerdings ist es nicht 100% gelöst, da ich es anschließend trotzdem noch
ein paar Mal bemerkte und auch in dem Zusammenhang im packet capture
wieder sah.

Erst eine Deaktivierung von "Sticky connections" (hier kann dann anscheinend
"Shared forwarding" problemlos aktiviert sein) scheint derzeit eine
100 prozentige Lösung für das Problem zu sein! In der Konstellation konnte
ich das Problem bis jetzt nicht mehr reproduzieren.

Ich möchte aber sehr gern "Sticky connections" nutzen, da einige Webseiten und
Onlineshops dies benötigen. Daher ist die o.g. Konstellation für mich auch
keine wirkliche Lösung.

Habt Ihr eine Idee, was die Ursache für diese Problematik ist?

Warum nutzt OPNsense nicht einfach die manuellen Outbound-NAT rules?

Viele Grüße

Udo