Sophos: Voip/SIP mit Telekom DeutschlandLAN

Sophos: Voip/SIP mit Telekom DeutschlandLAN

Bei einem DeutschlandLAN Anschluß wird SIP/VOIP über die bestehenden Internetleitung realisiert. In dem Beispiel habe ich einen DSL Anschluß welcher über eine Sophos UTM 9.5 realisiert wird und eine Avaya IP Office Anlage mit mehreren Telefongeräten. Die Telefonanlage hängt im lokalen Netz – man könnte auch die Telefonie trennen und auf ein eigenes Interface der Sophos legen oder ein eigenes VLAN verwenden, das war jedoch hier nicht gewünscht.

An der TAE Dose (kein NTBA oder Splitter dazwischen) hängt ein Telekom Speedport Entry 2 welcher ADSL und VDSL beherscht.

An dem Port LAN1 hängt ein LAN Kabel welches auf einen Netzwerk-Port der Sophos geht. Die PPPoE Einwahl läuft erfolgreich über diesen Port. Internet wird über diesen Anschluß realisiert.

Die Zugangsdaten wurden wie folgt eingerichtet:

Username: <Anschlusskennung><Onlinekennung><Mitbenutzer>@t-online.de
Kennwort: <Kennwort>

Bei VDSL bitte darauf achten, das bei der Sophos VDSL bei der PPPoE Einwahl erfolgt und auch VLAN7 getaggt ist. Sollte ein VDSL Modem mit integriert sein, bitte auch schauen ob diese ein VLAN Tagging benötigt.

Die DNS Server waren zuvor auf externe von Google eingestellt, diese habe ich jedoch auf die externen DNS Server welche bei der PPPoE Einwahl bereitgestellt werden (falls nicht automatisch, dann fest einstellen – Adressen können in dem PPPoE Log eingesehen werden). Dies wird benötigt, da die Services über DNS (z.B. _sip._regs.sip-trunk.telekom.de) aufgelöst werden müssen. Bei der Avaya IP Office kann man für die SIP Verbindung gar eigene DNS Server angeben – somit würde diese Anpassung nicht benötigt.

Eine Besonderheit, die ich habe in meinem Fall ist, das ich nicht über die ADSL Leitung rausgehe, sondern Parallel über eine weitere SDSL Leitung, damit jedoch die Telefonanlage auch die Leitung nutzt auf der das Voip läuft, habe ich eine neue Richtlinienroute erstellt (Schnittstellen & Routing > Statisches Routing > Richtlinien Routing > Neue Richtlinie) wie folgt:

Ob diese Regel funktioniert, testet man am besten an einem PC – wenn man die Seite wieistmeineip.de aufruft und die Regel aktiviert muss sich die IP über die man rausgeht ändern auf die Adresse der DeutschlandLAN Leitung.

Je nach Bandbreite sollte man auch noch ein QoS für SIP erstellen.

Dazu dann unter Schnittstellen & Routing > Status die Ports aktivieren und die richtigen Bandbreiten einstellen (in MBit). Dann unter Verkehrskennzeichner einen neuen Eintrag erstellen wie folgt (Adresse der Telefonanlage):

Und anschließend noch unter Bandbreiten Pools noch einen entsprechenden Bandbreitenpool anlegen wie folgt:

Wenn man dann in der Telefonanlage sieht, das sich die Anlage registriert die Rufnummer 0800 55 10033 anrufen, danach beginnt dann die Portierung.

