Securepoint Support Forum

Hallo,

es gab hier:
http://www.securepoint.de/support/topic.php?id=827
bereits vor einiger Zeit einen ähnlichen Fall, aber der ist zum Ende hin etwas abgeschweift, daher mache ich einmal ein neues Topic auf.

Wir bekommen vermehrt Anfragen über ein VPN-Fallback beim Einsatz von Ethernet-Connect.

Ein Kunde hat ein Ethernet-Connect von der Telekom,
Beide Standorte haben also das selbe Netz:
StandortA = 192.168.0.0 /24
StandortB = 192.168.0.0 /24

Jetzt möchte sich der Kunde zusätzlich absichern, Falls die Leitung abbricht.
Nach mehreren Überlegungen wäre eine Option, einen VPN-Tunnel über die vorhandenen Securepoints/SDSL-Leitungen an beiden Standorten zu etablieren.

Wenn es an dieser Stelle schon bessere Vorschläge gibt, bin ich ganz Ohr...

Da die Netze identisch sind, würde ich die Lösung aus dem oben genannten Post (Virtuelle IPs) verwenden.

StandortB soll zu StandortA Windows Terminalserver erreichen können.
(Die Option, dass StadtortA auch zu StandortB zugreifen kann, muss auch möglich sein - IP-Drucker stehen z.B. in StandortB)

StandortA:
1. Netzwerk
interne FW-IP (eth1): 192.168.0.1 /24
virtuelle IP (eth1): 172.16.1.1 /24

StandortB:
1. Netzwerk
interne FW-IP (eth1): 192.168.0.2 /24
virtuelle IP (eth1): 172.17.1.1 /24

VPN-Einrichtung StandortA:
2. Netzwerkobjekt-VPN
ipsec-StandortB 172.17.1.0 /24, Zone=vpn-IPSEC
3. Netzwerkobjekt internes virtuelles LAN StandortA:
LAN-virtuellA 172.16.1.0 /24 Zone=intern
4. VPN-Tunneleigenschaften (natives IPSEC)
lokales LAN: 172.16.1.0 / 24
Remote-LAN: 172.17.1.0 /24

VPN-Einrichtung StandortB:
2. Netzwerkobjekt-VPN
ipsec-StandortA 172.16.1.0 /24, Zone=vpn-IPSEC
3. Netzwerkobjekt internes virtuelles LAN StandortA:
LAN-virtuellB 172.17.1.0 /24 Zone=intern
4. VPN-Tunneleigenschaften (natives IPSEC)
lokales LAN: 172.17.1.0 / 24
Remote-LAN: 172.16.1.0 /24

Bis hier: Tunnel wird aufgebaut (ist auch keine Kunst)

Hide-NAT StandortA
5. LAN-A (192.168.0.0/24) -> Relation: 172.16.1.1 -> Ziel: LAN-virtuellB (172.17.1.0/24) nicht ausnehmen

Hide-NAT StandortB
5. LAN-B (192.168.0.0/24) -> Relation: 172.17.1.1 -> Ziel: LAN-virtuellA (172.16.1.0/24) nicht ausnehmen

Ist das Hide-NAT korrekt?

Zu den Regeln...
Ich möchte von Client1 (192.168.0.3) aus StandortB per RDP auf z.B. Terminalserver1 (192.168.0.4) in StandortA zugreifen.
Aufgrund der virtuellen-Netze wäre der Zugriff also:
Client1-StandortB (192.168.0.3) -> Terminalserver1-StandortA (172.16.1.4) -> RDP -> allow

Was muss hier nun wie ge-nat-et werden?
Ich dachte, dass ich den Terminalserver statisch natten müsste:
StandortA: Terminalserver1: 192.168.0.4, host, internal, snat: 172.16.1.4
Regel StandortA: LAN-virtuellB (172.17.1.0 /24) -> Terminalserver1 -> rdp -> allow
Regel StandortB: LAN-B (192.168.0.0 /24) -> LAN-virtuellB (172.16.1.0 /24) -> any -> allow

... funktioniert nicht.

füge ich in StandortB zusätzlich ein snat für den Client (auf 172.17.1.3) und eine separate Regel für den Client ein:
Client1 (192.168.0.3) -> LAN-virtuellB (172.16.1.0 /24) -> any -> allow

funktioniert es.

Fragen:
1. Strategie überhaupt richtig?
2. Muss ich an beiden Standorten jedes Objekt, das mit dem anderen Standort kommunizieren will, einzeln mit snat anlegen und eine separate Regel für jeden zugreifenden "Client" anlegen, oder mache ich irgendwo einen schritt zu viel?
3. Hide-Nat richtig bzw. welchen Sinn macht Hide-NAT, wenn jedes Objekt bereits snat hat?

Freue mich auf Antworten...

Gruß
Achim

ich weiß ja, dass es sich kompliziert liest, aber eigentlich ist die Problematik "nur":

1. VPN-Tunnel bei gleichem Subnet
2. Traffik in beide Richtungen ermöglichen

