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
Statische NAT Einträge aus lokalem Netz erreichbar machen
Moderator: Securepoint
-
- Beiträge: 18
- Registriert: Fr 28.09.2007, 14:16
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
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/to ... 54#post354
ich copy'n'paste einfach mal meinen Beitrag aus dem TERRA-Forum:
https://www.terra-firewall.com/forum/to ... 54#post354
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:
Externer Port:
Und zuguterletzt die Firewall-Regel:
Quelle: Internes Netz
Dienst:
Ziel: Internes Netz
-
- Beiträge: 18
- Registriert: Fr 28.09.2007, 14:16
Super, Danke für die Anleitung. Hat auf Anhieb geklappt!
Hatte ja fast alles richtig, bloß der Hide-Nat Eintrag war nicht dabei.
Hatte ja fast alles richtig, bloß der Hide-Nat Eintrag war nicht dabei.
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:
Hier kommt jetzt das Portforwarding ( = DNAT = Destination NAT = die Zieladdresse wird geändert)
ins Spiel. Das daraus resultierende Paket ist dieses:
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:
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:
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:
Hier das DNAT:
Zusätzlich wird jetzt ein SNAT durchgeführt
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.
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:
Vergleicht man jetzt das erste und das letzte Paket, wird klar, warum der Ping seinen Weg zurück in
die Eingabeaufforderung gefunden hat
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:
Code: Alles auswählen
icmp-echo-request
10.0.0.1/24 ------------------> 192.0.2.1
ins Spiel. Das daraus resultierende Paket ist dieses:
Code: Alles auswählen
icmp-echo-request
10.0.0.1/24 ------------------> 10.0.0.2/24
Dieser stellt jetzt fest, dass er sich ja im selben Subnetz befindet, wie Client A und antwortet so:
Code: Alles auswählen
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
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:
Code: Alles auswählen
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
Das HideNAT ist ein SNAT (= SourceNAT = die Quelladdresse wird geändert). Die Kommunikation sieht dann wie folgt aus:
Code: Alles auswählen
icmp-echo-request
10.0.0.1/24 ------------------> 192.0.2.1
Code: Alles auswählen
icmp-echo-request
10.0.0.1/24 ------------------> 10.0.0.2/24
Code: Alles auswählen
icmp-echo-request
172.16.0.1 ------------------> 10.0.0.2/24
und schickt den icmp-echo-reply daher über sein Default-Gateway (die Firewall) zurück.
Code: Alles auswählen
icmp-echo-reply
10.0.0.2/24 ------------------> 172.16.0.1
Richtung durch (Stichwort "Connection Tracking").
Das Ergebnis ist dieses Paket:
Code: Alles auswählen
icmp-echo-reply
192.0.2.1 ------------------> 10.0.0.2/24
die Eingabeaufforderung gefunden hat
Code: Alles auswählen
icmp-echo-request
10.0.0.1/24 ------------------> 192.0.2.1
icmp-echo-reply
192.0.2.1 ------------------> 10.0.0.1/24