Wird später komplett auf diese Leitung umgestellt sind weitere Anpassungen erforderlich:

  • Im Kundencenter feste IP aktivieren (evtl. übernehmen).
  • DNS Eintrag anpassen.
  • Ist DNS eingerichtet kann man nach kurzer Zeit auch im Kundencenter den DNS-Reverseeintrag einrichten.
  • Kontrollieren ob Name auch auf eventuelle Zeritifikat passt (z.B. bei Exchange Server).
  • Evtl. vorhandene Einträge im SPF für DNS Eintragen (siehe https://www.leibling.de/email-spf-erstellen/).
  • NAT und Firewallregeln anpassen.
  • Schnittstellenrouting entfernen.
  • QoS anpassen sofern eingerichtet.

Update:

In einem bestimmten Falle wurde die Leitung auch direkt von ADSL auf VDSL umgestellt. Es ist ein Speedport Entry 2 vor Ort eingesetzt – mit dem aktuellsten Firmwareupdate (zu finden unter https://www.telekom.de/hilfe/geraete-zubehoer/router/speedport-entry-2/firmware-zum-speedport-entry-2?samChecked=true) war dieses auch VDSL Kompatibel und konnte auf LAN2 im Modem Betrieb den Status ausgeben (http://169.254.2.1). Dort kann man dann die Verbindung einsehen:


Outlook 2016 kann sich nicht anmelden an Exchange

Ich habe einen Kunden der zwei Standorte hat. Der eine Standort hat Exchange 2010 und alle Rechner vor Ort sind noch mit Outlook 2010 eingerichtet. Diese hatten kein Problem auf den lokalen Exchange Server zuzugreifen, da diese durch das AD konfiguriert werden konnten und nicht über Autodiscover konfiguriert waren.

In dem anderen Standort war „nur“ ein Essentials Server, Exchange wurde über VPN im anderem Standort mitbenutzt. Die Clients hatten ebenfalls noch Outlook 2010 und wurden manuell einrichtet.

Nun kam jedoch ein neuer Client mit Office 2016 dazu im entferntem Stadndort und konnte wegen dem fehlenden Autodiscover nicht eingerichtet werden.

Da der Server jedoch noch Windows Server 2008 R2 war kam einrichten einer weitern Bindung im IIS für Autodiscover (mit SNI) nicht in betracht.

Ich habe dazu dann auf dem DNS im Netz mit dem Exchange eine neue Zone für die Emaildomain eingerichtet und dort einen Servicerecord für Autodiscover erstellt:

  • Start > ausführen > dnsmgmt.msc
  • Forward-lookup-Zone > Neue Zone erstellen (emaildomain)
  • Rechte Maustaste > weitere Einträge erstellen > Dienstidentifizierung (SRV) > Eintrag erstellen
  • Dienst: _autodiscover
  • Protokoll: _tcp
  • Port: 443
  • Host: URL des Exchangeserver

Dazu noch in dem anderen Netz im DNS eine bedingte Weiterleitung eingerichtet für die Emaildomain welche auf den DNS im Exchange Standort zeigt.

Hinweis:

Eine andere Alternative (welche ich jedoch nicht ausprobiert habe) wäre es, wenn man statt einem Servicerecord einen Alias erstellt mit namen autodiscover auf dem Exchange Server.

Sollte eine Anmeldung erfolgen, so bitte unbedingt als Anmeldenamen domain\user verwenden und nicht die Emailadresse.

Vergesst bitte nicht im DNS auch die anderen Adressen anzulegen welche im echten DNS sind (z.B. Exchange URL, www usw.).

Wenn eine Rückfrage kommt, ob die Weiterleitung erlaubt ist diese zulassen und denn Hacken machen bei nicht mehr Rückfragen. Dann erscheint die Rückfrage in Zukunft nicht mehr.


SBS 2011 Exchange, AD und DNS funktionieren nicht mehr, Fehler: Zugriff verweigert

Ich hatte dass Problem bei einem Kunden, das nach einem Neustart der Exchange Server nicht mehr startete.

Bei der Fehlersuche fand ich heraus, das das auch kein Zugriff auf DNS Management Konsole mehr möglich war, ich bekam die Fehlermeldung „Zugriff verweigert“ und in der Ereignissanzeige fand ich mehrere Meldungen, die Anmeldeprobleme bestätigten.

Weiterhin seltsam war, das der Server nicht mehr einem „Domänennetzwerk“ zugeordnet war, sondern nur noch einem Öffentlichen Netzwerk – man konnte zwar diesen in einem „Arbeitsplatznetzwerk“ zuordnen, jedoch nicht mehr einem Domänennetzwerk.

Neustarts halfen nichts und dauerten ewig (ca. 40 Minuten bis die GUI komplett geladen war).

Recherchen zeigten, das wohl intern die „interdomain trustrelationship“ beschädigt war.

Nach einem Neustart habe ich dann den folgende Befehlt eingeben:

nltest /sc_change_pwd:domainname.local

Als Antwort erhielt ich folgende Meldung:

Kennzeichen: 0
Verbindung Status = 0 0x0 NERR_Success
Der Befehl wurde ausgeführt.

Danach habe ich denn Server neugestartet und siehe da, wie von Zauberhand war das Problem behoben.

Der Server startete wieder schneller, Exchange funktionierte, der Zugriff auf die DNS Management Konsole war ohne Probleme möglich und in den Netzwerkeinstellungen war der Server wieder einem Domänennetzwerk zugeordnet.

Quelle: https://davidatkin.com/blog/server-2008-r2-sbs2011-dns-access-denied-network-unauthenticated/


Tipp: Kostenloser DynDNS Dienst in Deutschland für die Fritzbox

Die meisten DynDNS Anbieter sind mittlerweile kostenpflichtig oder haben Regeln, das man sich innerhalb von 30 Tagen anmelden muss, da sonst der Zugang verfällt.

Aus aktuellen Anlass habe ich gerade einen Anbieter gesucht, der folgende Punkte unterstützt:

  • Unterstützung für die Fritzbox
  • Kostenlos
  • Nicht alle 30 Tage anmelden
  • Sitz in Deutschland

Und siehe da, es gibt ihn tatsächlich: DNSHome.de

Hier gibt es die Information, wie man den Dienst mit der Fritzbox verwendet: https://www.dnshome.de/einrichtung.php


Exchange: Autodiscover-Umleitung

Versucht Outlook per HTTPS zu verbinden, nutzt es dazu Autodiscover. Hierbei kann es zu Fehlermeldungen kommen.

Damit dies nicht geschieht, kann man über DNS eine Umleitung einrichten.

Dazu erstellt man einen sogenannten SRV Eintrag im DNS.

Z.b. im lokalen Active Directory auf dem DC per Remote anmelden und dann wie folgt einrichten:

  • Start > ausführen > dnsmgmt.msc
  • Forward-lookup-Zone > AD auswählen
  • Rechte Maustaste > weitere Einträge erstellen > Dienstidentifizierung (SRV) > Eintrag erstellen
  • Dienst: _autodiscover
  • Protokoll: _tcp
  • Port: 443
  • Host: URL des Servers

Sobald Outlook die Umleitung bemerkt, fragt es nach ob man die Umleitung erlauben möchte – dies muss man natürlich Zulassen. Es empfiehlt sich hier auch einen Hacken zu setzen bei „Zukünftig nicht mehr zu dieser Website fragen„.

autodiscover