Messages

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.

Thank you very much for the quick reply.

I have a second policy-based IPsec connection. Will there be any conflicts if the ENC0 interface has an outbound rule?

Wouldn't it be better to disable the skip firewall rule again?

Do firewall rules need to be defined on the IPsec interface for the outbound rules to take effect?

I would be very grateful for any help.

Hello Forum

NAT Outbound on the VTI interface is not working.

Countless attempts have failed. The task is to establish a connection to the TI Gateway. The connection is established. A ping to the connector resolves.

DNS queries to splitdns.ti-dienste.de are answered.

However, when I try to resolve a query using curl, no rewrite to the local tunnel IP address occurs. Instead, the local client address appears:
IP 192.168.115.199.57949 > 100.102.31.5.443:

"Skip firewall rules" is checked in the virtual interface.

The NAT Outbound rule (hybrid mode) looks like this:

Hi Q-feeds,

I have two questions:

1. I currently have Crowdsec installed. Should I uninstall Crowdsec to avoid redundancy (for troubleshooting purposes), or do Q-Feeds and Crowdsec complement each other?

2. I'm currently using AdGuard Home and Unbound. What's the best way to integrate Q-Feeds' DNS functionality? Is there a DNSBL that I can configure in AdGuard with a corresponding API token, for example, in the format "https://api.qfeeds.com/feed/domain_blacklist.txt?key=<API_KEY>"?

Thank you in advance for your reply.