svengine

Am Besten die Received Lines in Header Zeile-für-Zeile vergleichen.

Hallo Ralph, Auf Anhieb bin ich jetzt auch überfragt. Nur weiss ich nicht warum in der NAT regel die Source auf die Interne IP addresse der Firewall genatted werden soll. Sollte die Source nicht "original" sein? Wenn es 10 minuten lang klappt und dann nichtmehr, dann höhrt sich das nach einem ARP PRoblem an. Schau einmal auf die ARP Einträge auf der PRO2040. Vielleicht klappt das aber auch mit statischen ARP Einträgen.

Hallo Ralph, also ganz kurz die neue konfiguration: - Wie ist die DMZ IP Adresse der Sonicwall? - Wie is die IP adresse der anderen Firewall? - Wie ist die IP adresse des PCs? - Wie ist die IP adresse der anderen firewall and der der PC angeschlossen ist? Frohes Neues übrigens noch.... Svensson

Ich glaube das klappt bei der Sonicwall nicht. Soweit ich weiss kann man den WAN Group VPN nur an eine Zone anbinden, nicht an eine IP addresse...

Hallo Flo, wenn nach fast 2 Tagen niemand antwortet, versuch ich es einfach einmal: Das Problem ist, daß die Sonicwall den Verkehr auf UDP 500,4500 abfängt, sobald die WAN Group VPN aktiviert ist. Daß heisst daß Du dann nichtmehr aussortieren kannst was in die DMZ soll und was von der Sonicwall bearbeitet werden muss. Ich sehe jetzt auf Anhieb nur zwei Lösungen (die zweite ist vielleicht ein bisschen abendteuerlich...) 1. Die WAN Group VPN auf der Sonicwall abschalten und allen UDP 500,4500 an den neuen VPN-Server in der DMZ durschschleusen. Somit werden dann ALLE VPN Verbindungen von diesem VPN Server bearbeitet. 2. Eine neue Zone auf der Sonicwall erstellen. Eine zweite WAN Verbindung bekommen und diese WAN Verbindung dann in diese neue Zone stellen. Die Sonicwall WAN Group VPN wird dann weiterhin die Anfragen auf die bisherige öffentliche IP-addresse bearbeiten ( Zone "WAN") und die Anfragen an die neue öffentliche IP addresse (Zone "Neu") können dann auf den zweiten VPN Server durchgeschleust werden. Viel Glück. Svensson

Ohje, keine Ahnung mehr wie das funktioniert. Ist einfach zulange her. Ich hoffe nur das ist keine SSL-VPN 200 weil die wars***ienlich nicht genügend resourcen hat.

Sonicwall SSL-VPN kann das auch. Die kann an dem Hostheader (URL) erkennen, an welche LAN IP addresse die Verbindung geroutet werden muß. Oder eben beide Webseiten auf demselben Server aufbauen...

Die Security types sind schon korrekt. Es gibt Untrusted, public und trusted. Die Default Firewall Regeln sind für Untrusted -> Public und Trusted, No traffic allowed Public -> Trusted, No traffic allowed Die Firewall Regeln für Trusted -> Public und Public -> Untrusted aber sind "All traffic allowed". Ich denke immernoch daß es an den NAT regeln gelegen hat.

Okay, den Wizard sollte man eigentlich NIE benutzen. dazu gibt eine Reihe von Gründen. Hauptsächlich daß der Wizard (denke ich) die Reihenfolge der Regeln nicht bestimmen kann. Ausserdem muss man sich mit den Nat-regeln früher oder später sowieso einmal auseinander setzen. Ich kann mir auf anhieb auch nicht erklären warum der Wizard drei regelen anlget, wenn streng genommen nur eine benötigt wird. Bei einer neuen Sonicwall (oder mit Grundeinstellungen) Gibt es immer eine Default-Natregel. Diese macht immer nur folgendes: Original Source: Any tranlated Source: Default WAN IP Address Original Destination: Any tranlated Destination: Original Original Service: Any tranlated Service: Original Diese Regel wird für jede Zone angelegt und erlaubt daß die IP Adresse von jedem DMZ- (oder LAN-) client auf die öffentliche IP addrese der Sonicwall genatted wird. Ansonsten kommt auch nichts von dem Internet Server zurück. Erstelle einfach einmal eine neue Zone "Test" (Network -> Zones) und schau Dir dann die Nat-regel an die für die "Test" -> "Wan" Zone erstellt wurde. Diese Regel fehlt Dir wars***einlich für "DMZ" -> "WAN", oder jemand hat daran herumgebastelt...

