Wechseln zu:Navigation, Suche
Wiki

Nameserver

Aus Securepoint Wiki





notempty
Dieser Artikel bezieht sich auf eine nicht mehr aktuelle Version!

notempty
Der Artikel für die neueste Version steht hier

notempty
Zu diesem Artikel gibt es bereits eine neuere Version, die sich allerdings auf eine Reseller-Preview bezieht





















































| }}




























































































Nameserver Konfiguration auf der UTM
Letzte Anpassung zur Version: 12.2.2
Neu:
  • IPv6-Adressen in der Relay-Zone
  • Layoutanpassung
notempty
Dieser Artikel bezieht sich auf eine Resellerpreview

v11.6

Einleitung

Der Nameserver der UTM bietet:

  • Forward-Zonen: Namensauflösung (FQDN) in IP-Adressen
  • Reverse-Zonen: IP-Adressen in FQDN)
  • Relay-Zonen: Weiterleiten von Anfragen, die zu einer bestimmten Domain gehören
  • DNS Forwarding: Weiterleiten sämtlicher DNS Anfragen
  • Um den Nameserver der UTM nutzen zu können, muss im Portfilter eine Regel mit dem jeweiligen Netz als Quelle und dem Ziel Interface.svg xy-Interface existieren.
    Als Dienst muss mindestens Service-group.svg dns erlaubt werden (Port 53 für TCP und UDP).
    Es emfpiehlt sich in der Regel jedoch die Dienstgruppe Service-group.svg proxy zu verwenden. Dies gibt weitere Ports für Dienste wie z.B. den transparenten Proxy, webcache oder einen Ping frei.


    • Voraussetzungen

    Nameserver der Firewall festlegen

    Nur für interne Prüfzwecke

    Datei:UTM v12.2.2 Nameserver Servereinstellungen.png
    Nameserver IP

    Im ersten Schritt muss die UTM selbst als Nameserver der Firewall festgelegt werden.

    1. Konfiguration unter → Netzwerk →Servereinstellungen Abschnitt
      DNS-Server
    2. Tragen Sie im Feld Primärer Nameserver als IP die 127.0.0.1 (localhost) ein.
    3. Klicken Sie auf Speichern
  • Wird kein Nameserver hinterlegt, werden DNS-Anfragen über die root-DNS-Server und die dort hinterlegten DNS-Server für die Top-Level-Domains aufglöst



    • Forward-Zone

    Eine Foward-Zone wird zur Umsetzung von Domainnamen in IP-Adressen verwendet.
    Diese Umsetzung ist sowohl in IPv4 (A) als auch in IPv6 (AAAA) möglich. In dem folgenden Einrichtungsbeispiel wird das Anlegen eines A-RR, für eine öffentliche Domain gezeigt.
    Wird der DNS der Firewall zur Auflösung verwendet, soll eine private IP aus dem internen Netz zurückgegeben werden.

    Diese Einstellung wird unter anderem dann benötigt, wenn aus dem internen Netz eine Domain aufgerufen wird, dessen öffentliche IP die der Firewall ist.
    Ohne diesen Eintrag würde man eine komplizierte Portweiterleitung benötigen, so allerdings kann die Anfrage ohne Umwege direkt an den Server gestellt werden.

    Einrichtung unter → Anwendungen →NameserverReiter Zonen Schaltfläche Forward-Zone hinzufügen

    A-RR anlegen

    Datei:UTM v12.2.2 Nameserver Forwardzone Schritt1.png
    Schritt 1
    Zonenname webserver.anyideas.de
    Domain, die von einem internen DNS-Server verwaltet wird
    Datei:UTM v12.2.2 Nameserver Forwardzone Schritt2.png
    Schritt 2
    Nameserver Hostname: localhost
    Als Nameserver dient die UTM selbst
    Datei:UTM v12.2.2 Nameserver Forwardzone Schritt3.png
    Schritt 3
    IP-Adresse:    
  • Die IP-Adresse ist nur dann erforderlich, wenn der Nameserver in der Zone liegt, die gerade erstellt wird und nicht der localhost, also die UTM selbst ist
    • Abschluss des Assistenten mit der Schaltfläche Fertig














    Beschriftung Wert Beschreibung Datei:Zone bearbeiten.png
    Zone bearbeiten
    Bearbeiten Die Zone kann durch einen Klick auf den Schraubenschlüssel bearbeitet werden
    Einstellungen
    Typ: Normal Einstellungen für Forward Zonen Datei:UTM v12.2.2 Nameserver Forwardzone.png
    Aktualisierung: 10000Link= Sekunden Frequenz, mit der der Eintrag aktualisiert wird
    Retry 1800Link= Sekunden Wiederholung der Aktualisierung bei Fehlschlag
    Läuft ab: 3600000Link= Sekunden Ablauffrist des Eintrags (beginnt nach erfolgreicher Aktualisierung erneut
    Minimum: 3600Link= Sekunden Nur für interne Prüfzwecke
    Einträge
    Typ NS localhost. Es existiert bereits ein NS-Eintrag (mit Punkt am Ende!)
    Bearbeiten Öffnet den Record-Eintrag zum bearbeiten
    Löschen Löscht den Record-Eintrag
    Eintrag hinzufügen Weiteren Record Eintrag hinzufügen
    Name webserver.anyideas.de. Gewünschter Domain Name
  • An die Domain wird ein Punkt "." gehängt (=Top-Level)
    		•  Datei:UTM v12.2.2 Nameserver Record hinzufügen.png
    Eintrag hinzufügen
    Typ: A A-Record Eintrag wählen

































    Typ Beschreibung
    NS Ein NS-Record (bzw. NS-RR: Name Server Resource Record) ist ein Datensatz eines DNS Servers und kann zwei unterschiedliche Funktionen erfüllen:
    • Er definiert, welche Nameserver für diese Zone offiziell zuständig sind.
    • Er verkettet Zonen zu einem Zonen-Baum (Delegation).

    In jedem Zonenfile muss mindestens ein NS-RR vorhanden sein, der angibt, welcher Nameserver für diese Zone autoritativ ist.
    Ist zum Bsp. die Firewall selbst zuständig muss hier "localhost" ausgewählt/eingegeben werden.

    A Mit einem A-RR (A Resource Record) wird einem DNS-Namen eine IPv4-Adresse zugeordnet.
    AAAA Mit einem AAAA Resource Record („quad-A“) wird einem DNS-Namen eine IPv6-Adresse zugeordnet.
    Es handelt sich damit um die IPv6-Entsprechung zum A Resource Record.
    TXT Mit einem TXT Resource Record kann ein frei definierbarer Text in einer DNS-Zone abgelegt werden.
    TXT Records können unter anderem zum Tunneln über DNS eingesetzt werden.
    PTR PTR Resource Records ordnen im Domain Name System einer gegebenen IP-Adresse einen oder mehrere Hostname(n) zu. Sie stellen damit gewissermaßen das Gegenstück zur klassischen Zuordnung einer oder mehrerer IP-Adresse(n) zu einem gegebenen Hostname per A- oder AAAA Resource Record dar.

    PTR Resource Records sind ein zentrales Element des Reverse DNS. Sie werden üblicherweise ausschließlich verwendet

    • in der in-addr.arpa-Zone (für den Reverse-Lookup von IPv4-Adressen),
    • in der Zone ip6.arpa (für den Reverse-Lookup von IPv6-Adressen)[1] sowie
    • in anderen Zonen für Hostnames, auf die ein CNAME Resource Record aus einer der vorgenannten Zonen zeigt.
    MX Der MX Resource Record (MX-RR) einer Domain ist ein Eintrag im Domain Name System, der sich ausschließlich auf den Dienst E-Mail (SMTP) bezieht.

    Ein MX-Record sagt aus, unter welchem Fully Qualified Domain Name (FQDN) der Mail-Server zu einer Domäne oder Subdomäne erreichbar ist. Es ist üblich, für eine Domäne mehrere MX-Records zu definieren mit unterschiedlichen Prioritäten, so dass bei Ausfall eines Mail-Servers ein anderer die E-Mails entgegennehmen kann. Dies erhöht die Wahrscheinlichkeit, dass eine Mail trotzdem an die Empfängerdomain zugestellt werden kann.

    CNAME Ein CNAME Resource Record (CNAME RR) ist im Domain Name System dazu vorgesehen, einer Domänen einen weiteren Namen zuzuordnen. Die Abkürzung "CNAME" steht für canonical name (canonical = anerkannt, bezeichnet also den primären, quasi echten Namen).

    Im einfachsten Fall verweist der Name eines CNAME Resource Records auf den Namen eines A Resource Records und/oder eines AAAA Resource Records. Die Namen dieser Resource Records verweisen auf eine IP-Adresse. Beim Wechsel einer IP-Adresse muss dann für mehrere Namen nur ein einziger Resource Record geändert werden. Ein NS Resource Record, MX Resource Record oder PTR Resource Record darf nicht auf einen CNAME Resource Record verweisen. Umgekehrt darf ein PTR Resource Record aber durchaus nur über einen CNAME Resource Record zugänglich sein. Der Name eines CNAME Resource Records darf nicht als Name anderer Resource Records verwendet werden, da er stellvertretend für alle Resource Records des Ziels steht.

    Wert 192.168.222.2 IP des Servers, auf den die Domain verweisen soll
    Speichern Schließt den Dialog für den DNS-Record
    Speichern Schließt den Dialog zum bearbeiten der Zone

    A-RR testen

    Testen des angelegten A-RR unter: → Netzwerk →NetzwerkwerkzeugeReiter Host
    Einstellungen
    		Datei:UTM v12.2.2 Nameserver A-RR testen.png
    Abfragetyp A Abfragetyp des Angelegten DNS-Records
    Hostname webserver.anyideas.de Webserver-Adresse wie im Record-Eintrag unter Name eingetragen (mit oder ohne den abschließenden Punkt)
    Nameserver 127.0.0.1 Localhost-Adresse der UTM

    Anwort

    Im unteren Fenster wird, wenn alles richtig eingerichtet wurde, die Domain auf die korrekte IP-Adresse aufgelöst.

    Alternatives Testen durch ein nslookup webserver.anyideas.de von einem Rechner aus dem Netzwerk der UTM

    Reverse-Zone

    • Reverse DNS lookup (rDNS) bezeichnet eine DNS-Anfrage, bei der zu einer IP-Adresse der Name ermittelt werden soll
  • Als RR-Typen sind nur PTR Resource Records zulässig
    Bei einem PTR-RR steht eine IP-Adresse als Anfragebasis und ein Name als Ergebnis – im Gegensatz zum A Resource Record, wo ein Name die Anfrage und eine IP-Adresse das Ergebnis darstellt.
    • Genutzt wird ein rDNS lookup häufig im Zusammenhang mit Spamfiltern.
      Viele Spam-Mails werden von Fake-Domainen versendet.
      Der Empfänger kann anhand einer Rückauflösung der IP festzustellen ob die Domain auch wirklich zu der ankommenden IP gehört, ist dies nicht der Fall wird die Mail abgewiesen.

    PTR-RR anlegen

    Im nächsten Schritt wird der PTR-RR angelegt.

    Zum Verständnis hier eine kurze Beschreibung:

    Da es extrem zeitaufwändig wäre, bei einer inversen Anfrage den gesamten Domänen-Baum nach der gewünschten IPv4-Adresse zu durchsuchen wurde eine eigenständige Domäne für inverse Zugriffe gebildet, die in-addr.arpa-Domäne. Unterhalb dieser Domäne existieren lediglich drei Subdomänen-Ebenen, so dass maximal drei Schritte zur Auflösung einer IPv4-Adresse erforderlich sind. Die unmittelbaren Subdomänen von in-addr.arpa haben als Label eine Zahl zwischen 0 und 255 und repräsentieren die erste Komponente einer IPv4-Adresse. (Beispiel: 64.in-addr.arpa oder 192.in-addr.arpa). Die nächste Ebene im Baum repräsentiert die zweite Komponente einer IPv4-Adresse (Beispiel: 27.64.in-addr.arpa. enthält die IPv4-Adressen 64.27.x.y) und die unterste Ebene schließlich die dritte Komponente (Beispiel: 125.27.64.in-addr.arpa enthält alle bekannten IPv4-Adressen des Netzes 64.27.125.0/24 – also z. B. 64.27.125.60).

    Wie aus den Beispielen ersichtlich ist, enthält ein reverser Name die IP-Adresskomponenten in umgekehrter Reihenfolge. Diese Struktur ermöglicht ein Verfeinern des reversen Adressraums in mehreren Schritten. In unserem folgenden Einrichtungsbeispiel werden wir mit dem letzten Adressraum (/24) arbeiten.

    1. Gehen Sie in der Navigationsleiste auf den Punkt Anwendungen und klicken sie im Dropdown-Menü auf Nameserver.
    2. Klicken Sie im erscheinenden Dialog auf den Button Reverse-Zone hinzufügen.
    3. Tragen Sie im Step 1 das gewünschte Subnetz ein, indem sich die IP-Adresse zu der gewünschten Domain befindet.
    4. Tragen Sie im Step 2 unter Nameserver "localhost" ein und klicken sie auf Fertig.

    Der Zonenname bildet sich automatisch wie im oberen Beispiel beschrieben.

    1. Bearbeiten Sie durch einen Klick auf den Schraubenschlüssel die angelegte Zone.
    2. Klicken Sie im erscheinenden Dialog auf den Button Eintrag hinzufügen.
    3. Tragen Sie in das Feld "Name", die letzte Zahl der Host-IP ein, die zu der gewünschten Domain gehört (In unserem Beispiel die "60".)
    4. Als Typ wählen Sie "PTR".
    5. In das Feld Wert tragen Sie die Domain ein auf die die IP-Adresse zeigen soll. An die Domain wird ein Punkt "." angehängt!
    6. Klicken Sie auf Hinzufügen.
    7. Klicken Sie auf Speichern.
    Nur für interne Prüfzwecke

    Reverse-Zone hinzufügen

    Datei:UTM v12.2.2 Nameserver Reversezone Schritt1.png
    Schritt 1
    Das gewünschte Subnetz, indem sich die IP-Adresse zu der gewünschten Domain befindet
    Datei:UTM v12.2.2 Nameserver Reversezone Schritt2.png
    Schritt 2
    Nameserver ist der localhost, also die UTM selbst
    Abschluss des Assitenten mit der Schaltfläche Fertig













    Name 60 Der letzte Zahlblock der Host-IP, die zu der gewünschten Domain gehört (Im Beispiel die 60) PTR-anlegen.jpg
    ?
    Typ: PTR PTR (Pointer)-Record

































    Typ Beschreibung
    NS Ein NS-Record (bzw. NS-RR: Name Server Resource Record) ist ein Datensatz eines DNS Servers und kann zwei unterschiedliche Funktionen erfüllen:
    • Er definiert, welche Nameserver für diese Zone offiziell zuständig sind.
    • Er verkettet Zonen zu einem Zonen-Baum (Delegation).

    In jedem Zonenfile muss mindestens ein NS-RR vorhanden sein, der angibt, welcher Nameserver für diese Zone autoritativ ist.
    Ist zum Bsp. die Firewall selbst zuständig muss hier "localhost" ausgewählt/eingegeben werden.

    A Mit einem A-RR (A Resource Record) wird einem DNS-Namen eine IPv4-Adresse zugeordnet.
    AAAA Mit einem AAAA Resource Record („quad-A“) wird einem DNS-Namen eine IPv6-Adresse zugeordnet.
    Es handelt sich damit um die IPv6-Entsprechung zum A Resource Record.
    TXT Mit einem TXT Resource Record kann ein frei definierbarer Text in einer DNS-Zone abgelegt werden.
    TXT Records können unter anderem zum Tunneln über DNS eingesetzt werden.
    PTR PTR Resource Records ordnen im Domain Name System einer gegebenen IP-Adresse einen oder mehrere Hostname(n) zu. Sie stellen damit gewissermaßen das Gegenstück zur klassischen Zuordnung einer oder mehrerer IP-Adresse(n) zu einem gegebenen Hostname per A- oder AAAA Resource Record dar.

    PTR Resource Records sind ein zentrales Element des Reverse DNS. Sie werden üblicherweise ausschließlich verwendet

    • in der in-addr.arpa-Zone (für den Reverse-Lookup von IPv4-Adressen),
    • in der Zone ip6.arpa (für den Reverse-Lookup von IPv6-Adressen)[1] sowie
    • in anderen Zonen für Hostnames, auf die ein CNAME Resource Record aus einer der vorgenannten Zonen zeigt.
    MX Der MX Resource Record (MX-RR) einer Domain ist ein Eintrag im Domain Name System, der sich ausschließlich auf den Dienst E-Mail (SMTP) bezieht.

    Ein MX-Record sagt aus, unter welchem Fully Qualified Domain Name (FQDN) der Mail-Server zu einer Domäne oder Subdomäne erreichbar ist. Es ist üblich, für eine Domäne mehrere MX-Records zu definieren mit unterschiedlichen Prioritäten, so dass bei Ausfall eines Mail-Servers ein anderer die E-Mails entgegennehmen kann. Dies erhöht die Wahrscheinlichkeit, dass eine Mail trotzdem an die Empfängerdomain zugestellt werden kann.

    CNAME Ein CNAME Resource Record (CNAME RR) ist im Domain Name System dazu vorgesehen, einer Domänen einen weiteren Namen zuzuordnen. Die Abkürzung "CNAME" steht für canonical name (canonical = anerkannt, bezeichnet also den primären, quasi echten Namen).

    Im einfachsten Fall verweist der Name eines CNAME Resource Records auf den Namen eines A Resource Records und/oder eines AAAA Resource Records. Die Namen dieser Resource Records verweisen auf eine IP-Adresse. Beim Wechsel einer IP-Adresse muss dann für mehrere Namen nur ein einziger Resource Record geändert werden. Ein NS Resource Record, MX Resource Record oder PTR Resource Record darf nicht auf einen CNAME Resource Record verweisen. Umgekehrt darf ein PTR Resource Record aber durchaus nur über einen CNAME Resource Record zugänglich sein. Der Name eines CNAME Resource Records darf nicht als Name anderer Resource Records verwendet werden, da er stellvertretend für alle Resource Records des Ziels steht.

    Wert mail.anyideas.de. Die Domain, auf die die IP-Adresse zeigen soll
  • An die Domain wird ein Punkt "." gehängt (=Top-Level)
    • Speichern Schließt den Dialog für den DNS-Record
    Speichern Schließt den Dialog zum bearbeiten der Zone
    Das Anlegen des PTR-RR ist damit abgeschlossen und die Firewall setzt auf Anfrage die IP auf die gewünschte Domain um!
    Testen des angelegten PTR-RR unter: → Netzwerk →NetzwerkwerkzeugeReiter Host
    Einstellungen
    		PTR-testen.jpg
    Abfragetyp PTR Abfragetyp des Angelegten DNS-Records
    Hostname 192.168.222.60 IP-Adresse des gewünschten Servers
    Nameserver 127.0.0.1 Localhost-Adresse der UTM

    Antwort
    Im unteren Fenster wird, wenn alles richtig eingerichtet wurde, die IP-Adresse auf die korrekte Domain aufgelöst.

    Alternativ durch ein nslookup 192.168.222.60 von einem Rechner aus dem Netzwerk der UTM

    Relay-Zone

    Eine Relay-Zone ist für das Weiterleiten von Anfragen, die zu einer bestimmten Domain gehören zuständig.
    Anwendungsbeispiel:

    • Die Firewall wird im internen Netz von allen Clients als Nameserver verwendet
    • Zusätzlich ist im internen Netz ein Nameserver integriert der für die interne Domänenverwaltung (anyideas.local)zuständig ist
    • Möchte nun ein Client einen internen Namen auflösen (z.B.: uma.anyideas.local) wird diese DNS-Anfrage an die Firewall gestellt
    • Durch eine Weiterleitung aller Anfragen auf anyideas.local an den internen Nameserver können diese ohne Probleme von selbigem aufgelöst werden
  • Anfragen die nicht zur internen Domain gehören, löst die Firewall weiterhin selbst auf

    • Relay anlegen

    Zonenname anyideas.local Domain, die von einem internen DNS-Server verwaltet wird Datei:UTM v12.2.2 Nameserver Relayzone hinzufügen.png
    Typ Relay Zonentyp ist Relay
    Server
    Server hinzufügen
    IP-Adresse: 192.168.222.5 IP-Adresse des internen DNS-Servers
    ab v12.2.2 IPv6-Adressen in der Reley-Zone     		Datei:UTM v12.2.2 Nameserver Relayzone Server hinzufügen.png
    Port: 53Link= Default: 53 für DNS-Anfragen
    Speichern Speichert die Angaben und schließt den Dialog
    Das Anlegen der Relay-Zone ist damit abgeschlossen und die Firewall leitet alle Anfragen auf die Domain an den gewünschten Nameserver weiter! Datei:UTM v12.2.2 Nameserver Relayzone.png
    Nameserver mit Relay-Zonen für IPv4 und IPv6

    DNS Forwarding

    Ein DNS Forwarding wird dazu Verwendet um alle DNS Anfragen, die an den Nameserver der Firewall gestellt werden, an eine andere IP weiterzuleiten.

    DNS Forwarding anlegen

    Konfiguration unter → Anwendungen →NameserverReiter DNS Forwarding Schaltfläche Domainweiterleitung hinzufügen Datei:UTM v12.2.2 Nameserver DNS-Weiterleitung hinzufügen.png
    IP-Adresse: 192.168.222.5 IP-Adresse des DNS-Servers, der sämtliche DNS Anfragen beantworten soll
    Speichern Speichert die Angaben und schließt den Dialog
    Das DNS Forwarding ist nun angelegt und sämtliche DNS Anfragen werden an die gewünschte IP weitergeleitet. Datei:UTM v12.2.2 Nameserver DNS-Weiterleitung.png
    DNS Forwarding

    DNS-Server hinter IPSec-Tunnel

    Sollen DNS Anfragen an einen entfernten Nameserver weitergeleitet werden, der sich in einem Netz hinter einem IPSec-Tunnel befindet, sind besondere Konfigurationen vorzunehmen.

  • Hier ist zu beachten das standardmäßig alle direkten Anfragen, die sich an externe Nameserver richten, von der Firewall mit der externen (öffentlichen) IP aus geschickt werden.
    Eine öffentlich IP wird jedoch nicht in einen IPSec-Tunnel geroutet!
  • Prinzipiell ist diese Konfiguration auch für SSL-VPN-Verbindungen möglich. Hier gibt es aber auch eine einfachere Kommunikation ohne HideNAT
  • Diese Beschreibung gilt gleichermaßen für Relay-Zonen wie auch für DNS Forwarding
    • Übersicht:
    • Es wird ein Netzwerkobjekt für das Netz, in dem der DNS-Server steht erstellt
    • Eine Portfilterregel mit einem HideNAT bewirkt die DNS-Weiterleitung auch in den Tunnel

    Netzwerkobjekt hinzufügen

    → Firewall →PortfilterReiter Netzwerkobjekte mit der Schaltfläche Objekt hinzufügen

    Name vpn-Netzwerk-DNS-Server Name für das Netzwerkobjekt
    ggf. ssl-vpn-Netzwerk… oder ipsec-Netzwerk…     		Datei:UTM v12.2.2 Nameserver Netzwerkobjekt anlegen.png
    Dialog Netzwerkobjekt hinzufügen
    Typ: Netzwerk (Adresse)
  • Kein VPN-Netzwerk wählen, da sonst DNS-Anfragen nicht hierher geroutet werden!
    • Adresse 10.10.10.0/24 IP-Adresse des VPN-Netzwerkes, in dem der DNS-Server steht
    Zone: external Zone, über die auch der VPN-Tunnel erreicht wird

    Portfilter Regel anlegen

    Im letzten Schritt muss eine Firewallregel, mit einem Hide-NAT angelegt werden. Diese bewirkt das die DNS-Weiterleitung auch in den Tunnel, und nicht direkt in das Internet, geht.

    Portfilter Regel anlegen unter → Portfilter →PortfilterReiter Regelhinzufügen mit der Schaltfläche +

    		 Datei:UTM v12.2.2 Nameserver Portfilterregel-Hidenat.png
    Quelle
    		Interface.svg external interface Interface, hinter dem das VPN-Netzwerk erreichbar ist
    Ziel
    		Network.svg vpn-Netzwerk-DNS-Server Name des zuvor erstellen Netzwerkobjektes
    Dienst
    		Service-group.svg dns dns gibt die Dienste domain-tcp und domain-udp frei
  • Bei einer AD-Anbindung über IPSec sollte hier Service-group.svg windows-domain gewählt werden
    • [-] NAT
    Typ:
    		Hidenat Das HideNAT sorgt für die Übersetzung der IP-Adressen, die erst damit durch den Tunnel gehen
    [-] NAT
    Netzwerkobjekt
    		external-interface Netzwerkobjekt, hinter dem der VPN-Tunnel mit dem DNS-Server als Ziel erreichbar ist
    # Quelle Ziel Dienst NAT Aktion Aktiv
    Dragndrop.png 4 Interface.svg external-interface Network.svg vpn-Netzwerk-DNS-Server Service-group.svg dns HN Accept Ein
    Mit dieser Regel werden nun alle DNS-Anfragen die über die Firewall an den entfernten Nameserver gestellt werden, über die IP des internen Interfaces genattet und können somit in den VPN-Tunnel geleitet werden.

    DNS-Server hinter SSL-VPN-Tunnel

    Steht der DNS-Server hinter einem SSL-VPN-Tunnel gibt es breits eine Route dorthin.
    Hier reicht im Netz des DNS-Servers eine Regel, die dem Transfernetz des Tunnels Zugriff auf diesen Server erlaubt.

  • Gibt es mehrere SSL-VPN-Tunnel bzw. mehrere DNS-Server, muss dieses für alle Tunnel und alle DNS-Server konfiguriert werden

    • Netzwerkobjekt im Netz des DNS-Servers hinzufügen

    UTM | Netz des DNS-Servers Netzwerkobjekt im Netz des DNS-Servers hinzufügen

    → Firewall →PortfilterReiter Netzwerkobjekte mit der Schaltfläche Objekt hinzufügen

    Name ssl-vpn-transfernetz Name für das Netzwerkobjekt Datei:UTM v12.2.2 Nameserver SSL-VPN Netzwerkobjekt anlegen.png
    Netzwerkobjekt im Netz des DNS-Servers
    Typ: VPN-Netzwerk Typ des Transfernetzes ist VPN-Netzwerk
    Adresse 10.2.10.0/24 Netz IP des Transfernetzes
    Die DNS-Anfrage kommt von der UTM selbst, daher wird hierfür die Zunnel-IP der UTM verwendet. Streng genommen reicht es auch hier die Tunnel-IP der UTM anzugeben.
      
    Zone: ssl-vpn Zone, über die auch der SSL-VPN-Tunnel ankommt

    Portfilter Regel im Netz des DNS-Servers anlegen

    UTM | Netz des DNS-Servers Portfilter Regel im Netz des DNS-Servers anlegen
    Quelle
    		Vpn-network.svg vpn-network Netzwerkobjekt für das Transfernetz
    Ziel
    		Host.svg DNS-Server Der DNS-Server im Netz hinter dem Tunnel
    Dienst
    		Service-group.svg dns dns gibt die Dienste domain-tcp und domain-udp frei
    [+] NAT
    Typ:
    		None Kein NAT erforderlich
    # Quelle Ziel Dienst NAT Aktion Aktiv
    Dragndrop.png 5 Vpn-network.svg vpn-network Host.svg DNS-Server Service-group.svg dns Accept Ein
    Portfilter Regel im Netz des DNS-Servers 
    Mit dieser Regel werden DNS-Anfragen von Hosts aus dem Urspungsnetz von der dortigen UTM durch das Transfernetz des SSL-VPN-Tunnels auf den DNS-Server erlaubt
    Abgerufen von „https://wiki.securepoint.de/index.php?title=UTM/APP/Nameserver_v12.2.2&oldid=88754“