Sonicwall - WAN-Subnetz Probleme

Ja, aber das du hast ja gar keine private IP in deinem Ping Pfad auf der Firewall ! Dein Firewall Design ist ja recht simpel und sollte dann immer so aussehen:


Wo muss man denn hier NAT machen ?? Nirgendwo....!!
Du solltest egal von woher aus dem Internet problemlos..

• Die WAN Port IP
• Die DMZ Port IP
• Einen Host im DMZ Segment

ohne irgendwelche NAT Regeln pingen können. Entsprechend passende ICMP Regel natürlich vorausgesetzt an der Firewall !
Wenn du den Reply direkt am WAN Port gesniffert hast, dann sendet deine Firewall den ICMP Echo ja de facto ab Richtung Provider bzw. Internet.
Dann liegt es auch nicht mehr an deiner Firewall sondern wird irgendwo dazwischen gefiltert.
Entweder am Inbound Provider der Firewall oder da wo der Ping Client ist. Da sist auch klar.

Was hast Du dem SW-Support an Daten übergeben und was war die genaue Auskunft?

Hast du testweise Mal ein anderes Gerät außer die Sonicwall dran gehangen?

Wie ist die globale Konfig der Routen der Sonicwall?

Hi,
Wie @aqui auch schon versucht hat dir zu erklären:
Du brauchst kein NAT oder auch kein Port forwarding oder was auch immer !
Du brauchst ein simples Routing auf der Sonicwall.

CH

@ChriBo: Das war auch einer meiner Gedanken. Bzw kann es sein dass eine globale Einstellung bezüglich der Routen hier schon "wirkt".

Sinnfreie und überflüssige Frage, denn in der Firewall gibt es lediglich eine einzige Route und das ist die Default Route auf den Provider 222.222.222.23 !
Sorry, und nochmals: Das Problem existiert doch überhaupt nicht in einem richtigen Design mit deinen Vorgaben !! Port Weiterleitungen sind in deinem Setup doch Blödsinn und gibt es gar nicht wenn es dir nur um dein eigenes öffentliches IP Segment geht. In der deiner Beschreibung redest du mit keinem Wort von irgendwelchen RFC 1918 Netzen hinter einer NAT Firewall. Was gilt denn nun ?? Verwirrung komplett...

Entweder hast du dir die Zeichnung oben nicht richtig angesehen oder ein falsches Design. In deinem Testszenario kommt niemals ein RFC1918 IP Netz vor wenn es dir lediglich darum geht Endgeräte IPs in deinem eigenen öffentlichen Subnetz von außen zu erreichen ! Wo sind da (bezogen auf deinen ICMP Test) RFC 1918 IP Netze oder irgendwelches Port Forwarding ?? Nirgendwo und ist auch nirgendwo erforderlich ! Kein NAT = kein Port Forwarding !
Oder wir haben dich hier alle irgendwie missverstanden oder...du hast es falsch geschildert was du eigentlich genau willst ?! Kollege @ChriBo hat es ja auch schon mehrfach gesagt.

OK, dann gilt das Beschriebene für das lokale LAN in der o.a. Zeichnung, richtig ?
Nur was dann völlig unverständlich ist ist die Tatsache WO dann dein dir zugewiesenes öffentliches Subnetz liegt ??
Wenn du für deine eigenen 85.22er IP Adressen KEIN eigenes Segment vorgesehen hast musst du mit dieser etwas unsauberen Methode des ARP Spoofing arbeiten wie es im Sonicwall KB beschrieben ist, das ist zwar IP Design technisch unschön ala quick and dirty aber wenn du nichts umstellen willst der Weg den du gehen musst. Die Frage ist wie die Firewall Regel technisch diese IPs handhabt ? Vermutlich aber wie Secondary IP Adressen auf dem WAN Port, so das das WAN Port Regelwerk hier gilt.

Du willst doch etwa NICHT wirklich Endgeräte mit einer RFC 1918 IP Adresse im lokalen geNATeten Netz von außen (Internet) pingbar machen, oder ?

@aqui: Woher weißt Du denn, dass es lediglich eine einzige Route gibt und wir diese aussieht?
Und warum bist Du der Meinung, dass diese essentielle Frage überflüssig und unwichtig ist, wenn Du selbst keine nennenswertes Know-How im Umgang mit Sonicwall hast, um es nett zu formulieren?

Oha,

