Statische NAT Einträge aus lokalem Netz erreichbar machen

Moderator: Securepoint

Gesperrt
SchlaWiener
Beiträge: 18
Registriert: Fr 28.09.2007, 14:16

Statische NAT Einträge aus lokalem Netz erreichbar machen

Beitrag von SchlaWiener »

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

merlin
Beiträge: 263
Registriert: So 01.07.2007, 12:34
Wohnort: Erlangen

Beitrag von merlin »

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

Benutzeravatar
Erik
Securepoint
Beiträge: 1480
Registriert: Fr 07.11.2008, 11:50

Beitrag von Erik »

Guten Tag,
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

SchlaWiener
Beiträge: 18
Registriert: Fr 28.09.2007, 14:16

Beitrag von SchlaWiener »

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

N1con
Beiträge: 5
Registriert: Mo 11.01.2010, 22:55

Beitrag von N1con »

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 ...

Benutzeravatar
Erik
Securepoint
Beiträge: 1480
Registriert: Fr 07.11.2008, 11:50

Beitrag von Erik »

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:

Code: Alles auswählen

	     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:

Code: Alles auswählen

	     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:

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
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:

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
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:

Code: Alles auswählen

	     icmp-echo-request
10.0.0.1/24 ------------------> 192.0.2.1
Hier das DNAT:

Code: Alles auswählen

	     icmp-echo-request
10.0.0.1/24 ------------------> 10.0.0.2/24
Zusätzlich wird jetzt ein SNAT durchgeführt

Code: Alles auswählen

	    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.

Code: Alles auswählen

	      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:

Code: Alles auswählen

	    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 ;)

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

Gesperrt