[GELÖST] IPsec und DNS (wie kommuniziert die OPNsense selber im Tunnel)

[NDregger]

Hallo Freunde der OPNsense,

ich glaube ich komme meinem Problem mit dem Unbound DNS und der DNS Weiterleitung endlich auf die Spur. So wie früher mit den Gateways anderer Hersteller versuche ich mit der OPNsense eine gefühlte einfache Lösung: DNS Weiterleitung an einen entfernten, nur per VPN erreichbaren DNS Server damit das Active Directory vom Hauptstandort auch per IPsec Tunnel erreichbar ist ohne die Clients direkt auf DNS Server der entfernten Gegenstelle zu schicken.

Heute glaube ich endlich den Grund für meine nicht funktionierende DNS Weiterleitung mit Unbound gefunden zu haben: Er kann den entfernten DNS schlicht und einfach nicht erreichen! Wie ich darauf komme: Versuche ich von einem beliebigen System hinter der Remote OPNsense den zentralen DNS zu pingen klappt das, nicht aber wenn es die OPNsense selber probiert (habe es über die SSH Shell getestet).

Von Bintec Routern kenne ich die IPsec Konfiguration so, das ich im Tunnel konfigurieren muss mit welcher IP der Router selber in den Tunnel kommunizieren darf, sonst würde er nämlich nicht die richtige IP nehmen. Kann es ein das genau hier mein Fehler liegt und ich der OPNsense bei einem IPsec Tunnel sagen muss mit welcher seiner IPs er überhaupt in den Tunnel gehen soll?

Hintergrund: An unserer Schule läuft eine OPNsense 24.1 mit zwei DSL Anschlüssen und mehreren internen Netzen (Verwaltung, Schüler, PBX usw) und daher glaube ich muss der OPNsense sagen mit welcher IP sie in den Tunnel kommunizieren soll.

Ich hoffe mal es ist verständlich wo ich den Knoten sehe und hoffe auf eine schlaue Idee von euch!

Grüße aus BaWü
Norbert

[Patrick M. Hausen]

Bei einem Policy Based Tunnel hat der Tunnel keine Adressen. Du kannst z.B. in den Tunnel gehende Pakete auf die LAN-Adresse der Firewall NATen.

[NDregger]

Hallo Patrick,

wenn ich Dich richtig verstehe habe ich das Problem, weil ich den Tunnel ausschließlich im Legacy Mode eingerichtet habe und es damit ein rein Policy based routing ist, richtig?

Wie wäre denn der richtige Weg das einzurichten?


Norbert

[NDregger]

Ich habe mir noch mal die Outbound NAT Regeln der OPNsense angesehen und dachte ich hätte die richtige Richtung, nur leider scheint mir noch was zu fehlen....

Im Moment sieht meine - nicht funktionierende - Regel so aus:
- Interface IPsec
- IPv4
- Protocol any
- Source adresse This Firewall
- Source port any
- Destination adress Firewall Alias für die Remote Site
- Destination Port any
- Translation / target auf LAN_Verwaltung adress (sagt mir die IP die ich auf dem Interface LAN_Verwaltung habe)

Der Rest steht auf Standard

Stimmt die Richtung oder denke ich hier komplett falsch?

Müde Grüße
Norbert

[Monviech (Cedrik)]

Hallo Patrick,

wenn ich Dich richtig verstehe habe ich das Problem, weil ich den Tunnel ausschließlich im Legacy Mode eingerichtet habe und es damit ein rein Policy based routing ist, richtig?

Wie wäre denn der richtige Weg das einzurichten?


Norbert

Nein bei IPsec gibt es 2 Arten von Tunneln. "Policy Based" heißt, dass über den Tunnel mehrere Netze miteinander verbunden werden. Der IPsec Tunnel selbst hat aber kein eigenes Netz, und keine IP Adressen auf den Interfaces.
Die andere Art ist der VTI Tunnel, der hat ein Transfer Netz und es werden Routen auf die IPsec Interfaces gesetzt, welche IP Adressen besitzen.

Es ist egal ob du Legacy oder Connections in der GUI verwendest.

Eine einfache Art, die Firewalls kommunizieren zu lassen, ist die IP Adressen von Interfaces anzusprechen, die auf den Firewalls schon existieren. Wenn du z.B. 172.16.0.0/24 mit 192.168.0.0/24 durch eine IPsec Policy verbindest, dann sollte es auf beiden Firewalls Interfaces mit z.B. 192.168.0.1/24 und 172.16.0.1/24 (z.B. die LAN interfaces) geben. Darauf hört Unbound (wenn du es auf ANY interfaces hören lässt), und mit einer Firewallregel auf dem IPsec oder LAN interface zu destination "This Firewall" kann UDP/TCP 53 erlaubt werden.

Für den Ping test durch den VPN Tunnel zur anderen Firewall würde ich explizit das Interface angeben.

Auf der einen Firewall

ping -S 192.168.0.1 172.16.0.1

Auf der anderen Firewall:

tcpdump -i enc0 proto ICMP

[Patrick M. Hausen]

@Monviech wie kriegt man bei Unbound die Query-Source-Address so hin, dass das die aus dem verbundenen Netz ist? Habe ich in der Doku nicht gefunden. Ich benutze BIND, da gibt es die Option, und das fluppt alles auch ohne NAT.

[NDregger]

Guten Morgen,

ich habe das gerade mal mit dem Ping Befehl unter Angabe der Source Adresse probiert und damit können sich beide OPNsense pingen, so gesehen passt (wie erwartet) mein grundsätzlicher Tunnel schon mal :-)