mach es doch "einfacher":
besorge dir einen echten Router (Cisco / Mikrotik oä.).
Gib dem Router die WAN IP 222.222.222.23/29 mit GW 222.222.222.17 auf der externen Seite.
Auf der internen Seite z.B. 85.22.65.41/29 deine Sonicwall bekommt dann z.B. die 85.22.65.46/29 mit GW 85.22.65.4. Dann kannst du einfach mit PAT und NAT auf der Sonicwall arbeiten.
Kein PAT oder NAT auf dem vorgeschaltetem Router !

CH

Das weiss man doch sicher durch die IP Design Beschreibung des TOs. Wo sind denn dort IP Netze die NICHT lokal an der Firewall liegen und ggf. Routen erfordern würden ?? Nirgendwo !
Folglich gibts dann logischerweise nur eine einzige Default Route ! Alle Netze sind ja direkt an der Firewall verbunden die "kennt" die FW also immer selber also auch ohne Routen.

@Knorkator
Ja aber dann ist dein Design doch falsch. Kollege @ChriBo hat es ja auch schon gesagt.
Deine Server gehören dann in ein separates Segment an der FW. Das würde auch diese gruselige Frickelei mit dem NAT Forwarding obsolet machen und wäre kinderleicht mit dem Setzen einer neuen IP auf dem Server in 5 Minuten erledigt.

So oder so auch wenn du es mit deiner Quick and Dirty Methode machst siehst du ja das die ICMP Pings richtig aus der Firewall in Richtung Provider bzw. Internet gehen. Alles gut also wenn dieser Packet Trace wirklich direkt vom WAN Port kommt wie du ja versicherst.
Letztlich liegt es dann NICHT mehr an deinem Firewall Setup selber !

Er hat kein Wort zu dem Thema verloren oder den Nachweis dazu erbracht, aber man weiß es?

Ich wäre mit solchen Äußerungen besonders dann vorsichtig, wenn man nicht weiß wie eine Sonicwall im besonderen sich verhält.

Wir wissen nicht was der Support an Input bekommen hat, noch wissen wir welche Firmware um Einsatz ist. Zwischen Sonic OS 5.x und 6.x hat sich speziell zu diesem Thema einiges geändert. Der "andere" Weg von 2013 erwähnt ebenfalls nicht die Firmwareversion.

Das muss er ja auch nicht. Wenn wir jedem Fragesteller hier unterstellen das seine Netzwerk Schilderung per se falsch oder unvollständig ist und er noch 10 andere IP Netze mit einem nicht beschrieben Router irgendwo an der FW angebunden hat müsste man ja niemals mehr auf solche Threads antworten da das dann im Chaos enden würde.
Glauben wir also dem TO mal das er das alles sachlich richtig geschildert hat und es eben ein solches Banalszenario ist was KEINE statischen Routen sondern rein nur die Default Route erfordert.
Zurück zum Thema...

Auch zu behaupten, dass es was im Design falsch ist, ohne Kenntnis über das Zoning der SW zu haben ist methodisch falsch. Bzw. unterstreicht nicht zu wissen, wie das Konzept des SonicOS ist.

Die Sonicwall bietet alle nötigen Werkzeuge um diesen Standardfall zu diagnostizieren.

Ich wiederhole mich. Du hast Null Ahnung von Sonicwall.
Die Frage ist (eine) Standardfrage bezüglich des Falles, die auch der Support als erstes prüft.

Nee, nee alles gut. Der Professor hat nur gerade ne Blockade weil er seinen HW Liebling angekratzt sieht. Daran erkennt man aber auch das er das Problem nicht verstanden hat, denn es geht NICHT um das Produkt oder Zoning oder wasauchimmer, sondern rein allein um das IP Netzwerk Design. Aber egal, zu dem Thema ist ja nun abschliessend alles gesagt...
OK, bestätigt dann das es de facto NICHT an deiner Firewall liegt, denn der Wireshark Trace zeigt ja dann an der Stelle eindeutig das das Echo Reply Paket sauber aus dem WAN Port Richtung Provider geht. Und das auch mit den richtigen IP Adressen.
Fazit:
Entweder der Provider oder das Segment wo der Client ist filtert ICMP Echo Pakete.

Hi Knorkator.
Schalte bitte einen Router zwischen deine Sonicwall und den Switch von Dokom21 (der Cisco2960).
Wie habe ich in einem anderen Post geschrieben.
das es nur mit der Sonicwall geht wage ich zu bezweifeln.

