[Gelöst] SSL VPN Verbindung steht, keine Kommunikation möglich

Allgemeine Fragen zu Problemen. Keine Fehlerberichte oder Feature-Anfragen

Moderator: Securepoint

Antworten
jens.manke
Beiträge: 25
Registriert: Mi 03.02.2016, 23:13

[Gelöst] SSL VPN Verbindung steht, keine Kommunikation möglich

Beitrag von jens.manke »

Hallo zusammen,

ich habe zwei SSL VPN gemäß wiki konfiguriert, beides UTM 11.6.1:

1. Dwarf mit RC100 Site-to-Site SSL VPN
2. Dwar Roadwarrior SSL VPN

Beide VPN Verbindungen werden aufgebaut, ich kann bei beiden jedoch nicht kommunizieren, d.h. es wird schon auf Pings nicht geantwortet. Ich habe mich an den Wiki gehalten und Regeln, Netzwerkobjekte, Routen konfiguriert. Ich erhalte auch den DNS übertragen, jedoch geht kein Verkehr durch. Beim Roadwarrior kann ich z.B. weder das Handy anpingen noch vom Handy ins Netz.

Benutzeravatar
Erik
Securepoint
Beiträge: 1480
Registriert: Fr 07.11.2008, 11:50

Beitrag von Erik »

Hier muss doch irgendwo... Ah! Meine Gebetsmühle!

- Prüfen Sie, ob es Fehlermeldungen beim Verbindungsaufbau gibt.
- Werden die Routen für das jeweils gegenüberliegende Netz korrekt gesetzt? (Netzwerk -> Netzwerk-Werkzeuge)
- Sind im Livelog geDROPte Pakete zu sehen? (Wenn Sie einen Ping schicken)
- Sind im Livelog ACCEPTete Pakete zu sehen, nachdem Sie das Logging für SSLVPN-Regel aktiviert haben? (Wenn Sie einen Ping schicken)
- Ist die Windoze-Firewall auf dem Zielserver so konfiguriert, dass sie Verbindungen aus dem SSLVPN-Netz zulässt?

jens.manke
Beiträge: 25
Registriert: Mi 03.02.2016, 23:13

Beitrag von jens.manke »

Hallo Erik,

also laut den "grünen Lämpchen" steht die Verbindung, laut LOG ist sie was flatterhaft:

04.02.2016 10:43:03 openvpn-S2S Server g-server MANAGEMENT: Client connected from /tmp/openvpn_management_EB760314.sock
04.02.2016 10:43:03 openvpn-S2S Server g-server MANAGEMENT: CMD 'state'
04.02.2016 10:43:03 openvpn-S2S Server g-server MANAGEMENT: Client disconnected
04.02.2016 10:43:03 openvpn-S2S Server g-server MANAGEMENT: Client connected from /tmp/openvpn_management_EB760314.sock
04.02.2016 10:43:03 openvpn-S2S Server g-server MANAGEMENT: CMD 'status 2'
04.02.2016 10:43:03 openvpn-S2S Server g-server MANAGEMENT: Client disconnected
04.02.2016 10:43:07 DHCP-Server (dhcpd) DHCPREQUEST for 192.168.8.9 from 00:1a:e8:68:e4:9f via eth1
04.02.2016 10:43:07 DHCP-Server (dhcpd) DHCPACK on 192.168.8.9 to 00:1a:e8:68:e4:9f via eth1

Für das Ping kriege ich einen default drop:

04.02.2016 10:46:15 kernel DROP: (DEFAULT DROP)192.168.10.3:54458 tun0 eth1 192.168.8.146:161UDP
04.02.2016 10:46:15 kernel DROP: (DEFAULT DROP)192.168.10.3:54458 tun0 eth1 192.168.8.146:161UDP

Das traceroute von eimem PC des 192.168.8.x Netzes kommt nur bis zur Firewall 192.168.8.1, das Transfernetzwerk mit der 192.168.33.x wird schon nicht mehr erreicht. Ich habe folgende Routen gesetzt.

Site-to-Site SSLVPN, Port 1195
Netz des SSLVPN Servers: 192.168.8.0/24 mit Interface tun0, Transfernetzwerk 192.168.33.0/24
Netz des SSLVPN Clients: 192.168.10.0/24 mit Interface tun0


