Securepoint Support Forum

Hallo zusammen,

ich muß mich heute mit einem Problem an Euch wenden, da ich nunmehr nicht mehr weiterkomme...

Auf der Securepoint ist der Dyndns eingerichtet (bekommt auch die richtige IP, etc.). Wird nun der Domainname xxxxx.xxxdns.com eingegeben, so wird im internen Netz nichts erreicht (was ja auch so sein soll).

Die Aufgabe besteht darin, über den DynDNS Domain-Namen den internen Mailserver via HTTPS und SMTP zu erreichen. Dazu muss logischerweise eine Regel eingerichtet werden:

External_Interface -> Mailserver -> mail

wobei in der Dienstgruppe "mail" die Dienste HTTPS und SMTP enthalten sind.

Doch scheinbar klappt diese Regel nicht, denn Anfragen über den Domainnamen xxxxx.xxxdns.com laufen ins Leere.

Generelle Frage:

Wie muss eine Portweiterleitung vom externen Interface (dass mittels DynDNS auch erreichbar ist) auf einen internen Service aussehen???

Ich würde mich freuen, wenn mir hier jemand helfen könnte.

Viele Grüße
Michael

also deine regel die du da angelegt hast ist aber falsch ... die muss lauten
internet > mailserver > mail ...
schlie´ßlich greift ja das internet zu und nicht das externe interface der fw...
außerdem muss der mailserver in den netzwerkobjekten mit einer statischen nat angelegt sein (quasi mit eth0 wenn das dein externes interface ist)

für sowas müsste es aber im download bereich glaube auch ein howto geben, bin mir nicht ganz sicher

Ich habe die Regel inzwischen abgeändert:

Internet -> Mailserver -> mail,

wobei eine statische NAT auf pp0 angelegt wurde (pp0 entspricht ja dem eth0).

Wenn ich nun intern die DynDNS-Adresse eingebe, kommt die Meldung, dass der Host nicht erreichbar ist (111).

von Extern erreiche ich den Server erst recht nicht - wobei die Namensauflösung mittels DynDNS aber funktionert (richtige IP wird angezeigt).

mm also wenn du das objekt mit der statischen nat richtig angelegt hast müsstest du unter statischer nat dann eigentlich folgenden eintrag sehen:

Nat Objekt: mailserver (oder wie du den angelegt hast)
nat relation: ppp0
ziel: any
dienste: mail

wenn das drin ist sollte die portweiterleitung erstmal so stimmen .... gehts trotzdem nicht würd ich auf die regel erstmal das logging aktivieren und schauen ob die anfragen korrekt von der firewall weitergeleitet werden oder ob die geblockt werden.
eventuell fehlt dir auch ein hide-nat eintrag??? weiß ja nicht ob der mit am internen lan hängt oder in der dmz?
du müsstest dort quasi den eintrag haben:
nat objekt: intern-netz (und ein eintrag mit dmz-netz)
nat relation: ppp0
ziel: any
ausnehmen: nein

Hallo alle zusammen,

von Intern kann dieses DNAT nicht funktionieren da du ja von Intern kommst und mit der Anfrage auf das DynDNS aufs Externe interface zugreifen willst. Das kann NAT-Technisch nicht funktionieren. Von Intern musste für den Zugriff den Internen DNS Namen des Mailservers verwenden.

Von Extern ist relativ einfach zu beschreiben:
1. Du legst ein neues Netzwerkobjekt an, Name Mailserver-DNAT, IP Adresse des Mailservers, Statische NAT =ppp0 und ne tolle Gruppe dafür. Dann sollteste schon die meldung bekommen das die IP bereits vergeben ist. Ignoriere dies und weiter gehts
2. Dienst Gruppe mail existiert ja anscheinend bereits.
3. Regel hinzufügen die da heißt Internet->Mailserver-DNAT->Mail->Accept

4. Von Extern testen und berichten obs geklappt hat.
Ansonsten mal bitte nen Auszug aus dem Logging.

Grüße
A.Rietz

Hallo alle zusammen,

von Intern kann dieses DNAT nicht funktionieren da du ja von Intern kommst und mit der Anfrage auf das DynDNS aufs Externe interface zugreifen willst. Das kann NAT-Technisch nicht funktionieren. Von Intern musste für den Zugriff den Internen DNS Namen des Mailservers verwenden.

Von Extern ist relativ einfach zu beschreiben:
1. Du legst ein neues Netzwerkobjekt an, Name Mailserver-DNAT, IP Adresse des Mailservers, Statische NAT =ppp0 und ne tolle Gruppe dafür. Dann sollteste schon die meldung bekommen das die IP bereits vergeben ist. Ignoriere dies und weiter gehts
2. Dienst Gruppe mail existiert ja anscheinend bereits.
3. Regel hinzufügen die da heißt Internet->Mailserver-DNAT->Mail->Accept

4. Von Extern testen und berichten obs geklappt hat.
Ansonsten mal bitte nen Auszug aus dem Logging.

Grüße
A.Rietz

Hallo,

Habe alles kontrolliert, passt so (Ziel ist allerdings nicht "mail" sondern "SSL", da von extern über SSL zugegriffen werden soll).

Einstellungen:

Hide NAT

NAT-Objekt: Internal_Network
NAT Relationship: ppp0
Ziel: any
ausnehmen: nein

Statische NAT

NAT-Objekt: Exchange
NAT-Relation: ppp0
Ziel: any
Dienst: https

Portfilter

