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
OpenVPN Tunnel steht, aber kein Zugriff
Moderator: Securepoint
- Christian E.
- Securepoint
- Beiträge: 238
- Registriert: Do 05.07.2012, 16:19
- Wohnort: Lüneburg
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ß
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
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
Code: Alles auswählen
# tcpdump -i tun0 -nnp port 80 or proto 1
Code: Alles auswählen
# curl --interface <IP-VON-ETH1> http://SERVER-IP
Wenn ja: tcpdump abbrechen und erneut mit folgenden Parametern starten:
Code: Alles auswählen
# tcpdump -i <EXTERNES-INTERFACE> -nnp host <SSLVPN-SERVER> and port <SSLVPN-PORT>
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
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