Wir haben eine Securepoint 10 aufgesetzt, die mehrere Public IPs auf eth0 besitzt, nennen wir sie 1.1.1.1, 1.1.1.2 und 1.1.1.3...
Folgende Netzobjekte sind definiert und per SNAT an die jeweilige Public-IP gebunden:
Server A = 10.0.0.1 steht in der DMZ
Server B = 10.0.0.2 steht in der DMZ
Server C = 10.0.0.3 steht im LAN
Hosting-Gruppe = Server A + B
Office-Gruppe = Server C
Folgende Dienstegruppen sind definiert:
Windows-Hosting = http https ftp
Als Portfilter gibt es dann folgende, um das SNAT zu aktivieren:
Internet -> Office-Gruppe -> https -> ACCEPT
Internet -> Office-Gruppe -> smtp -> ACCEPT
Internet -> Office-Gruppe -> msrdp -> ACCEPT
Internet -> Hosting-Gruppe -> Windows-Hosting -> ACCEPT
Internet -> Hosting-Gruppe -> msrdp -> ACCEPT
Sprich: Es gibt KEIN SNAT-Mapping für smtp vom Internet in die Hosting-Gruppe.
Trotzdem legt die Securepoint laut Manager -> Firewall -> Statische NAT ein solches Mapping für jede Public-IP zur entsprechenden DMZ-IP an. Wie kann das sein?
So sieht es in dem Dialog dann aus:
Server C -> 1.1.1.3 -> Internet -> https [KORREKT]
Server C -> 1.1.1.3 -> Internet -> smtp [KORREKT]
Server C -> 1.1.1.3 -> Internet -> msrdp [KORREKT]
Server A -> 1.1.1.1 -> Internet -> ftp, http, https [KORREKT]
Server B -> 1.1.1.2 -> Internet -> ftp, http, https [KORREKT]
Server A -> 1.1.1.1 -> Internet -> msrdp [KORREKT]
Server B -> 1.1.1.2 -> Internet -> msrdp [KORREKT]
Server C -> 1.1.1.3 -> Internet -> smtp [TAUCHT HIER ERNEUT AUF?]
Server A -> 1.1.1.1 -> Internet -> smtp [UNERWÜNSCHT]
Server B -> 1.1.1.2 -> Internet -> smtp [UNERWÜNSCHT]
Hängt es vielleicht mit diesen ausgehenden Portfiltern zusammen?
Office-Gruppe -> Internet -> smtp -> ACCEPT
Hosting-Gruppe -> Internet -> smtp -> ACCEPT
Falls ja, sollte man nicht erwarten, daß das SNAT nur wirkt, wenn das Netzwerk-Objekt als Destination im Portfilter eingetragen ist? Oder gibt es dafür einen tieferen Sinn den ich noch nicht kenne?
Lerne gern dazu. :-)
Unerwartete Mappings bei SNAT
Moderator: Securepoint
-
- Beiträge: 34
- Registriert: Do 30.10.2008, 15:44
Unerwartete Mappings bei SNAT
Zuletzt geändert von hurikhan77 am Di 02.03.2010, 20:48, insgesamt 1-mal geändert.
Ah da schlägt doch mein Ratschlag aus Ihrem andern Fred schon zu
Wenn Sie ausgehende Regeln definieren, tun Sie das bitte mit einem (neuen) Netzwerkobjekt, bei dem "Statisches NAT" nicht ausgefüllt ist.
Der tiefere Sinn ist, dass ja das ausgehende Paket wieder entsprechend zurückgenattet werden muss (das Conntrack kann hier nicht greifen), weswegen die "Rückregel" explizit in den iptables hinterlegt wird.
Wenn Sie ausgehende Regeln definieren, tun Sie das bitte mit einem (neuen) Netzwerkobjekt, bei dem "Statisches NAT" nicht ausgefüllt ist.
Der tiefere Sinn ist, dass ja das ausgehende Paket wieder entsprechend zurückgenattet werden muss (das Conntrack kann hier nicht greifen), weswegen die "Rückregel" explizit in den iptables hinterlegt wird.
Zuletzt geändert von Erik am Di 02.03.2010, 22:27, insgesamt 1-mal geändert.
-
- Beiträge: 34
- Registriert: Do 30.10.2008, 15:44
Hab's nun einfach in die umgekehrte Richtung für das gesamte DMZ-Subnetz erlaubt statt für die einzelnen Server in der DMZ - das muß man da nicht ganz so eng sehen, da dort bisher sowieso für alle Server die selben ausgehenden Regeln gelten.Erik hat geschrieben: Ah da schlägt doch mein Ratschlag aus Ihrem andern Fred schon zu
Wenn Sie ausgehende Regeln definieren, tun Sie das bitte mit einem (neuen) Netzwerkobjekt, bei dem "Statisches NAT" nicht ausgefüllt ist.