Hallo,

ich habe jetzt schon mehrfach folgendes Szenario gehabt (Securepoint 2007)
- Ich habe im lokalen Netz einen Dienst laufen, der von extern erreichbar ist, z.B. einen Webserver
- Von extern verwende ich keinen DNS-Eintrag, sondern die feste IP des Netzes.
- Der statische NAT-Eintrag sowie die Firewall Regeln sind richtig konfiguriert. Der Zugriff von extern auf diese IP führt zu einer Weiterleitung auf den angegebenen Host und der Webserver ist erreichbar.

Aus dem internen Netz habe Zugriff auf den Server über die lokale IP.
Wenn ich aber versuche über die externe IP auf den Server zuzugreifen, erkennt die Firewall wohl nicht, dass Sie mich auf den Server weiterleiten muss.

Gibt es da eine Möglichkeit das trotzdem zu erreichen?
Ich habe schon eine static NAT Regel erstellt mit NAT Relation=eth1 (lokales Netz) und eine Firewall Regel [Internet NET -> External Interface -> HTTP-HTTPS -> ACCEPT] erstellt, so dass die Pakete nicht mehr gedroppt werden.


Ich weiß nicht, ob dieses Szenario durch die Protokoll-Standards für Routing etc. abgedeckt ist. Ich weiß nur, dass mit dem "Home"-Routern (z.B. DLink oder fritz.box) ohne was einzustellen der Zugriff auch von intern möglich ist.



Gruß

Jürgen

Hallo,

hierzu muss das SNAT-Objekt nochmal mit seiner öffentlichen IP in der Zone firewall-internal angelegt werden:
Name: SNAT-Objekt
IP: X.X.X.X (öffentliche IP)
Maske: 32
Zone: firewall-internal
SNAT: leer
Gruppe: Grp-SNAT-Objekt

Danach müssen die entsprechenden Regeln erstellt werden:
internes Netz -> Grp-SNAT-Objekt -> http -> ACCEPT

Es antwortet aus dem internen Netz nicht das eth0, sondern eth1.

Gruß,
Rolf Gerold

Guten Tag,
ich copy'n'paste einfach mal meinen Beitrag aus dem TERRA-Forum:
https://www.terra-firewall.com/forum/topic.php?post=354#post354

Quote

der Kernel ist in dem Fall (das ist nicht böse gemeint) schlauer als Sie und routet das Paket direkt ins interne Netz zurück, ohne vorher ein SNAT auf die öffentliche IP durchzuführen. Das Rückpaket nimmt dann den direkten Weg zum Client mittels ARP-Request, was diesen Rechner ziemlich zum Grübeln bringen dürfte, da die Anfrage ja an eine andere IP ging.
Soviel Geschwafel zum Problem, kommen wir jetzt zur Lösung:

Binden Sie auf das interne Interface eine Dummy-IP (z.B. 172.16.0.1/32). Diese IP darf nicht im gleichen Subnetz liegen wie das interne Netz.

Jetzt fügen Sie folgendes HideNAT hinzu:
Quelle: Internes Netz
NAT-Relationship: 172.16.0.1
Ziel: Internes Netz

Vorletzter Schritt ist ein Portforwarding:
Quelle: Internes Netz
NAT-Relationship: eth0 (ppp0)
Ziel: <Gerät>
Externer Port: <Dienstname>

Und zuguterletzt die Firewall-Regel:
Quelle: Internes Netz
Dienst: <Dienstname>
Ziel: Internes Netz

Super, Danke für die Anleitung. Hat auf Anhieb geklappt!
Hatte ja fast alles richtig, bloß der Hide-Nat Eintrag war nicht dabei.

Dies hat mir bei meinem Dyndns Problem von innen nach innen auch geholfen, nur leider habe ich nicht wirklich verstanden was ich da mit der dummy adresse gemacht habe.
Da fehlt mir grade irgendwie der Bezug ...

OK ich werd das mal versuchen darzustellen.
Folgendes Szenario:
Der Client A mit der IP 10.0.0.1/24 möchte über die öffentliche
IP 192.0.2.1 (eth0) auf einen Client B (10.0.0.2/24) im
gleichen Netz einen Ping absetzen. Auf der Firewall ein Portforwarding eingerichtet:
Internet -> eth0 -> Client B -> icmp

Die Kommunikation zwischen den Rechnern sieht dann folgendermaßen aus:

	     icmp-echo-request
10.0.0.1/24 ------------------> 192.0.2.1

Hier kommt jetzt das Portforwarding ( = DNAT = Destination NAT = die Zieladdresse wird geändert)
ins Spiel. Das daraus resultierende Paket ist dieses:

	     icmp-echo-request
10.0.0.1/24 ------------------> 10.0.0.2/24

Dieses Paket verlässt die Firewall also ins interne Netz und kommt bei Client B an.
Dieser stellt jetzt fest, dass er sich ja im selben Subnetz befindet, wie Client A und antwortet so:

	     arp-who-has 10.0.0.1
10.0.0.2/24 ---------------------> Broadcast

	     arp-reply [MAC von Client A]
10.0.0.1/24 -----------------------------> 10.0.0.2/24
	  
	     icmp-echo-reply
10.0.0.2/24 ----------------> 10.0.0.1/24

Vergleicht man jetzt das erste (icmp-echo-request) mit dem letzen (icmp-echo-reply)
stellt man fest, dass es für Client A so aussieht, als käme die Antwort auf seinen Ping
von einer ganz anderen IP-Addresse:

	     icmp-echo-request
10.0.0.1/24 ------------------> 192.0.2.1

	      icmp-echo-reply
10.0.0.2/24 ------------------> 10.0.0.1/24

Deshalb wird er das Paket verwerfen. Hier kommt jetzt unsere Dummy-IP 172.16.0.1 und das HideNAT ins Spiel.
Das HideNAT ist ein SNAT (= SourceNAT = die Quelladdresse wird geändert). Die Kommunikation sieht dann wie folgt aus:

	     icmp-echo-request
10.0.0.1/24 ------------------> 192.0.2.1

Hier das DNAT:

	     icmp-echo-request
10.0.0.1/24 ------------------> 10.0.0.2/24

Zusätzlich wird jetzt ein SNAT durchgeführt

	    icmp-echo-request
172.16.0.1 ------------------> 10.0.0.2/24

Das Paket verlässt die Firewall und kommt bei Client B an. Dieser weiss nicht, wo das Netz mit der IP 172.16.0.1 ist
und schickt den icmp-echo-reply daher über sein Default-Gateway (die Firewall) zurück.

	      icmp-echo-reply
10.0.0.2/24 ------------------> 172.16.0.1

Dieses Paket kommt an der Firewall an und diese führt nun das SNAT und das DNAT in umgekehrte
Richtung durch (Stichwort "Connection Tracking").
Das Ergebnis ist dieses Paket:

	    icmp-echo-reply
192.0.2.1 ------------------> 10.0.0.2/24

Vergleicht man jetzt das erste und das letzte Paket, wird klar, warum der Ping seinen Weg zurück in
die Eingabeaufforderung gefunden hat

	     icmp-echo-request
10.0.0.1/24 ------------------> 192.0.2.1

	      icmp-echo-reply
192.0.2.1   ------------------> 10.0.0.1/24