Doch, geht natürlich auch so mit der Sonicwall wenn er es so löst wie in der Zeichnung oben mit einem freien LAN Port bzw. separatem Segment.
Das hätte den großen Vorteil das die öffentlich erreichbaren Server auch in einem sicher abgetrennten und dedizierten IP Segment liegen das mit einem wasserdichten FW Regelwerk kontrolliert werden kann.
Fehlt ein Hardware Port macht man es mit einem VLAN Port. Letztlich egal, Hauptsache das Server Netz mit den öffi IPs ist abgetrennt.
Das derzeitige Design das man per ARP Spoofing am WAN und Port Forwarding klassische Ports wie Mail oder anderes in ein lokales RFC 1918 LAN leitet ist Sicherheits technisch gesehen eigentlich eine Todsünde und ein NoGo vom Design her. Von der Nutzung dieser Secindary Aliase auf dem gleichen IP Segment wie der Provider Router mal erst gar nicht zu reden.
Solche wellknown Ports sind permanent in Scan Attacken und anderen Angriffen die im Sekundentakt am WAN anliegen enthalten. Das ungeschützt in ein internes LAN mit anderen Rechnern forzuwarden spricht nicht gerade für ein intelligentes Security Konzept. Quick and Dirty Lösungen als Workaround für einfache Design Fehler sollten im Firewall Umfeld immer Tabu sein. Sollten.... Aber muss jeder letztlich selber entscheiden was er da macht und welches Risiko er bereit ist zu akzeptieren.
Ein Systemhaus was sowas "verbricht" sollte man dann besser niemals mehr an hausinterne IT lassen...
Aber das ist dann wieder ein ganz anderes Thema.

Professional bitteschön.

Ich Frage ab, was der Support abfragen würde.
Es ist nämlich erst Mal sicherzustellen, dass X6 nicht zufällig für diese Route benutzt wird. Das hat einen Grund.

Auch ist es Quark zu erzählen, dass das Design falsch ist oder unsicher oder quick ans dirty. Besonderes dann wenn man traurige Berühmtheit erlangt hat im beleidigen von Hilfesuchenden, wenn sie nicht den persönlich präferierten weg oder Hersteller wählen.

Natürlich kann man dann noch vollends als Spinner rüberkommen, wenn man seine eigene "Ratschläge" weder befolgt noch kennt.

Zitat: "Das muss er ja auch nicht. Wenn wir jedem Fragesteller hier unterstellen das seine Netzwerk Schilderung per se falsch oder unvollständig ist und er noch 10 andere IP Netze mit einem nicht beschrieben Router irgendwo an der FW angebunden hat müsste man ja niemals mehr auf solche Threads antworten da das dann im Chaos enden würde."

Eigentlich müsstest du ihm jetzt deine Standardleier erklären.

Wenn du jedoch Ahnung hättest von den Sonicwalls, dann würdest du großes Interesse daran haben diese Sachen zu wissen wenn das WAN nicht über X1 läuft.
Derjenige der das WAN nicht über X1 erreichbar gemacht hat, muss die gesamte Sonicwall daraufhin reinpassen mit all ihren Standardconfigs. Und Routing und NAT sind bei der Sonicwall getrennt und generieren für Konfigs die nicht unbedingt offensichtlich sind, wenn man nicht gesteigertes know how hat.

So so...du findest 2 IP Netze auf einem physischen Draht also ein normales Design ? Nur nebenbei: Der TCP/IP Standard sieht sowas nicht vor. Allein das ICMP Handling ist damit undefiniert und funktioniert nur mit der Primär Adressierung also dem Provider Netz. Nur einer von vielen Gründen warum das unsauber ist. Quark ist also de facto eine Sache, IP KnowHow etwas anderes...
Wie gesagt es ist alles zu dem Thema gesagt und es geht NICHT um das Produkt als solches sondern, um es nochmals zu wiederholen, ums IP Design an sich das eben nicht Protokoll konform ist. Solche Standards kennst du auch ganz sicher selber als Netzwerk Professional.
Es hat auch, wie bereits mehrfach gesagt, rein gar nichts mit Sonicwall Know How zu tun oder anderem dedizierten Produkt KnowHow. Es geht ums IP Knowhow an sich.
Natürlich ist sowas mehr oder minder mit allen Firewalls hinzubekommen nicht nur der Sonicwall. Es ist und bleibt aber IP technisch unsauber, egal ob man eine Sonicwall hat oder eine Cisco Firepower oder was auch immer.
Und in dem vom TO beschriebenen, einfachen Design reicht eine simple Default Route über den einzigen WAN Port. Da "versteckte" Routing Fehler zu konstruieren oder weitere fiktive WAN Ports und zu unterstellen ist in diesem Kontext einfach absurd. Aber egal...
Wir sollten den Thread des TO hier nicht durch sachfremde Themen kapern !