Route auf Server: 192.168.10.0/24 auf tun0

Route auf dem Client: 192.168.8.0/24 auf tun0

jens.manke
Beiträge: 25
Registriert: Mi 03.02.2016, 23:13

Beitrag von jens.manke »

Nachtrag:

Die Firewall Regeln habe ich so erstellt wie im wiki, d.h. internal-networks --> VPN objekt any und dann nochmal die Gegenrichtung mit VPN objekt --> internal networks any

Bei der IPSEC Set-up Beschreibung, wurde auch ein IPSEC aufs Interface konfiguriert, sowas habe ich beim VPN SSL nicht gefunden und daher auch nicht aufgesetzt, falls das der Grund sein sollte

Ergebnis Traceroute mit Netzwerktools der UTM, diesmal kommt ich zumindest zum Transfernetzwerk:

LOG
4.02.2016 11:08:23 spcgi AUDITuser=adminremote=::ffff:192.168.8.238duration=5mscommand=dhcp lease list
04.02.2016 11:08:24 DHCP-Server (dhcpd) DHCPINFORM from 192.168.8.5 via eth1: not authoritative for subnet 192.168.8.0

Traceroute:

traceroute to 192.168.10.3 (192.168.10.3), 30 hops max, 60 byte packets
1 192.168.77.2 (192.168.33.2) 37.167 ms 37.181 ms 36.793 ms

Benutzeravatar
Erik
Securepoint
Beiträge: 1480
Registriert: Fr 07.11.2008, 11:50

Beitrag von Erik »

Der Default-DROP deutet darauf hin, dass mindestens ein Netzwerkobjekt falsch ist. Da der Internetzugriff ja wohl funktioniert, kann es nur das Netzwerkobjekt für das Remote-Netz sein. Bitte prüfen Sie, ob die Zone, die sich auf "tun0" befindet exakt mit der Zone übereinstimmt, die das Remote-Netz im Netzwerkobjekt hat.

Dann prüfen Sie, ob das Netzwerkobjekt wirklich mit dem Remote-Netz im Feld "Adresse" angelegt wurde. Das Transfernetz ist bei SSLVPN-Verbindungen an der Stelle irrelevant.

jens.manke
Beiträge: 25
Registriert: Mi 03.02.2016, 23:13

Beitrag von jens.manke »

Ok, ich habe hier immerhin jetzt ein accept des Pings, ich muss nachher nochmal an den anderen Standort schauen fahren, wie es dort aussieht, ich denke es klemmt jetzt noch bei der Gegenseite. Wir hatten eine Doublette in der Zone, die auf ein leeres Interface gezeigt hat, wahrscheinlich ein Artefakt einer früheren Konfig.

Frage: Beim Netzwerkobjekt also "einfach" die IP des Netzwerkes der Gegenseite eintragen und NICHT das interface, richtig?

Benutzeravatar
Erik
Securepoint
Beiträge: 1480
Registriert: Fr 07.11.2008, 11:50

Beitrag von Erik »

Wie meinen? Welches "Interface" wollen Sie da eintragen? Wenn auf der Gegenseite das Netz "192.168.10.0/24" ist, muss das auch genau so im "Adress"-Feld des Netzwerkobjekts angegeben werden.

jens.manke
Beiträge: 25
Registriert: Mi 03.02.2016, 23:13

Beitrag von jens.manke »

In der Anleitung zu IPSEC wurde IPSEC noch auf eth0 freigegeben.

ich bin jetzt bei der gegenstellt, dort werden die pings auch akzeptiert, allerdings gibts keine Antwort, das traceroute kommt auch bis zum tranfernetzwerk, allerdings nicht weiter. Routen stimmen. Was könnte jetzt noch falsch sein? die CLI basierte Änderung wegen port 1195 habe ich gemacht, die bezieht sich wahrscheinlich auch nur auf den Tunnelaufbau, dieser steht ja.

jens.manke
Beiträge: 25
Registriert: Mi 03.02.2016, 23:13

Beitrag von jens.manke »

Hat sich erledigt, Mr Zufall hatte den Server abstürzen lassen, danke soweit

Antworten