Ich bin gespannt ob Patrick so lieb ist mir mit der NAT Regel noch auf die Sprünge zu helfen um das zu lösen :-) Hätte halt den Scharm, das es würde für jegliche Kommunikation zwischen den beiden OPNsense gleich funktionieren würde :-)

Gruß
Norbert

[NDregger]

Hier sieht man wie es durch die Angabe der Source IP funktioniert :-)

[Monviech (Cedrik)]

@Patrick

Hah ich hab das nur auf Umwegen laufen. Ich forwarde mit Unbound zu einem DNS Server der im Netzwerk auf "meiner Seite" läuft (eins das durch die Policy durch den Tunnel kommunizieren darf), und der forwarded dann auf die andere Seite. Also eine DNS Kaskade.

Mit VTI Tunnel, oder Wireguard geht es direkt. Ich muss aber Policy based IPsec verwenden also halt Notlösung. ^^

[Patrick M. Hausen]

@NDregger sorry, ich hab das mit NAT nirgends selbst am laufen. Du könntest natürlich auf der Sense den BIND zusätzlich zum Unbound aktivieren, ersteren als Forwarder für letzteren eintragen, und dann die Source Address einstellen.

[Monviech (Cedrik)]

Verkehr, den die OPNsense erzeugt, selber zu NATen, das ist nicht möglich.

Vergleiche hier:
https://forum.opnsense.org/index.php?topic=36642.msg178914#msg178914
https://forum.opnsense.org/index.php?topic=35521.msg172596#msg172596

Hier ging es aber explizit um DNAT, aber SNAT geht wahrscheinlich auch nicht, da der Verkehr im Loopback Interface erzeugt wird.

Meine Empfehlung:

Mach einen kleinen Wireguard Tunnel um die Unbounds der OPNsensen zu verbinden.

[NDregger]

Hach kann die Welt doch einfach sein wenn man nur weiß wie...

Hatte gerade ein kurzes Gespräch mit Ad, und jetzt ist mir seine Erklärung auch endlich verständlich...

Wie verhält sich eine OPNsense intern? Wer mit SSH sich auf ihr anmeldet und die Routing Tabelle ansieht wird feststellen, das nicht eine der VPN Verbindungen die per policy based routing in ihrer Routing  Tabelle sichtbar sind, und damit nutzt sie ihre Standroute beim Versuch eines Ping / DNS Auflösung via VPN oder was auch immer.

Auch wenn sich der Lösungsweg komplett schräg anhört: Er funktioniert! Ad hat es mir einmal gezeigt, ich habe es schon mehrfach nachgebaut...

1.) Unter System: Gateways: Configuration die OPNsense selber mit der LAN IP, die für den VPN Tunnel genutzt werden soll, als Gateway eintragen
2.) Unter System: Routes: Configuration eine Route für das bislang nur per policy baesd routing bekannte Netz anlegen und als Gateway das zuvor unter Punkt 1 angelegte nutzen.

Fertig!

Wer es kontrollieren möchte: mit einem netstat -nr4 vor der Anpassung sieht man nur die LAN Routen (durch die vorhandenen Interfaces) plus PPPoE Verbindungen als default route, mehr nicht. Nach der Anpassung wird die händisch hinzugefügte Route angezeigt und genutzt!

Ich hoffe mal die Erklärung hilft euch, bei Rückfragen einfach melden!

Gruß
Norbert

[NDregger]

Hallo Freunde der OPNsense,

ich glaube ich komme meinem Problem mit dem Unbound DNS und der DNS Weiterleitung endlich auf die Spur. So wie früher mit den Gateways anderer Hersteller versuche ich mit der OPNsense eine gefühlte einfache Lösung: DNS Weiterleitung an einen entfernten, nur per VPN erreichbaren DNS Server damit das Active Directory vom Hauptstandort auch per IPsec Tunnel erreichbar ist ohne die Clients direkt auf DNS Server der entfernten Gegenstelle zu schicken.

Heute glaube ich endlich den Grund für meine nicht funktionierende DNS Weiterleitung mit Unbound gefunden zu haben: Er kann den entfernten DNS schlicht und einfach nicht erreichen! Wie ich darauf komme: Versuche ich von einem beliebigen System hinter der Remote OPNsense den zentralen DNS zu pingen klappt das, nicht aber wenn es die OPNsense selber probiert (habe es über die SSH Shell getestet).

Von Bintec Routern kenne ich die IPsec Konfiguration so, das ich im Tunnel konfigurieren muss mit welcher IP der Router selber in den Tunnel kommunizieren darf, sonst würde er nämlich nicht die richtige IP nehmen. Kann es ein das genau hier mein Fehler liegt und ich der OPNsense bei einem IPsec Tunnel sagen muss mit welcher seiner IPs er überhaupt in den Tunnel gehen soll?

Hintergrund: An unserer Schule läuft eine OPNsense 24.1 mit zwei DSL Anschlüssen und mehreren internen Netzen (Verwaltung, Schüler, PBX usw) und daher glaube ich muss der OPNsense sagen mit welcher IP sie in den Tunnel kommunizieren soll.

Ich hoffe mal es ist verständlich wo ich den Knoten sehe und hoffe auf eine schlaue Idee von euch!

Grüße aus BaWü
Norbert

[Patrick M. Hausen]

@NDregger - coole Sache, vielen Dank. Da hab ich heute auch noch was gelernt.

[lfrieseke]

Kommt immer auf das DNS Setup an. Bei IKEv2 und einem Client VPN kann man dediziert einen DNS mitgeben beim Client VPN Setup.
https://administrator.de/tutorial/ipsec-ikev2-vpn-fuer-mobile-benutzer-auf-der-pfsense-oder-opnsense-firewall-einrichten-337198.html