18.04.2023, aktualisiert um 12:29:22 Uhr

2485

Pfsense RW Wireguard DNS Namen im entferntem Netz nutzen

Guten Tag

Ich nutze eine RW Wireguard verbindung auf Windows 11, und verbinde mich via PFsense Wireguard VPN mit einem entferntem Netzwerk.
Ich tunnel den gesamten Verkehr über die Verbindung. Ip Adressen lassen sich im entferntem Netz ansprechen, genau so wie Internetadressen getunnelt mit der externen Quellip des entferntem netzes. Dort funktioniert auch ganz normal die Domainnamensauflösung.

Wenn ich jedoch mit zum Beispiel einer remote App oder auch nur via Ping einen dns Namen im entferntem Netz erreichen will funktioniert dies nicht.

Ich nutze Pfsense 2.6.0 mit dem Wireguard Plugin 0.1.6_2

Bei einem Wireguard auf einer Fritzbox läuft es. Dort ist in der Wireguard Config des clients als DNS die Fritz Box eingetragen. Nicht der DNS Server im internen Netz (DC)
Ich habe daher die Einstellungen wie folgt verändert :

[Interface]
PrivateKey = *Private Key*
Address = 10.10.58.111/24
DNS = 192.168.1.253, pfsense.firewall
(Das ist die IP und Hostname der PFsense, ip und Hostname des DC und DNS im etferntem Netz habe ich bereits ohne Erfolg ausprobiert)

[Peer]
PublicKey = *Public Key*
AllowedIPs = 192.168.1.0/24, 0.0.0.0/0
Endpoint = *Externe IP des Wireguard Servers*:51821
Haken bei Blockiere Verkehr ausserhalb des tunels ist gesetzt

Nun kann ich den Host DC01 im entferntem Netz jedoch nicht via namen pingen.
Im anderen Netz, wo die Fritzbox den Wireguard Server stellt, geht dis mit faktisch identischen Einstellungen jedoch.
Ich gehe also davon aus, auf der PfSense muss etwas eingestellt werden.
Ich vermute im Bereich DNS Resover ?
Dieser ist aktiv.
zum Probieren habe ich schon mal DNS Query Forwarding aktiviert, und den dns Server im Internen Netz der Pfsense eingetragen unter System > General Setup
Leider auch ohne Erfolg
Hat jemand eine Idee ?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 6819513872

Url: https://administrator.de/contentid/6819513872

Ausgedruckt am: 19.12.2024 um 10:12 Uhr

12 Kommentare

Neuester Kommentar

Die o.a. Konfig ist zumindestens bei den Allowed IPs in der Peer Section falsch.
Wenn du ein Gateway Redirect machst ist es doch vollkommen überflüssig dann dort noch einmal 192.168.1.0/24 anzugeben wenn du so oder so mit 0.0.0.0/0 alles in den Tunnel routest.
Das das dann sinnfrei ist erkennst du sicher selber und solltest du deshalb auch aus der Konfig entfernen. Bei einem Gateway Redirect steht einzig und allein nur noch 0.0.0.0/0 unter dem AllowedIPs Parameter!

Was die DNS Auflösung anbetrifft ist die Konfig soweit richtig, denn wenn der Tunnel aktiv ist wird die 192.168.1.253 als primärer DNS Server an den Client übergeben.
Das "pfsense.firewall" dahinter macht natürlich nur dann Sinn wenn der primäre DNS Server diesen Hostnamen auch auflösen kann oder eine DNS Weiterleitung zu einem DNS Server hat der auflösen kann, ansonsten ist er überflüssig.
Was du bei aktivem Tunnel dann unbedingt testen solltest ist...

