Topics

[Edit:]

Hi,

Gibt es einen Mechanismus auf der OPNsense der statische Routen (System: Routes: Configuration) aus der Routing-Tabelle (System: Routes: Status) löscht?

Konkret geht es um eine Route für einen Route-Based IPsec Tunnel - also zu dem Netz auf der anderen Seite.
Hierzu wurde auch ein Gateway bei "System: Gateways: Single" angelegt.

Das "automatische" Entfernen der Route scheint irgendwann zu erfolgen wenn der Tunnel nicht mehr steht.
Wieder angelegt wird diese Route aber anscheinend nur wenn man bei "System: Routes: Configuration" auf "Apply" klickt.

Grundsätzliche Infos:
- CARP Verbund (2x OPNsense 19.1.6 und 2x 19.7.4), tritt bei beiden Versionen auf
- VPN: IPsec: Tunnel Settings: "Disable MOBIKE", mit enabled und disabled probiert
- VPN: IPsec: Tunnel Settings: "Install Policy", natürlich disabled! ^^
- VPN: IPsec: Advanced Settings: "Do not install routes" enabled

Edit:
Das Deaktivieren von MOBIKE sorgt anscheinend doch dafür dass das "automatische" Entfernen der Route nicht mehr passiert! Ist das ein gewolltes Verhalten der MOBIKE-Funktion - Manuell eingetragene statische Routen zu entfernen?

Hi Leude,

gibt es eine Möglichkeit einen OpenVPN User an ein bestimmtes VLAN zu binden?
Auf der OPNsense kann ja ein OpenVPN User auch über RADIUS oder LDAP authentifiziert werden und
diese Protokolle unterstützen das Mapping prinzipiell. Oder gibt es eine grundsätzlich andere Lösung?

Would be nice to hear that it's basically working ;)
Please explain your setup (CARP IPv6 address or IPv6 Alias etc.)

Currently I have created firewall rules on several interface-tabs.
The firewall rules of some interface-tabs are basically the same.
I would like to summarize these interfaces in a group interface:

Code Select Expand


IPv4 ICMP   LAN1 Net    *     Other Net
IPv4 TCP    LAN1 Net    443   Other Net
...


"LAN1 Net" is the directly connected network on the interface-tab in the example.
"Other Net" is the same on all interfaces-tabs i want to group.

These rules effectively prevent spoofing the source IP.

In order not to maintain all rules on every interface I want to create them on a group interface only once.
A rule on the group interface would look like this:

Code Select Expand

IPv4 TCP    Group-Interface   443    Other Net

But now spoofing would be possible.
Packages with any source IP from "Group-Interface" networks could be sent from
any interface from "Group-Interface" to "Other Net".

It seems that anti-spoof rules are automatically created (on top in the rules list):

Code Select Expand

block drop in log on! xn4 inet from 10.10.0.0/24 to any

Would be the "quick" keyword in this rule enough to solve my problem?
Is there a fundamentally different solution for my problem.

Bei "System -> Settings -> Tunables" können syncookies enabled/disabled werden.
(net.inet.tcp.syncookies   Generate SYN cookies for outbound SYN-ACK packets)

Werden die Syncookies nur für TCP-Verbindungen generiert die direkt an die OPNsense addressiert sind?
Um die Syncookie-Funktion für Hosts hinter der OPNsense zu verwenden muss ich in einer FW-Regel entsprechend die synproxy-Funktion aktivieren?

Moin Leute,

mir sind einige Dinge im Zusammenhang mit CARP und dem HA-Verbund aufgefallen.
Vielleicht könnt ihr mich ja aufklären :)
Version ist 18.1.6

1. CARP/XMLRPC: Falsche Zuordnung der Interfaces auf Backup-Maschine bei XMLRPC synchronisierung
  Den virtuellen IPs vom Typ CARP werden bei der synchronisierung unter Umständen die
  falschen Interfaces zugeordnet.

  Anscheinend müssen die initialen Interfacenamen also z.B. LAN und OPT1
  den gleichen System-Interfaces (xn0) wie auf der Backup-Maschine zugeordnet sein.
  Der Zuordung bei "Interfaces -> Assignments" kann nicht vertraut werden.
  Somit muss bei "Interfaces -> Overview" die initiale Zuordnung auf beiden Maschinen übereinstimmen.
  Das ist irgendwie versteckt bzw. verwirrend, oder?

2. Welche Firewallregeln müssen für CARP/PFSYNC/XMLRPC erstellt werden?
  Anscheinend kommen CARP und PFSYNC ohne Regeln durch, XMLRPC (TCP 443) benötigt aber eine?

3. CARP Authentication wird nicht angewandt, trotz angabe von Password im GUI?
  (Wegen der gleichen IP Protokollnummer (112) werden CARP pakete von tcpdump als VRRPv2
  Pakete geparsed, das scheint aber trotzdem aussagekräftig zu funktionieren!?)
  Jedenfalls zeigt mir tcpdump "authtype none" an. Des Weiteren sehe ich kein Feld
  welches den SHA1-HMAC enthalten könnte.

4. Der Prio-Wert in den CARP Advertisements hat maximal den Wert 240 (mit tcpdump überprüft)
  Der Prio-Wert ist ja anscheinend direkt der Skew-Wert den man in der GUI einstellen kann.
  Die Backup-Maschine bekommt dann über XMLRPC den Skew-Wert vom Master + 100.
  Wenn auf dem Master ein Wert >=240 eingetragen wird bekommt die Backup-Maschine den Wert 254.
  Ab einem Wert >=240 auf dem eigentlichen Master wird die Backup-Maschine zum neuen Master:
  Der Zustand ist dann z.B.:
  Eigentlicher Master: 250
  neuer Master: 254
  (Der neue Master sendet aber weiterhin nur CARP Advertisements mit dem Wert 240)
  Obwohl der Skew-Wert auf dem eigentlichen Master noch niedriger ist, ist die Backup-Maschine
  neuer Master geworden? (advbase war immer 1)
 
  Die magische Zahl 240 sowie der Wechsel des Masters sind mir hier unverständlich.
  Kann mich jemand erleuchten? ;)

5. Die Option "Disable preempt" bei "System -> High Availibity -> Settings" befindet sich unter der Überschrift
  "State Synchronisation". So wie ich das sehe hat diese Option aber garnichts mit der State Synchronisation,
  also PFSYNC zu tun.

Moin Leute,

ich würde gerne alle neuen Pakete die aus dem Internet auf dem WAN Interface
ankommen loggen. Für die Pakete für die am WAN Interface kein Portforwarding konfiguriert ist
scheint das auch zu funktionieren.
Das Portforwarding zu Hosts im LAN sorgt dafür dass erst an dem entsprechenden
LAN Interface eine Lognachricht generiert wird. Diese kann ich dann aber nicht mehr generisch zuordnen.

Kann man nicht einfach alles "neue" eindeutig loggen was am WAN Interface ankommt?
Grundsätzlich würde ich dafür Netflow nehmen, aber das scheint nur Pakete zu beachten die am WAN Interface
durch die Firewall erlaubt sind.