und dann die Fragen dazu:
Fragen:
1. Strategie überhaupt richtig?
2. Muss ich an beiden Standorten jedes Objekt, das mit dem anderen Standort kommunizieren will, einzeln mit snat anlegen und eine separate Regel für jeden zugreifenden "Client" anlegen, oder mache ich irgendwo einen schritt zu viel?
3. Hide-Nat richtig bzw. welchen Sinn macht Hide-NAT, wenn jedes Objekt bereits snat hat?

???

achim hat geschrieben: [...] Ist das Hide-NAT korrekt?

Soweit ist alles gut.

achim hat geschrieben: Zu den Regeln...
Ich möchte von Client1 (192.168.0.3) aus StandortB per RDP auf z.B. Terminalserver1 (192.168.0.4) in StandortA zugreifen.
Aufgrund der virtuellen-Netze wäre der Zugriff also:
Client1-StandortB (192.168.0.3) -> Terminalserver1-StandortA (172.16.1.4) -> RDP -> allow

Was muss hier nun wie ge-nat-et werden?
Ich dachte, dass ich den Terminalserver statisch natten müsste:
StandortA: Terminalserver1: 192.168.0.4, host, internal, snat: 172.16.1.4
Regel StandortA: LAN-virtuellB (172.17.1.0 /24) -> Terminalserver1 -> rdp -> allow
Regel StandortB: LAN-B (192.168.0.0 /24) -> LAN-virtuellB (172.16.1.0 /24) -> any -> allow

... funktioniert nicht.

Sind sie sicher, dass "funktioniert nicht" heißt: "die Pakete werden von der Firewall verworfen". Ich tippe nämlich drauf, dass es heißt: "der Server antwortet nicht".
Da geschehen gern komische Dinge, wenn die Quell-IP (des Pings zb) nicht im gleichen Netz ist, wie der Terminal-Server.

Prüfen Sie das am besten mit "tcpdump -i -nnp proto 1".
Sehen Sie nur die Echo Requests, aber keine Replies, antwortet der Server nicht.

Der Server antwortet nicht.
Beide Firewalls lassen die Pakete durch, aber ich gelange weder mit ping noch mit rdp zum server.

erst nachdem ich
füge ich in StandortB zusätzlich ein snat für den Client (auf 172.17.1.3) und eine separate Regel für den Client ein:
Client1 (192.168.0.3) -> LAN-virtuellB (172.16.1.0 /24) -> any -> allow

hinzugefügt habe, antwortet der Server und der Zugriff funktioniert.

Daraus folgte dann die Frage, welchen Sinn das Hide-NAT macht, wenn ich eh alle Server/Clients statisch natten muss. bzw. habe ich etwas anderes vergessen, weshalb der Server nicht antwortet. (firewall auf den Clients/Servern kann definitiv ausgeschlossen werden.)

Danke
Achim

HideNAT = SNAT = nur die Quell-Adresse wird geändert. Das brauchen Sie, damit der Server in NetzA nicht denkt, dass die Antwort an einen Rechner im lokalen Netz geht.

Statisches NAT = DNAT = nur die Ziel-Adresse wird geändert. Das brauchen Sie, damit der Client in NetzB nicht denkt, der Server steht im lokalen Netz.

Beides zusammen sorgt dafür, dass der Traffic zwischen ClientB und ServerA immer über die beiden Firewalls geroutet wird.

Ok, zuerst danke für die (tageszeitlich) späte Antwort...

Aber, ich wollte hier kein PING-PONG-Spiel erzeugen...

Mein Fehler: als ich SNAT schrieb meinte ich Statisches NAT und kein Source NAT... da in der Securepoint ja auch keine Menüpunkte angesprochen werden, die Source oder Destination NAT heißen...

Hide-NAT = SourceNAT = ... das ist mir wohl klar
Statisches NAT = DestinationNAT = nur die Ziel-Adresse wird geändert ... ist für mich Blödsinn...
Statisches NAT = Destination-NAT + Source-NAT -> selbst unsere Securepoint sieht das so- gerade eben getestet: Securepoint ohne eine Hide-NAT-Regel und der Server mit statischem NAT kann trotzdem ins Inet... was ohne SourceNAT nicht gehen würde.


Ich wollte mir nur etwas Zeit sparen bzw. die Tests nicht beim Kunden durchführen und hatte deshalb aus zeitmangel für ewige tests das ganze ins forum gestellt...

Eigentlich möchte ich nur ein Antwort auf die Frage:
Warum funktioniert die geschilderte Situation nur mit statischem NAT auf beiden Seiten und nicht auch mit Hide-Nat auf der Quellseite und Statischem NAT auf der Zielseite?

A1. aufgrund von planlosigkeit müssen sie einen leichtsinnigkeitsfehler begangen haben
A2. Sie haben in Ihrer Ausführung im ersten Post folgendes vergessen:...
A3. wir haben keine Ahnung, so weit haben wir das nie getestet
A4. Wir unterscheiden gar nicht zwischen den verschiedenen NAT-Typen, in dem neuesten Release ist ein Zufallsgenerator eingabaut, der den Typ des NAT je nach Uhrzeit bestimmt und ihr einzelner test war somit nicht als referrenz geeignet...
A4. Sie verstehen das einfach nicht, sie müssen betriebsblind sein: wenn sie am mittwoch beim kunden sind, sollten wir das telefonisch klären
A5. Maaaaannnn Alter... die Antwort ist 42


gruß
achim