Securepoint Support Forum

Hallo,

ich habe mit Hilfe der Hotline seit gestern einen IPSec Tunnel zwischen zwei Standorten eingerichtet.
Da ich nicht so schnell mit einem Rückruf gerechnet hatte und ich zur Zeit mal wieder mehrere Projekte gleichtzeitig machen darf, habe ich
die wichtigste Information dem Hr. Johansson vorenthalten. ;-) Das Zielnetzwerk hat nämlich ein anderes Gateway als die dortige Securepoint Firewall. ;-)
Den IPSec Tunnel hatte ich mehrfach auch selber eingerichtet, bin aber an dem Zugriff auf das Zielnetzwerk gescheitert. Der Grund dürfte klar sein. .-)

Zum Verständnis:
Wir wollen aus unserem Schulungsraum und dem Netzwerk 172.16.199.0/24 auf das Zielnetzwerk des Kunden 10.46.66.0/24 zugreifen.
Der Kunde wird zukünftig Schulungen bei uns im Hause bekommen und dazu müssen die Mitarbeiter auf ihr gewohntes Netzwerk/Server zugreifen können.

Das Zielnetzwerk hat jedoch eine andere Gateway Adresse (10.46.66.1).
Der Kunde hat die zusätzliche DSL Leitung mit der Securepoint Firewall (10.46.66.253) bekommen, damit zum einen die Kaspersky Updates funktionieren aber auch,
damit verschiedene Personen aus dem WAN, Zugriff auf das interne Netzwerk erhalten.
Das funktioniert auch sehr gut.

Was nicht funktioniert, ist der Zugriff aus unserem Schulungsraum auf das Zielnetzwerk (Ping, RDP zum Beispiel).

Ich wäre sehr, sehr dankbar, wenn mir jemand verraten könnte was ich da konfigurationstechnisch machen kann!
Vielen Dank!

Mit freundlichen Grüßen
Sascha Wilknißß

Die folgende Fehlermeldung kann ich im CLI auf der Remote Firewall sehen.
2013-08-08T13:46:08+02:00 kernel DROP: (DEFAULT DROP) IN=ppp0 OUT= MAC= SRC=172.16.199.101 DST=10.46.66.253 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=2150 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=15

Die IP-Adresse 172.16.199.101 gehört meinem Notebook welches ich im Schulungsraum angeschlossen habe.
Ich habe versucht einen ping in das Remote Netzwerk abzusetzen.

Liebe Grüße
Sascha

Hallo!
Haben Sie die Regel erstellt?

Quelle: internal-network
Ziel: ipsec-netzwork
Service: any
NAT: Hidenat Exclude
Netzwerkobjekt: Ausgehendes Interface

Hallo,
vielen Dank für die Antwort!

Ich habe die Regel jetzt, wie von Ihnen beschrieben, auf unserer Firewall eingetragen.

Firewall -> Portfilter -> Regel hinzufügen
Quelle: Schulungsraum-Network -> Ziel: vpn-ipsec-network -> Dienst: any -> NAT: Hidenat Exclude -> Netzwerkobjekt: external-interface

Bei Netzwerkobjekt bearbeiten sehe ich, das bei Zone: vpn-ipsec steht und darunter bei Adresse ist das Zielnetzwerk 10.46.66.0/24 eingetragen. Ist das richtig?

Leider funktioniert der Zugriff auf das Zielnetzwerk 10.46.66.0/24 immer noch nicht.
Die folgende Fehlermeldung sehe ich im CLI Log auf der Kunden Firewall.

2013-08-08T15:54:55+02:00 kernel DROP: (DEFAULT DROP) IN=ppp0 OUT= MAC= SRC=172.16.199.1 DST=10.46.66.253 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=1844 SEQ=5

Vielen Dank!
Liebe Grüße
Sascha

Auf der "Kunden-Firewall" ist also ein eingehendes Paket aus dem Internet (IN=ppp0) zu sehen, welches von der IP 172.16.199.1 (SRC=172.16.199.1) kommt und zur IP 10.46.66.253 (DST=10.46.66.253) geschickt wird.
Warum um alles in der Welt richten Sie auf Ihrer Firewall eine ausgehende Regel ein? Ein Kollege von mir würde sagen: "Wenn Sie mit dem Auto nicht in die Garage kommen, schließen Sie doch auch nicht die Terrassentür auf und wundern sich, dass es immer noch nicht rein kommen"

Hallo, solche Vergleiche tragen zwar immer zur allgemeinen Belustigung bei, lösen jedoch nicht immer das Problem.
Ich habe nun auf unserer FW die dementsprechende Regel entfernt.
Wenn ich eine belegte Zielnetz IP 10.46.66.8 aus dem 172.xxxx Netz pinge bekomme ich keine Antwort.
Das Zielnetzs hat ein anderes (vorgegebenes ) default Gateway (10.46.66.1). Dieses Gatway kann ich nicht ändern.

Ich muss dennoch in das Zielnetz um dort per RDP/ping auf Systeme zugreifen zu können.

Hat noch jemand konkrete Tipps.

Sie müssen zwei Dinge erledingen:
1. Sorgen Sie dafür, dass die Geräte trotz anderem Default-GW wissen, wo genau das IPSec-Netz ist. Bedeutet, dass Sie entweder auf allen Clients eine statische Route eintragen oder (was irgendwie klüger ist) sie erledigen das auf dem bestehenden Gateway*.
2. Jetzt kümmern Sie sich darum, dass keine Pakete mehr verworfen werden. Sehen Sie einen DROP im Log, kontrollieren Sie die Netzwerkobjekte (korrekte Zonen? korrekte IPs/Netzmasken?) und dann die Schnittstellen (alle benötigten Zonen auf dem Interface?)

*: weil die Frage sowieso kommt... "können" Sie weder die Routen auf den Clients, noch auf dem bestehenden Default-GW verändern, kann man auf der Firewall natürlich immernoch HIDENATten. Das führt dann aber dazu, dass die Kommunikation nur in die eine Richtung (eingehend) möglich ist.