Internet -> Grp_Exchange -> SSL ; aktiv

Die Gruppe "SSL" beinhaltet den Dienst "https"

Es soll nun der Zugang über die gesicherte Verbindung über den Port 443 hergestellt werden, was allerdings nicht funktioniert (Zertifikate etc. auf dem Exchange sind korrekt eingerichtet; mit der Firewall-Lösung "IPCOP" funktioniert alles bestens).

Habe ich etwas übersehen?

Viele Grüße
Michael

Hallo,

schaue parallel dazu bitte einmal ins logging was dort dokumentiert wird.
Vielleicht hilft das schon bei der Lösung, ansonsten kann der SecurePoint Support bestimmt per Fernwartung dabei helfen.

Grüße
A. Rietz

Ich vermute, dass es mit dem DynDNS zusammenhängt, obwohl das externe Netzwerk aus dem Internet anpingbar ist - somit ist die DynDNS-Auflösung korrekt. Lediglich die Weiterleitung auf den Exchange-Server klappt nicht. Im Log wird die Anfrage scheinbar nicht geblockt...

Gruß
Michael

Also am DynDNS kanns eigentlich nicht liegen wenn alles korrekt eingerichtet ist. Habe es selbst täglich im Einsatz.

Wende dich bitte an den Support.
Das ist schneller als weiter rum zuraten

Grüße
A. Rietz

Hallo,

versuchen Sie mal bitte folgendes:

1. anmelden per ssh (putty) als root
2. auf der Rootkonsole folgendes Kommando eingeben:

tcpdump -i eth1 port 443 -nnp

3. Den Zugriff von aussen versuchen. Wenn aus der internen Schnittstelle Pakete in Richtung Webserver rausgehen, dann macht die FW ihren Job. Wenn auch Pakete zurückkommen, dann macht der Server auch seinen Job, zumindestens auf Verbindungsebene. Dann liegt der Fehler offensichtlich auf der Protokollebene, und man muss Client und Server mal auf die Finger klopfen ;-)

HTH

Hallo,

versuchen Sie mal bitte folgendes:

1. anmelden per ssh (putty) als root
2. auf der Rootkonsole folgendes Kommando eingeben:

tcpdump -i eth1 port 443 -nnp

3. Den Zugriff von aussen versuchen. Wenn aus der internen Schnittstelle Pakete in Richtung Webserver rausgehen, dann macht die FW ihren Job. Wenn auch Pakete zurückkommen, dann macht der Server auch seinen Job, zumindestens auf Verbindungsebene. Dann liegt der Fehler offensichtlich auf der Protokollebene, und man muss Client und Server mal auf die Finger klopfen ;-)

HTH

Hallo,

ich habe die Verbindung gemäß Dump überprüft:

Ergebnis: es kommt nichts rein! :shock:

Scheinbar kann das ppp0-Interface (eth0) die Anfrage aus dem Internet nicht entgegennehmen, was m.E. dann auf das DynDNS zurückzuführen ist. Aber die Adresse wird korrekt aufgelöst.

Nun bin ich absolut ratlos...

Gruß
Michael

Hier meine aktuellen Einstellungen:

Internal_Network -> Internet -> any
Internal_Network -> Internal_Interface -> Proxy_Services
Internet -> External_Interface -> mail
Exchange -> Internet -> mail
Internet -> Exchange_2 -> SSL
Internet -> Exchange_2 -> SMTP

für "Exchange_2" existiert jeweils eine statische NAT auf ppp0 (Ziel: any)

für "Internal_Network" existiert eine Hide-NAT auf ppp0 (Ziel: any)

Netzwerk:

ppp0: Interface eth1; Zone: external, firewall-external, vpn-ipsec
eth1: Zone: internal, firewall-internal

Das ist soweit alles...

Es funktioniert alles, bis auf den externen Zugriff über DynDNS, wobei - wie beschrieben - die Namensauflösung klappt.

Gruß
Michael

Michael_R hat geschrieben:
Ergebnis: es kommt nichts rein! :shock:

Nun ja, genaugenommen kommt nix raus, aber ich will ja nicht klugscheissen :-)

Wir sollten jetzt überprüfen ob denn auch was reingeht, und zwar so:

tcpdump -i ppp0 port 443 -nnp

Wenn jetzt nix reinkommt, dann ist die Firewall in soweit aussen vor, als dass sie keine Pakete wegschmeissen kann, die garnicht an der firewall ankommen. Wenn dem so ist dann könnte es tatsächlich so sein dass die Dyndns-Adresse nicht ordnungsgemäß aktualisiert wird. Das lässt sich einfach überprüfen, indem man die Appliance unter dem Dyndns-Namen pingt. Man kriegt zwar nichts zurück, aber das ist der einfachste Weg, an die IP zu kommen, die momentan hinter dem Hostnamen liegt.

Stimmt diese nicht, dann gibt es tatsächlich ein Problem mit Dyndns. Um das zu analysieren, schauen wir ins Livelog. Scheitert das Update des Clients, dann finden sich graue Einträge, die ungefähr folgendermaßen aussehen:

New IP: 80.12.45.111
Update failed

Dann sind entweder die Zugangsdaten nicht korrekt oder der Updateserver hat ein Problem.

Steht stattdessen nach einem Reconnect der DSL-Verbindung folgendes:

New IP: 80.12.45.111
Update successful

dann wird die IP-Änderung möglicherweise nicht von allen Nameservern korrekt übernommen. Da können wir aber auch nix für...

HTH

Andreas