DynDNS will nicht funktionieren

normatel

Lt. Commander
Dabei seit
Okt. 2006
Beiträge
1.336
Problem: DynDNS - Sonicwall TZ210 - Terminal Server 2008

Hallo zusammen,

vielleicht hat einer von euch noch eine Idee, mir fällt nichts mehr ein.

Ich habe hier einen Terminal Server am laufen (2008er), soweit alles eingerichtet und aus dem internen Netz auch alles OK.
Nun habe ich mir ein schickes DynDNS Konto eingerichtet, meine WAN IP eingetragen (ich habe 2, eine davon genommen) und mal alle Optionen bei DynDNS aktiviert.
Sehr schön, scheint funktioniert zu haben, nun arbeite ich auf einer Sonicwall TZ210, dort habe ich mein DynDNS eingetragen (On-line: IP-ADRESS as of 04/12/2011 17:14:36).
Nun in der Firewall noch ein Objekt anlegen das den Terminalserver ausgibt mit der IP Adresse (statisch) und dann eine Rolle hinzugefügt: WAN to LAN, Destination ist mein Terminal, Ports sind 3389 TCP und UDP, von Source Any.

Sooo, nun sollte eine Remote Verbindung von extern ja auf meine Adresse.dyndns-remote.com möglich sein, geht aber nicht, es will einfach nicht gehen.

Aktiviere ich den Ping auf meiner Leitung kann ich die Adresse auch Pingen.

Grüße
 
Zuletzt bearbeitet:
I

impressive

Gast
"Aktiviere ich den Ping auf meiner Leitung kann ich die Adresse auch Pingen."

womit bestätigt ist das dyndns funktioniert. dein problem liegt woanders ;)
 

normatel

Lt. Commander
Ersteller dieses Themas
Dabei seit
Okt. 2006
Beiträge
1.336
Richtig, der Titel ist etwas schlecht gewählt, wie ich auch schon schrieb, weiß ich nicht mehr wo ich suchen soll. Keine Idee?

Habe den Titel mal geändert :)
 

Visceroid

Rear Admiral
Dabei seit
Mai 2010
Beiträge
5.135
Also ich habe nur den Port 3389 TCP auf meiner Hardware u. Softwarefirewall durch geschalten und alles funktioniert.
 

normatel

Lt. Commander
Ersteller dieses Themas
Dabei seit
Okt. 2006
Beiträge
1.336
@Visceroid: Diese Erkenntnis hilft mir nur leider nicht weiter :D

Eine Firewall auf dem Terminal selbst läuft nicht!
 

LinuXfr3ak

Ensign
Dabei seit
Nov. 2010
Beiträge
241
Testest du das ganze von deinem eigenen Netzwerk aus oder von einem anderen? Viele Router können kein Loopback - sprich nicht vom eigenen LAN auf das WAN Interface zugreifen! WEnn ja - teste es mal über ein anderes Netz/Mobiles Internet etc. Ansonsten liegt das Problem wohl an den Portforwarding einstellungen des Routers
 

normatel

Lt. Commander
Ersteller dieses Themas
Dabei seit
Okt. 2006
Beiträge
1.336
Nein, ich teste es aus einem externen Netz, wie ich schon oben schrieb:

Sooo, nun sollte eine Remote Verbindung von extern ja auf meine Adresse.dyndns-remote.com möglich sein, geht aber nicht, es will einfach nicht gehen.
Viel Einstellungen gibt es aber nicht, ich kann die eine Access Rule erstellen welche steht. :/
 

Visceroid

Rear Admiral
Dabei seit
Mai 2010
Beiträge
5.135
@normatel: Sorry sollte eigentlich nur Aussagen das du dir das UDP forwarding überhaupt sparen kannst. Wird zwar an der Problematik nichts ändern, aber unsinnige forwards bringen auch nichts ausser Sicherheitsrisiken.

Auch wenn du schreibst eine Firewall am Terminal läuft nicht, kann sein das die Windows Firewall aktiv ist?
 

DonConto

Lt. Commander
Dabei seit
Juli 2004
Beiträge
1.746
Hast du mal kontrolliert, ob der Ping wirklich an deine gerade aktive IP Adresse geht? Läuft der Rückweg (also vom Terminal Server zu deinem Testgerät) auch über diese WAN IP?
 

normatel

Lt. Commander
Ersteller dieses Themas
Dabei seit
Okt. 2006
Beiträge
1.336
@Visceroid: Da gebe ich dir recht, da ich aber zum testen nur die "Terminal Services"-Gruppe hinzugefügt habe, war der UDP auch dabei, dass ist der Grund :)

@Don: Der Ping geht an die richtige, ich bekomme auch einen Ping reply von meiner WAN IP die ich eingetragen habe, dass muss auch gehen, da der Ping sonst gar nicht gehen würde, da nur WAN2 einen Ping erlaubt, WAN1 aber nicht.