Das Thema hatten wir dich zur Unterhaltung vieler Teilnehmer schon.

Wie heißt denn dieser TCP/IP Standard und wenn Du schon dabei bist, dann kannst du auch alle anderen Fragen bezüglich so Sachen wie "Guidelines" und "Standards" benennen. Da warten wir schon lange darauf.

Es wurden auch keine Routing Fehler konstruiert, sondern es sollte geklärt werden warum von Routing gesprochen wurde und auf X6 ein NAT arbeiten soll.
Wenn man SonicOS kennt, dann weiß man, dass die Wahl des Interfaces kein Zufall ist und es dafür sogar eine explizite Diagnose-Option gibt. Außerdem behandelt die Sonicwall die NAT Regeln unabhängig vom Routing, sie werden separat gepflegt und erzeugen unzählige Zusatzkonfiguration, die nicht in jeder Ansicht angezeigt werden. Außerdem ist das Zoning im Zusammenhang mit NAT ein Stolperstein und eventuell angelegte Objekte und deren Verschachtelung ist wichtig zu wissen.

Allein der Umstand, dass nicht X1 samt möglicher Subinterfaces für das WAN genutzt wird, heißt, dass jemand die gesamte Grundkonfiguration umgebaut hat. Wer sowas beherrscht, nimmt das NAT in Minuten in Betrieb und weiß auch die Ursache für die Thematik in Kürze zu ermitteln, weil die Sonicwall ein vollumfängliches Featureset dazu hat. Mit Traffic-Mirrorung im WAN, kann eigentlich nichts mehr schief gehen.

Noch Mal, falls es nicht ankam, SonicOS pflegt Routing und NAT getrennt und nicht zwangsläufig hat eine Routing oder Nat-Einstellung eine Auswirkung auf den anderen Typ, kann es aber haben. Dazu erfragt man das globale Routing und die NAT policies, Routing policies und Objects samt deren Verschachtelung. Dann hat die Firmware und auch Firewall noch einen Einfluss auf dieses Verhalten.

Also kläre uns auf, warum grundsätzlich supporte Konfigurationen nicht irgendwelchen Standards entsprechen und vor allem die diese Standards heißen.
Und denke Mal drüber nach, warum der Support nicht sonst gesagt hätte, es ist eine nichtunterstützte Konfigurationen. Nein sie sagten, die Konfig sollte funktionieren. Das heißt, dass dem Support zumindest diese Information bekannt waren.

Und wenn ich das machen würde, was du mir vorhälst lustigerweise aber deine Masche idt, dann hätte ich dem TO erklärt das seine Hardware Kacke ist, sein Design gruselig und ihm meine präferierte Lösung vorgeschlagen.

Dabei wäre die Frage nach einer anderen Konfigurationen, gerade weil er ein Subnetz hat angebracht, dennoch nicht gefragt.

Also?

@Knorkator: Gucke dir Mal die Tabelle "Comparison of L2 Bridge Mode to Transparent Mode" an ob du alle diese Hinweise richtig umgesetzt hast nun Bezug auf das NAT. Das kann dir mindestens die Suppe versalzen.

http://help.sonicwall.com/help/sw/eng/8620/25/9/0/content/Ch27_Network_ ...

Auch solltest Du dir die Frage stellen ob nicht ein der beide fort verglichenen Verfahren für dich das optimale wäre. Zumindest könntest du dir alle Besonderheiten des NAT von Hals schaffen und hast nicht weniger Sicherheit.

@aqui: Überprüfe mal deinen Standardsschmarn mit den zwei Netzen auf dem physischen Interface, NUR mit dem, was für diese in den Link genannten Modis diesbezüglich geschrieben steht. Sonicwall erwähnt dort auch, dass Nat eine andere Baustelle ist.
Bestimmt wegen der Standards und dem Design?
🤦

Im Grunde hat die Dokom sich hier das Leben selber schwer gemacht. Es ist völlig unverständlich warum sie dir dein 85.22.65.40/29 nicht auf den Switch gelegt haben so wie es eigentlich generell üblich ist und wonach ihre Installation ja auch aussieht...?!
Das solltest du sie auch einmal fragen, denn es ist ja völlig unverständlich warum man jetzt nur für das Netz noch einen einsamen Router da als Durchlauferhitzer hinstellen muss zumal ihrer ja schon vor Ort ist.