Mit ipconfig -all (Winblows) checken ob der primäre DNS Server auch auf die o.a. IP gesetzt ist. Ein nslookup ohne Parameter geht auch.
Mit nslookup hostname.intern versuchen einen internen Hostnamen über den internen DNS Server aufzulösen. hostname.intern muss dann natürlich intern auflösbar sein!
Mit nslookup hostname.intern 192.168.1.253 kannst du auch den DNS Server erzwingen zur Auflösung.
Stelle sicher das deine TLD Suchdomain im Client entsprechend konfiguriert ist sofern du Hostnamen ohne den kompletten FQDN angibst.

Moin...

Address = 10.10.58.111/24

und das wäre eher ein /32

Frank

und das wäre eher ein /32

Nein, das ist leider falsch!
Die Device IP Adressen im internen WG Netz werden immer mit der dort verwendeten Netzmaske angegeben. Ist ja nichts anderes wie auch an einem LAN Adapter an einem Rechner.

Nur die Adressen in den AllowedIPs der Peer Definition werden dann mit einem 32er Host Prefix angeben (in der Regel der VPN Server und analog bei Server die Client Peers) um das Crypto Routing eindeutig zu machen. Sprich es taucht also nur da auf.
Siehe dazu auch im hier oder an einem Praxisbeispiel bzw. WG Tutorial.
Das ist aber einzig nur in einem Split Tunneling Setup relevant!

Für den TO, der ja statt Split Tunneling ein Gateway Redirect Setup betreibt das eh sämtlichen Traffic in den Tunnel schaufelt ist das nicht relevant.

Moin...

Zitat von @aqui:

und das wäre eher ein /32

Nein, das ist leider falsch!

äh stimmt... jetzt wo du es schreibst

Die Device IP Adressen im internen WG Netz werden immer mit der dort verwendeten Netzmaske angegeben. Ist ja nichts anderes wie auch an einem LAN Adapter an einem Rechner.

Nur die Adressen in den AllowedIPs der Peer Definition werden dann mit einem 32er Host Prefix angeben (in der Regel der VPN Server und analog bei Server die Client Peers) um das Crypto Routing eindeutig zu machen. Sprich es taucht also nur da auf.
Siehe dazu auch im hier oder an einem Praxisbeispiel bzw. WG Tutorial.
Das ist aber einzig nur in einem Split Tunneling Setup relevant!

Für den TO, der ja statt Split Tunneling ein Gateway Redirect Setup betreibt das eh sämtlichen Traffic in den Tunnel schaufelt ist das nicht relevant.

in der Tat..

Zitat von @aqui:

Die o.a. Konfig ist zumindestens bei den Allowed IPs in der Peer Section falsch.
Wenn du ein Gateway Redirect machst ist es doch vollkommen überflüssig dann dort noch einmal 192.168.1.0/24 anzugeben wenn du so oder so mit 0.0.0.0/0 alles in den Tunnel routest.

Ja das sehe ich auch als Anfänger so. Ich habe für die Versuche lediglich die Config so weit es geht von einer funktionierenden Fritzbox (7.50) Config kopiert. (es handelt sich da um ein Netz mit DC und einer Fritzbox als Firewall. Die Konfiguration wurde automatisiert erstellt.) Dort funktionieren dns Namen, lustigerweise auch dann wenn ich der Fritzbox nie den domänen DNS bekannt gegeben habe. Ich habe diesen Eintrag als "nicht schädlich" angesehen. Ich habe dies nun korrigiert.

Was die DNS Auflösung anbetrifft ist die Konfig soweit richtig, denn wenn der Tunnel aktiv ist wird die 192.168.1.253 als primärer DNS Server an den Client übergeben.
Das "pfsense.firewall" dahinter macht natürlich nur dann Sinn wenn der primäre DNS Server diesen Hostnamen auch auflösen kann oder eine DNS Weiterleitung zu einem DNS Server hat der auflösen kann, ansonsten ist er überflüssig.