Kann das Ergebnis leider nicht posten da ich es übers iPhone teste, wäre jetzt umständlich.

Achja, ich sage euch gern die Adresse, dass sind eh nur Tests und ihr könnt nichts kaputt machen: ips.dyndns-remote.com ... testet selbst und ihr werdet sehen was ich meine :)
 

DonConto

Lt. Commander
Dabei seit
Juli 2004
Beiträge
1.746
Kannst du versichern, dass Hin- und Rückweg der Datenpakte über das gleiche WAN Interface gehen?
 

normatel

Lt. Commander
Ersteller dieses Themas
Dabei seit
Okt. 2006
Beiträge
1.336
Also ich per iPhone jetzt nicht weiß wie, kann ich es dir nicht 100%ig sagen, aber auch das deaktivieren von WAN1 hilft mir nicht, dazu habe ich noch eingestellt bei der DynDNS Config auf der Sonicwall: Bound to: X2 (WAN2). ... so ein Rotz echt :)
 

Visceroid

Rear Admiral
Dabei seit
Mai 2010
Beiträge
5.135
@normatel: Deine URL (ips.dyndns-remote.com) löst zu 188.111.85.155 auf.
Ein tracert zeigt als letzten Hop: business-188-111-085-155.static.arcor-ip.net

Da steht business static :p wofür brauchst du dann überhaupt dyndns? :)

Aber zum Problem: Ist die von mir gepostete IP die richtige, zum passend Wan Port gehörende?
Tracert/Ping geht durch, RDP sagt das nix läuft.

Weiters ist lt. schnellem Portscan von den Standardports nur der 80er offen/beantwortet.

Du könntest mal probieren irgend einen Server am Terminal auf zu machen (FTP z.B.) um zu sehen ob ein anderes forwarding den Effekt bringt den es sollte.
 

normatel

Lt. Commander
Ersteller dieses Themas
Dabei seit
Okt. 2006
Beiträge
1.336
Also das mit DynDNS sind nur paar Tests, ich brauche es nicht, Grund hierfür sind eigentlich Zweigstellen die es später wohl nutzen müssen, ich selbst brauche es später natürlich nicht.

Die IP passt zum WAN Port, richtig.

Dann scheint wohl wirklich was an meiner Regel nicht zu stimmen, aber mehr kann ich nicht einstellen:
FROM WAN TO LAN
source: WAN2_188.111.85.155
destination: IPS_Lindau-LAN-Host-SRVterm
service: Terminal Services
allow

Hinter destination steckt die client ip.
und hinter dem service die ports

Du könntest mal probieren irgend einen Server am Terminal auf zu machen (FTP z.B.) um zu sehen ob ein anderes forwarding den Effekt bringt den es sollte.
Keine andere Möglichkeit :D ?
 
Zuletzt bearbeitet:

Visceroid

Rear Admiral
Dabei seit
Mai 2010
Beiträge
5.135
Die aufgelöste IP der Destination IPS_Lindau-LAN-Host-SRVterm und die Ports im Service sind richtig hinterlegt? Beim Service hast du ja geschrieben das es passen soll.. wie gesagt: 3389 TCP sollte reichen, tuts bei mir halt. Portforwarding.com empfiehlt auch 3389 UDP aufzumachen. Sollte aber auch so funktionieren.

Deine HW-Firewall gibt es dort leider nicht, ein kleineres Modell TZ-170 hat auch keine Besonderheiten bei der Einrichtung der Freigabe.
Im Zweifelsfall probier mal das forwarding händisch, also nicht über den vordefinierten Service zu machen. Vielleicht hakt es ja daran?
 

normatel

Lt. Commander
Ersteller dieses Themas
Dabei seit
Okt. 2006
Beiträge
1.336
Die Destination ist die IP des Terminalservers, ich kann in der Sonicwall leider nur Objekte erstellen und diese als Destination wählen, ich kann dort keine händische IP eintragen. Mehr sollte es dann aber auch nicht sein, daher wundert es mich auch.
 

Visceroid

Rear Admiral
Dabei seit
Mai 2010
Beiträge
5.135
Wenn dem so ist wirds wohl auch funktionieren :)

Also nach all der Abklärung bleibt bei mir auch nur "keine Ahnung" über.
Ich selbst habe keine Sonicwall, also kann ich außer den Grundsatzfragen leider nicht viel machen :(
Gibts von der Sonicwall keinen Support wo man fragen kann (Forum/Hotline?)
 

normatel

Lt. Commander
Ersteller dieses Themas
Dabei seit
Okt. 2006
Beiträge
1.336
Was er mir ständig dropped ist Port 546 und 547:

PORT 546 – Information

Port Number: 546
TCP / UDP: UDP
Delivery: No
Protocol / Name: dhcpv6-client
Port Description: DHCPv6 Client


Habe das Problem anderweitig gelöst, ist aber eine ganz andere Vorgehensweise die hier eigentlich nicht mehr rein passt.
 
Zuletzt bearbeitet:
Top