Securepoint Support Forum

Hallo zusammen,

nach vielem Hin-und-Her habe ich nun einen stehenden OpenVPN Site-to-Site-Tunnel.

Unsere Securepoint fungiert als Client, den Server kann ich nicht beeinflussen.
Allerdings bekomme ich keinen Zugriff auf den Server im internen Netz der Gegenseite hin. Nach deren Informationen wäre aber alles korrekt eingerichtet.

Was könnte ich auf unsere Seite noch versuchen?

Infos:
interner Server Gegenseite: 10.5.0.4
zugewiesen Tunnel-IP vom Server: 192.168.169.14 auf tun3

Was habe ich gemacht:
1. Netzwerk > Netzwerkkonfiguration > Routing (Quelle: leer / Gateway: tun3 / Ziel: 10.5.0.0/8 /Gewichtung: 0)
2. Netzwerkobjekt angelegt (10.5.0.0/8 Zone: vpn-openvpn-<Name>)
3. Regeln angelegt (10.5.0.0/8 > Internal Network > any > ACCEPT und Internal Network > 10.5.0.0/8 > any > ACCEPT)

Ich bekomme aber partout keinen Zugriff auf den Server 10.5.0.4.

Das LOG gibt nichts her, außer:
13.03.2014 12:29:55 HTTP-Proxy (squid) 1394710195.302 63143 192.100.100.3 TCP_MISS/503 4753 GET http://10.5.0.4/forms/frmservlet? - HIER_DIRECT/10.5.0.4 text/html

Muss ich noch was mit der zugewiesenen Tunnel-IP machen? Muss ich noch was natten?

Danke für eure Mühen!

Gruß
Malte

Hallo,

ist der Server durch den Tunnel anpingbar?
Wenn dies nicht der Fall ist, überprüfen Sie ob die Pakete in den Tunnel gehen.
Dazu verbinden Sie sich als "root" User per SSH auf die Firewall und dumpen:

# tcpdump -i tun3 -nnp

Gruß

Hallo,

der Ping wird grundsätzlich von der Gegenseite verworfen. Daher funktioniert der Ping eh nicht.

Der tcpdump zeigt folgendes:

14:19:51.635836 IP 192.168.169.14.54557 > 10.5.0.4.80: Flags , seq 3966099676 , win 14600, options [mss 1460,sackOK,TS val 77622353 ecr 0,nop,wscale 7], lengt h 0
14:19:52.631959 IP 192.168.169.14.54557 > 10.5.0.4.80: Flags , seq 3966099676 , win 14600, options [mss 1460,sackOK,TS val 77622453 ecr 0,nop,wscale 7], lengt h 0
14:19:54.631960 IP 192.168.169.14.54557 > 10.5.0.4.80: Flags , seq 3966099676 , win 14600, options [mss 1460,sackOK,TS val 77622653 ecr 0,nop,wscale 7], lengt h 0
14:19:58.641961 IP 192.168.169.14.54557 > 10.5.0.4.80: Flags , seq 3966099676 , win 14600, options [mss 1460,sackOK,TS val 77623054 ecr 0,nop,wscale 7], lengt h 0
14:20:06.661960 IP 192.168.169.14.54557 > 10.5.0.4.80: Flags , seq 3966099676 , win 14600, options [mss 1460,sackOK,TS val 77623856 ecr 0,nop,wscale 7], lengt h 0
14:20:22.701961 IP 192.168.169.14.54557 > 10.5.0.4.80: Flags , seq 3966099676, win 14600, options [mss 1460,sackOK,TS val 77625460 ecr 0,nop,wscale 7], length 0

Gruß
Malte

Moin,

hat keiner einen Ansatz?

Gruß
Malte

Dann in einer zweiten Root-Shell im tcpdump sollten jetzt Pakete von der internen IP der Firewall zur entfernten Server-IP mit port 80 sichtbar sein. Wenn nicht, sind die lokalen FW-Regeln falsch konfiguriert.

Wenn ja: tcpdump abbrechen und erneut mit folgenden Parametern starten: Dann in der zweiten Shell wieder den "curl" Befehl ausführen.
Im tcpdump sollten jetzt zwei Arten von Paketen sichtbar sein: einmal um die 53 Byte große Pakete - das sind die SSLVPN-Keepalives und dann die eigentlichen HTTP-Pakete, während der curl versucht, die Verbindung herzustellen. Ist das der Fall, werden die Pakete von der Gegenstelle verworfen,

Hallo Erik,

letzteres trifft auf uns zu. Im tcpdump sind zwei Arten von Paketen sichtbar. Letztendlich bricht der curl-Befehl mit der Meldung "couldn't conncect to host" ab.

Somit werde ich mich mal wieder mit der Gegenseite auseinandersetzen müssen und hoffen, dass sie kritikfähig sind.

Gruß und vielen Dank
Malte