Messages

[0]

@W0nderW0lf

Muss das Subnetz nicht z.B. 192.168.1.0/24, 192.168.99.0/24 lauten?

Vielen Dank!

Hallo Forum!

Zunächst möchte mich wieder einmal für die grandiose Arbeit der Entwickler bedanken! Der Umstieg auf OPNsense 26.1.1 gelang problemlos, wie auch die Umstellung auf die neuen Regeln.
Auch beim Forum möchte ich mich für die vielen interessanten und lehrreichen Beiträge bedanken.

Ich nutze Crowdsec, q-feeds und suricata (netmap, Überwachung auf den LAN Schnittstellen) und bin mir nicht sicher, ob all diese Tools sich sinnvoll ergänzen oder, ob es im Bestreben eine höhere Sicherheit in meinem Netzwerk zu gewährleisten z.B. durch Überschneidungen zu nachteiligen Effekten führen kann. Vielleicht macht es ein Tool überflüssig.
Jetzt mit OPNsense Version 26.1.1 gibt es noch die Möglichkeit suricata auf ,,divert-to" umzustellen. Macht das Sinn, wenn netmap stabil läuft auch in Hinblick auf die Zukunft?
Wo sollte eine entsprechende Regel sinnvollerweise platziert werden, welche Schnittstelle, vor q-feeds oder danach?

Somehow I had a hunch that this "one interface only" switch in the new rules scheme would cause problems., because it mixes up the priorities.

I created a group with only wan or whatever (that worked). I assigned this group a sequence that took precedence over all other groups, so that it was applied before all other group rules.

What do you mean by that second question? I do not quite understand.

What I meant was that if I allow everything except my "restricted group net", I don't need to specify separate IPv4 and IPv6 interfaces in an alias. My problem is that I don't have a static IPv6 address from Telekom, even though it admittedly changes very rarely.

These are the rules for the "Restricted" group:

Thank you for sharing.
May I ask what the aliases for the local network IPv4 and IPv6 actually look like?

You cannot view this attachment.

In your opinion, you could also use the interface group restricted itself, something like this
source: restricted net
destination: restricted net ?

So wie ich das verstanden habe hast du vorher im LAN einen "echten" Konnektor gehabt und nun auf einen HK (Highspeedkonnektor) per VPN gewechselt.

Nach Auslaufen der Zertifikatsgültigkeit der Einbox- Konnektoren, was von Konnektor zu Konnektor unterschiedlich ist, erfolgt eine Neuanbindung an die TI derzeit nur noch per TI Gateway per VPN.

Dann drängt sich mir als erstes auf, hast du die "alten" routen auf den jeweiligen Geräten Mac´s gelöscht ?
und dann die neuen gesetzt?

Die Routen sind spätestestens zum Zeitpunkt der Umstellung auf den Clients zu löschen und entsprechende Routen in der Firewall zu setzen.
Auch wenn Du nicht Tomedo nutzt, stellt Zollsoft eine Liste zur Verfügung:
https://support.tomedo.de/handbuch/tomedo/telematikinfrastruktur-ti/ports-und-routen-fuer-die-ti/

sind die Ports entsprechend angelegt worden? siehe PDF

Auch wenn ich den Link nicht öffne, nehme ich an, dass dort eine Aufstellung zu finden ist, welche ausgehenden Ports freigegeben sein sollen. Da es sich bei der OPNsense um eine statefull Firewall handelt, müssen keine ausgehenden Ports definiert werden. Antwortpakete von aussen werden zugelassen, wenn sie zu dem gesetzten "state" passen.
Die jedoch zu definierende NAT Regel ist eine outbond Regel zur Maskierung auf eine dem TI-Konnektor bekannte IP (lokale Tunnel IP, die in der Konfiguration vorgegeben ist).

P.s. IPsec Ports müssen auf der WAN Schnittstelle natürlich erlaubt sein als Grundvoraussetzung damit IPsec überhaupt funktionieren kann.

Muss ich das OS dann zurück setzen?

Nein, nutze selber 25.7.10.

Hast du bei der Child Konfigurationen den Punkt Richtlinien deaktiviert? (siehe screenshot)

@RES217AIII Kannst du mir die Dokumentation zukommen lassen oder ist die irgendwo einsehbar?

https://support.tomedo.de/handbuch/tomedo/telematikinfrastruktur-ti/ti-gateway/
Am Ende wird beschrieben wie man die Konfiguration testen kann, was wie gesagt ohne SMC B nicht funktionierte.

Ausserdem empfehle ich die Anleitung im Forum Tomedo, die funktioniert (inclusive des Kommentars am Ende)
https://forum.tomedo.de/index.php/109174/anleitung-ipsec-vpn-tunnel-an-opnsense-fur-ti-gateway-edit-infos-fur-homeoffice-uber-vpn
Ich habe auf der Basis eine PDF mit den einzelnen Konfigurationsschritten erstellt, die ich Dir gerne zu Verfügung stellen kann.