Auch hier habe ich bling kopiert. Ist bereits gelöscht.
Was ich mich immer noch frage. die Pfsense muss doch wissen das es den DNS Server unter 192,168.1.254 gibt. ?
Sobald ich unter DNS Vorwarder DNS Query Forwarding aktiviere, und die IP Adresse des netzinternem DNS eintrage funktioniert das "Internet" nicht mehr.

Was du bei aktivem Tunnel dann unbedingt testen solltest ist...

Mit ipconfig -all (Winblows) checken ob der primäre DNS Server auch auf die o.a. IP gesetzt ist.

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : XMG
   Primäres DNS-Suffix . . . . . . . :
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein
   DNS-Suffixsuchliste . . . . . . . : fritz.box

Unbekannter Adapter Blomberg:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : WireGuard Tunnel
   Physische Adresse . . . . . . . . :
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 10.10.58.111(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 0.0.0.0
   DNS-Server  . . . . . . . . . . . : 192.168.1.253
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Drahtlos-LAN-Adapter LAN-Verbindung* 1:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter
   Physische Adresse . . . . . . . . : A4-B1-C1-C7-67-68
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Drahtlos-LAN-Adapter LAN-Verbindung* 2:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter #2
   Physische Adresse . . . . . . . . : A6-B1-C1-C7-67-67
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Drahtlos-LAN-Adapter WLAN:

   Verbindungsspezifisches DNS-Suffix: fritz.box
   Beschreibung. . . . . . . . . . . : Intel(R) Wi-Fi 6 AX200 160MHz
   Physische Adresse . . . . . . . . : A4-B1-C1-C7-67-67
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   IPv6-Adresse. . . . . . . . . . . : 2003:e2:7f0f:a400:6f84:f8a9:325a:16c1(Bevorzugt)
   IPv6-Adresse. . . . . . . . . . . : 2003:e2:7f0f:a400:ab75:7c5e:3ed9:eab2(Bevorzugt)
   Lease erhalten. . . . . . . . . . : Donnerstag, 20. April 2023 12:25:07
   Lease läuft ab. . . . . . . . . . : Donnerstag, 20. April 2023 15:25:06
   Temporäre IPv6-Adresse. . . . . . : 2003:e2:7f0f:a400:5ced:d0aa:86:a67b(Bevorzugt)
   Verbindungslokale IPv6-Adresse  . : fe80::ab75:7c5e:3ed9:eab2%12(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.111.109(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Mittwoch, 19. April 2023 12:23:56
   Lease läuft ab. . . . . . . . . . : Sonntag, 30. April 2023 12:25:05
   Standardgateway . . . . . . . . . : fe80::464e:6dff:fe5b:9fec%12
                                       192.168.111.253
   DHCP-Server . . . . . . . . . . . : 192.168.111.253
   DHCPv6-IAID . . . . . . . . . . . : 128233921
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-2A-ED-7E-39-B0-25-AA-41-E4-5E
   DNS-Server  . . . . . . . . . . . : fd00::464e:6dff:fe5b:9fec
                                       2003:e2:7f0f:a400:464e:6dff:fe5b:9fec
                                       192.168.111.253
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

* Mit nslookup hostname.intern versuchen einen internen Hostnamen über den internen DNS Server aufzulösen. hostname.intern muss dann natürlich intern auflösbar sein!

Server:  SchulePfSense.Schule.int
Address:  192.168.1.253

*** //dc01// wurde von SchulePfSense.Schule.int nicht gefunden: Non-existent domain.

Das ergibt für mich auch Sinn, denn die PFsense kennt den internen DNS ja nicht.
Also DNS Resolver DNS Query Forwarding aktiviert, und unter System General Setup die IP Adresse des internen DNS angegeben. Ab da spinnt intern die Auflösung ins Internet, und ich habe auch über den Tunnel keine dns Auflösung mehr.
Die Meldung dann :

Server:  SchulePfSense.Schule.int
Address:  192.168.1.253

*** //dc01// wurde von SchulePfSense.Schule.int nicht gefunden: Server failed.

* Mit nslookup hostname.intern 192.168.1.253 kannst du auch den DNS Server erzwingen zur Auflösung.

Stelle sicher das deine TLD Suchdomain im Client entsprechend konfiguriert ist sofern du Hostnamen ohne den kompletten FQDN angibst.

Zur Sicherheit mit Domäne dahinter "dc01.Domäne.int" versucht. Leider sind die Meldungen dann zu oben identisch.
Ich bin mir laienhaft ziemlich Sicher das der DNS Resolver nicht so konfiguriert ist, wie er sollte ?
lg

die Config so weit es geht von einer funktionierenden Fritzbox (7.50) Config kopiert.

Immer einen schlechte Idee, denn AVM nutzt bekanntlich eine nicht Wireguard konforme Konfiguration was man beachten muss wenn man auf externe nicht AVM Wireguard Endgeräte vernetzt.
https://www.heise.de/ratgeber/Fritzbox-VPN-Was-WireGuard-ausmacht-und-wi ...

die Pfsense muss doch wissen das es den DNS Server unter 192,168.1.254 gibt. ?

Jein!
Das kann sie natürlich nur wissen wenn DU ihr das im General Setup konfigurierst und auch den Haken setzt das PPPoE und DHCP diesen statischen DNS Eintrag nicht überschreiben dürfen!

Sobald ich unter DNS Vorwarder DNS Query Forwarding aktiviere

Das das "Internet" nicht mehr funktioniert ist natürlich Unsinn und weisst du auch selber. Kannst ja immer im "Diagnostics" Menü mit der WAN IP als Source einmal einen reine Internet IP wie 8.8.8.8 pingen dann weisst du das es geht! Du meist vermutlich das die DNS Auflösung dann scheitert, oder?!
Vermutlich hast du dann vergessen DNSsec zu deaktivieren. Guckst du dazu auch hier.

Das ergibt für mich auch Sinn, denn die PFsense kennt den internen DNS ja nicht.

Dann solltest du ihr den im General Setup tunlichst konfigurieren wie oben schon gesagt!

das der DNS Resolver nicht so konfiguriert ist, wie er sollte ?

Oben redest du noch vom "Forwarder" ?! Ja was denn nun ?? Resolver oder Forwarder?!

Wenn es das denn nun war bitte deinen Thread dann hier auch als erledigt schliessen!

Noch nicht erledigt. Ich bin nur noch nicht dazu gekommen das weiter zu testen, da ich das nur spät abends, oder nachts machen kann

Dann harren wir mal der Ergebnisse die da kommen sollen...

Zitat von @aqui:

Dann harren wir mal der Ergebnisse die da kommen sollen...

Danke für die Geduld.

Bisher ist der Resolver so eingestellt (Bilder)

Was deinen Link angeht.
DNSsec auf den bildern noch aktiv, habe ich kurz ausprobiert zu deaktivieren. Leider hat dies nichts geändert.
Block private networks and loopback addresses ist auf den Wan Ports tatsächlich aktiv.
Hinter deinem Link wird auch das deaktiviert. Das Problem dort war aber vermutlich ein anderes, da es ja hier um einen Tunnel geht.

Das Ergebnis ist noch immer das ich im entferntem Netz (192.168.1.0/24) keinen DNS Namen auflösen kann.
Hinzu kommt, das die DNS Auflösung für das Internet via Tunnel sehr verzögert ist. Viele Seiten laufen ins timeout, und sind nach mehrmaliger Aktualisierung sichtbar. Laut Berichten ist dies auch lokal im entferntem Netz der Fall.

Ich vermute ich darf nicht alle Netze im Resolver angeben. Aufgelöst werden über den Tunnel soll ja nur das 192.168.1.0/24er Netz, und das Internet.

Die Option unter DNS Resolution Behavior wäre für mich auch noch ein Ansatzpunkt. Aber ich kann das leider erst nachts testen.