Messages

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).

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?

Hallo Forum,
ich hoffe und freue mich auf eure Unterstützung.

Folgende Situation: Die LAN Schnittstelle mit der IP Adresse 192.168.115.0/24 hat eine Regel:

Erlaube
in
Quelle: any
Port: any
Ziel LAN Adresse
Port: 53 (DNS)

dann eine Regel:

Block
in
Quelle: any
Port: any
Ziel: any
Port: 53 (DNS).

Natürlich gibt es eine Regel:

Block
in
Quelle: any
Port: any
Ziel  invertiert RFC1918
Port: any

und eine Regel die Internet erlaubt:

Erlaube
in
Quelle: any
Port: any
Ziel any
Port: any.

Es wurde eine IPsec Verbindung (VTI) mit dem HSK der TI konfiguriert. Es wurde nach einem Gateway (Remote IP), Routen zu dem Gateway, eine NAT Outbond Regel zum NAT Masquierung auf die Lokale IP erstellt:

Erlaube
in
Quelle: any
Port: any
Ziel TI Netzwerk
Schnittstelle: Lokale IP
Port: any.

Auf IPsec (in der IPsec Tunnelkonfiguration wurde "Überspringe Firewall Regel") wurde eine any to any Regel erstellt:

Quelle: any
Port: any
Ziel any
Port: any.

Erst damit funktionierte die NAT Regel.

Die Auflösung der DNS erfolgt über die Kette Client > AdguardHome (53) > unbound (53530) > DNS über TLS (quad 9)
In Unbound (Port 53530) wurde eine Weiterleitung definiert für Telematik auf die Adresse des HSK Konnektors (nicht TunnelIP!!).
Der Adressbereich für CGNAT wurde im Rebind Schutznetzwerk in unbound herausgenommen, da hierunter auch der Netzwerkbereich der offenen Fachdienste fallen (100.102.0.0/15).

Hier mein Problem:
Der Client der mit KIM kommunizieren muss, wurde von der Firewall zurückgewiesen, weil, so vermute ich, in seinen Einstellungen ein lokaler DNS Server (192.168.115.1) die Verbindung zu KIM aufnahm und eine Adresse aus dem Netzwerkbereich 100.102.0.0/15 (konkret 100.102.8.6) zurückkam (Rebind Schutz).

Erst als ich Blockregel auf der LAN Schnittstelle für externe DNS deaktivierte und einen öffentliche DNS Server in dem Client händisch einstellte (9.9.9.9) gelang eine Verbindung zu KIM+.

Nun könnte man ja sagen geht doch!

Aber im Moment habe ich auf dem LAN Netzwerk jedoch die Auflösungen externer DNS Server erlaubt.
Meine Frage ist daher mit welcher eleganten Lösung ich dem Client möglich machen kann, trotz Rebind Schutz Kontakt zu KIM+ aufzunehmen (siehe Bild). Und warum funktioniert nicht das Löschen des Netzwerkes CGNAT (100.64.0.0/10) aus der Einstellung von unbound wo die Rebind Schutznetzwerke definiert sind?

Bin froh dass es soweit funktioniert. Die Feinjustierung folgt Schritt für Schritt.

Today was the switchover to the HSK Gateway at TI.

My outbound NAT rule only worked after I created an any to any rule on the enc0 interface (IPsec). I'm just glad the setup is working for now.

I'll check later whether I can better control the firewall's behavior with rules in front of it, so I don't allow access to every local network user.

A final connection problem with a specific service could only be solved by, contrary to my original configuration of only answering local DNS queries via Adguard Home and Unbound as resolvers and blocking external queries, entering a public address (Quad 9) on the server and allowing only that client access to Quad 9.

The reason is likely a block of addresses from the CGNAT range 100.64.0.0/10 (the relevant range for me is addresses 100.102.0.0/15, which are within this range).

Since I have removed DNS rebinding protection for the CGNAT address range in my unbound configuration, I don't understand why the request was blocked. I don't think this is an IPsec problem and therefore probably doesn't belong in this section.

In the child configuration, an any-to-any configuration is defined:

0.0.0.0/0 0.0.0.0/0. (Image 1)

As I understand it, all interfaces have the option to use the IPsec tunnel. However, if I want to exclude the guest network, I need to define a firewall rule for IPsec that blocks it, right? (Image 2)

Does the IPsec interface require firewall rules like all other interfaces, such as (just an example of a rule set on a guest network interface), or does it initially work out of the box and the interface is only used for fine-graining source/destination rules?

If you skip firewall rules on VTI interfaces, all NAT and Firewall rules should be defined on the enc0 interface (IPsec).

If you are careful and selective with the scope (source + destination) of these rules they shouldnt affect each other between vti and policy based tunnels.

Please note that the only way to have both VTI + policy at the same time and matching NAT on them is via skip firewall rules and only using the enc0 interface (for rules and NAT)

Thanks again.
Sometimes you can't see the forest for the trees. So the brief reminder was helpful because it brought me back down to earth.

Thanks also for the great work on the OPNsense project.

Thank you so much, I'll try it later. I literally spent the whole night trying frustratingly, trying seemingly every possible combination. I have to go to work now. Thank you again.