versuch einmal folgendes: Original Source: <DMZ PC Address object> tranlated Source: Default WAN IP Address Original Destination: Original tranlated Destination: Original Original Service: Any tranlated Service: Original Der rest sollte nicht geändert werden. Achte auch darauf daß die IP addresse des DMZ PCs korrekt unter "Network" -> "Address Objects" eingetragen ist. Diese Sollte ein Host in der DMZ sein. Eigentlich sollte die unterste NAT Regel (Default Rule) das abdecken, wenn diese Regel aber abgeändert worden ist dann kann das fehlschlagen. Wenn diese NAT Regel nichts hilt, kann der PC denn überhaupt die IP addresse der DMZ Interface anpingen? Sven

Hallo Ralph, eigentlich brauchst Du nur die Regel DMZ -> WAN, Ping erlauben (meistens ist das die "Default Rule" die schon im OS drin ist). Hat die DMZ private IP adressen oder öffentliche? Eventuell gibt es hier ein Routing Problem zwischen der DMZ und dem Internet. Schau einmal unter network -> Routing ob Dir hier etwas auffällt. Wenn nicht, mach einmal eine Packet capture mit TCP, ICMP. vielleicht wird das Paket gestoppt und Duch kannst auf der Sonicwall Website nachschauen was der "Drop Code" bedeutet. Weitere Möglichkeit ist daß die Private IP adrese des Servers nicht auf die öffentliche IP adresse der WAN Interface genattet wird, aber das sollte man auch in der packet capture sehen können. Viel Glück. Sven

Hallo Sven, kapier ich nicht ganz. Das Datum ist das Datum der emails? Und alle Emails auf dem Blackberry Smartphone haben dasselbe Datum (Einrichtungsdatum)? Ich nehem an das Datum der Emails in der Inbox des Benutzers ist korrekt, das Datum auf Dem Blackberry Server ist korrekt und das Datum auf dem Blackberry Smartphone ist ebenfalls korrekt? Besteht das Problem auch beim Email Versand? Gruß, Auch Sven....

Hallo Beisammen, ich wollte nur einen kurzen Beitrag zu diesem Problem schreiben. Wir koennen in den logs sehen dass email urspruenglich von einer oeffentlichen IP addresse die mit "205" endet verschickt wurde: 10:46:13 (out 68)>>> 250-mx.google.com at your service, [xxx.xxx.xxx.205] Wenn der NDR dann verchickt wurde hat die Email Security versucht diesen an dieselbe oeffentlichen IP addrese zu senden: 10:46:16 (out 66)connecting from sonicwall.xxx.xxx (0.0.0.0) to mail.xxx.xxx (xxx.xxx.xxx.205) Das heisst, die Sonicwall hat einen oeffentlichen DNS server abgefragt, der dann auch eine oeffentlich IP adrese weitergegeben hat. Wenn diese Verbindung dann vom LAN (oder DMZ) and die WAN IP-adresse geht, dann dreht die Firewall diese Verbindung ab. Die Loesung war also zicherzustellen dass die email Security einen DNS server hat der eine private IP adrese fuer mail.domain.xxx angibt. Das kann ein A eintrag und auch ein MX eintrag sein. Kann man uebrigens auch testen aus der Email Security commandline mit dem Dig-command. Dieses Problem tritt sehr haeufig mit Sonicwall email securitys auf, daher schreib ich einfach einmal diesen post. Sorry wegen den fehlenden Umlauten, ich hab leider nur ein englisches Keyboard. Mahlzeit.