Hast Du weitere IPsec Verbindungen konfiguriert?
Es kann an der NAT Konfiguration liegen.

Guten Morgen,
meiner Erfahrung konnte ich erst KIM+ und KVsafenet nach Integration und Aktivierung der SMC B erreichen, anders als in der Dokumentation meines Serviceanbieters (Tomedo von Zollsoft) angegeben. Was mich nebenbei in den Wahnsinn getrieben hat, als ich vor dem geplanten Installationstermin durch Zollsoft soweit alles vorbereiten wollte.
Einstellung "skip firewall rules" wie auf dem screenshot anbei.

Hallo liebes Forum,
falls jemand eine Anleitung sucht zur Konfiguration von OPNsense zur Nutzung des TI Gateways so möchte ich hier einen Link zur Verfügung stellen, falls noch nicht gefunden:

https://forum.tomedo.de/index.php/109174/anleitung-ipsec-vpn-tunnel-an-opnsense-fur-ti-gateway-edit-infos-fur-homeoffice-uber-vpn?show=110744#a110744

Die Anleitung stammt nicht von mir, sondern von Herrn Mai, bei dem ich mich auch hier nochmals bedanken möchte.

Für Anregungen zur Verbesserung und Lösung mancher Problemstellungen würde ich mich freuen.

B. Unkel

In Unbound (Port 53530) wurde eine Weiterleitung definiert für Telematik auf die Adresse des HSK Konnektors (nicht TunnelIP!!).

Bin nicht sicher ob das dein Problem ist, aber der Konnektor beantwortet grundsätzlich keine (DNS-) Anfragen seines Standard-Gateways.

Bin nicht sicher ob das dein Problem ist, aber der Konnektor beantwortet grundsätzlich keine (DNS-) Anfragen seines Standard-Gateways.

Ich denke, Du hast Recht!!!!!

Habe unbound nur auf LAN hören lassen, was aber keine Verbesserung des Verhaltens brachte.

Wieder auf alle hören lassen, brachte bei "sockstat -4 -P tcp | grep unbound" als Ergebnis, dass die WAN Adresse genutzt wurde und nicht der IPsec Tunnel.

Mit Rumprobieren kam ich zu folgenden Ergebnis:
Auch wenn in den Konfigurationanforderung eine Weiterleitung der Domain .telematik auf die IP des TI Konnektors gefordert ist, führt die Deaktivierung dieser Weiterleitung zu dem gewünschten Ergebnis. Ich erreiche kim.telematik.
Warum das so funktioniert und nicht wie gefordert, verstehe ich nicht (was nichts heisst, weil ich doch noch sehr ahnungslos bin, wie ich immer wieder feststelle)

Weil vielleicht gar nicht der Rebind Schutz das Problem ist? Schau mal in die DNS logs oder erhöhe den Log Output von Unbound um zu sehen WAS das Problem ist und gehe nicht einfach davon aus, dass es der Rebind Schutz sein muss. Das wäre ja nur dann aktiv, wenn man sowohl eine Antwort mit public IP als auch eine mit privater/geschützter bekommt und nicht einfach NUR wenn es ne interne IP wäre. Sonst würde bspw. Unbound ja auch zur Firewall IP selbst null Auskunft geben.

Ich würde raten, dass es ggf. eher daran liegt, dass Unbound kein sauberes Bein hat mit dem er zum Telematik Kram telefonieren soll. Du könntest daher mal als "Workaround" in den unbound Einstellungen das "ausgehende Interface" auf LAN stellen. Klingt kontraproduktiv, aber das zwingt Unbound eigentlich, als abgehende Adresse ne interne IP zu nutzen, die ggf. in deinem IPsec Tunnel erfasst ist und geroutet wird anstatt sich auf das VTI Netz zu binden und ggf. das dafür zu nutzen. Klappt meistens bei reinen Phase2 IPsecs sehr gut um das zu umgehen. Evtl. genügt das schon.

Vielen Dank.
Werde ich versuchen. Muss ich allerdings in einer ruhigen Minute machen um den Betrieb nicht zu sehr zu stören.

Hö? Was tut das? Alles was nicht lokale Netze sind verbieten? Das wäre dann ja "fast" Internet, das macht ja keinen Sinn, wenn man danach wieder Internet erlauben will und es vorher aber verboten hat? Was soll das invertieren?

Zudem: Alles was auf LAN Seite geblockt wird würde ich SEHR empfehlen mit "Reject" zu machen, nicht mit Block, damit eine sofortige Ablehnung kommt und keine Minute oder zwei auf nen Timeout gewartet werden muss. Das verzögert Clients massiv, wenn die gegen sowas laufen.

Und: Source Any würde ich auf internen Netzen nie machen, sondern immer das entsprechende Subnet auf dem ich bin. Also in dem Fall "LAN subnet".

Ich bin immer sehr dankbar für Verbesserungsvorschläge. Unten habe ich ein Bild von meinen Regeln auf dem LAN Netzwerk gemacht. Was kann ich besser machen?