Messages

@bartjsmit

That's also how I plan to do it.

How to solve it if the new machine has a different interface constellation? The VLANs on an interface of the old machine should then be placed on a specific interface of the new machine.

Do I have to make manual changes in the configuration file before importing?

In der "OPNsense2-openvpn.log" steht z. B. folgendes (fehlt in "OPNsense2-openvpn-PSK.log")

Code Select Expand

Nov  5 13:42:12 OPNsense2 openvpn[8916]: OPTIONS IMPORT: timers and/or timeouts modified
Nov  5 13:42:12 OPNsense2 openvpn[8916]: OPTIONS IMPORT: --ifconfig/up options modified
Nov  5 13:42:12 OPNsense2 openvpn[8916]: OPTIONS IMPORT: route-related options modified
Nov  5 13:42:12 OPNsense2 openvpn[8916]: OPTIONS IMPORT: peer-id set
Nov  5 13:42:12 OPNsense2 openvpn[8916]: OPTIONS IMPORT: adjusting link_mtu to 1625
Nov  5 13:42:12 OPNsense2 openvpn[8916]: OPTIONS IMPORT: data channel crypto options modified

Ich kann mir nicht vorstellen dass dieser Unterschied durch die "Server Mode" Einstellung hervorgerufen wird.
Falls dem so ist wären die Logdaten bei sonst gleichen Settings hilfreich denke ich.

In der PSK-Config ist z. B. der Haken bei "Topology" gesetzt, bei der anderen Config nicht!

[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?

ein Dauerping von einem Client in LAN A auf Client LAN B läuft ins Leere, aber firewall sagt:

ovpns1      Sep 22 18:52:42   192.168.0.6:61046   192.168.2.36:9630   tcp   let out anything from firewall host itself   



wo kann ich bei der Analyse weiter ansetzen?

Ich würde einfach mal den angenommenen Lauf der Pakete der Reihe nach überprüfen.
Die Firewall verlassen die Pakete ja laut Log. Danach sollten die Pakete ja am VPN Endpunkt ankommen.
Somit mal auf dem VPN Client am Interface lauschen und schauen was ankommt.

Code Select Expand

tcpdump -n -i <interface>
Kannst ja auch noch mit Filtern einschränken.
Wenn du eintreffende Pakete (z. B. ICMP Echo Requests) siehst aber keine Replies, am Interface welches die Pakete im nächsten Schritt verlassen sollten lauschen ...usw.
So kann man eingrenzen wo die Pakete geblockt werden bzw. eine Route fehlt etc.

Also gibt es keine Möglichkeit nur an "einer Stelle (auf einem Interface)" das Firewalling für User-VLAN und dem
entsprechenden VPN-User zu pflegen?

Zum Verständnis: Der User soll die gleichen Zugriffsberechtigungen auf Netzwerkebene haben egal ob er im Büro sitzt oder sich von außen übers VPN einwählt.

Das gibt OpenVPN aber nicht her. OpenVPN ist kein Router, der in mehreren Netzen gleichzeitig seinen Fuß hat. Du brauchst pro VLAN einen Server. Ansonsten müsstest du ja in OpenVPN konfigurieren welcher Nutzer in welches Netz kommt. Und das geht nicht.

@theq86
Ich glaube nicht dass es bei meinem Problem um Routing Funktionalitäten geht.
Wie gesagt, mit Client Specific Overrides kann ich ja den einzelnen OpenVPN-Usern eigene Netze zuweisen und so beim Routing und den Firewall-Regeln schon User spezifisch konfigurieren.

...Ist vielleicht doch der Weg über eine Bridge die Lösung?
Eine Bridge zwischen OpenVPN-Interface und allen User-VLAN-Interfaces.
Das jeweilige VPN-User-IP-Netz setzt man dann auf ein Subnetz innerhalb des IP-Netzes des User-VLAN.
Somit kann man die Regeln auf dem User-VLAN für OpenVPN-User und internen VLAN-User zusammen an einer Stelle pflegen.

Über Firewall-Regeln müsste man doch klar Regeln können welches VPN-User-IP-Netz in welches IP-Netz des entsprechenden User-VLANs darf um die Trennung zwischen den VLANs zu wahren die sonst wegen dem Bridging verloren ginge?
Oder sieht hier jemand Probleme?

@superwinni2
ich glaube aber langsam dürfte klar sein was meine eigentliche Frage ist ;)
Falls nicht: Ich will unterschiedliche OpenVPN-User die sich auf einem OpenVPN-Server einloggen in unterschiedliche VLANs mappen. Für jeden User einen eigenen VPN-Server zu konfigurieren ist keine Option da
dann unterschiedliche Server-Ports verwendet werden müssten und der Verwaltungsaufwand zu groß wäre.

@hmarius1
Mit Client Specific Overrides kann ich je OpenVPN-User spezifische Transfernetze etc. vergeben.
Die Firewall-Regeln die auf meinen schon bestehenden User-VLANs liegen müsste ich dann aber auf das OpenVPN Interface kopieren und an zwei Stellen pflegen.
Daher die Idee die OpenVPN-User einfach in ihr entsprechendes VLAN zu mappen.
Aber wie schon gesagt, vielleicht gibt es auch eine grundsätzlich andere Lösung für mein Problem.

Und wie bekomme ich die einzelnen VPN User in ihr spezifisches VLAN?
Du beschreibst nur wie man alle VPN User auf einem OpenVPN-Server in ein gemeinsames VLAN packt, oder?

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?

Do you have a rule on the LAN interface to allow SNMP traffic?
In the next step check if the SNMP query is received by the firewall like FraLem was mentioning.
Then we can look further.

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

1. I think for the sshlockout table only failed SSH logins get counted. Thus you should check your script.

2. The sshlockout rule is evaluated before the anti-lockout rule, thus the anti-lockout rule has no effect here.

I don't think there's an switch to disable the sshlockout function.
Anyway you can remove IPs from the sshlockout table -> Firewall: Diagnostics: pfTables

Bei mir wurde der PfTables-Eintrag zu einem Alias erst angelegt nachdem ich auf "Apply" (Firewall: Aliases -> Apply) geklickt habe. Hast du das vielleicht vergessen?
(Nach dem Verwenden des Alias in einer Filter-Regel wurde der PfTables-Eintrag auch angelegt)

To create the pfTable entries you have to press the apply button.
(Firewall: Aliases -> Apply)