SSL-VPN - kein Zugriff aufs Netz

Moderator: Securepoint

Gesperrt
wolfit
Beiträge: 7
Registriert: Di 03.08.2010, 22:59

SSL-VPN - kein Zugriff aufs Netz

Beitrag von wolfit »

Hallo,

ich habe eine SSL-Verbindung von einem Client zum Gateway aufgebaut. Verbindung steht. Der Client erhält die IP 192.168.250.10.
Das Netz hinter der Firewall hat allerdings 192.168.175.0.
Ich habe somit keinen Zugriff auf die Rechner hinter dem Gateway, da sie ja eine andere IP haben.
Welche einstellungen muss ich noch vornehmen? Routen?

Danke im voraus!

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

Beitrag von Erik »

Routen werden implizit durch die Firewall-Regeln an den Client übergeben. Dazu müssen Sie natürlich eine Firewall-Regel haben, die dem openvpn-Netz den Zugriff ins interne Netz erlaubt (danach nicht vergessen, den OpenVPN-Dienst neuzustarten).
Geht es dann immernoch nicht, aktualisieren Sie entweder die Interfaces oder - sollte das im Moment nicht möglich sein - fügen Sie manuell folgende Route hinzu:

Quelle:
Gateway: 192.168.250.2
Ziel: 192.168.250.0/24
Zuletzt geändert von Erik am Mi 04.08.2010, 09:54, insgesamt 1-mal geändert.

wolfit
Beiträge: 7
Registriert: Di 03.08.2010, 22:59

Beitrag von wolfit »

es sind folgende Firewallregeln angelegt:

Internet -> externes Interface -> openvpn accept
SSL_Nutzer01(192.168.250.10) -> internalnetwork -> any accept

oben genannte Route habe ich eingegeben, allerdings ohne Erfolg

Ich kann mit meinem Notebook eine Verbindung von außerhalb aufbauen, dieses erhält dann die IP 192.168.250.10. Ich kann aber trotzdem nicht auf meine anderen Rechner hinter der Firewall zugreifen.
Firewall hat die IP 192.168.175.1 und die anderen Rechner 192.168.175.2 ...

ebenfalls kommt im log immer folgendes:

ralfwolf/80.237.194.100:4456 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #53 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Kann mir noch einer eine Hilfestellung geben?

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

Beitrag von Erik »

OK das hatte ich auch noch nicht.
Google gibt dazu her:
- kaputte Treiber auf dem Client,
- Leitung mit extrem hoher Latenz
- die verschlüsselten Pakete wurden beim Transport entweder manipuliert oder zerstört

Ich würde damit anfangen, einmal die TAP-Treiber komplett zu entfernen.

sascha
Beiträge: 8
Registriert: Do 02.09.2010, 17:57

Beitrag von sascha »

Ich hätte hier ein ähnliches Problem:
Es wird keine Route ins interne Netz gesetzt.

Nachdem ich mich hier durchgelesen habe wurde folgende Regel in
Firewall -> Portfilter
erstellt:

Internet -> external Interface -> openvpn -> ACCEPT

Folgende Interfaces sind aktiv:

eth0 als ppp0 - hier wird unsere DSL Verbindung aufgebaut
eth1 - internal, firewall-internal - 192.168.50.0/24
eth2 - dmz1, firewall-dmz1 - 192.168.66.6/24
tun0 - vpn-openvpn - 192.168.251.1/24

was ich so gar nicht verstehe ist folgender eintrag in der Logdatei der Verbindung :
Thu Sep 02 17:53:07 2010 C:\\WINDOWS\\system32\\route.exe ADD 87.79.75.92 MASK 255.255.255.255 192.168.99.1
Thu Sep 02 17:53:07 2010 C:\\WINDOWS\\system32\\route.exe DELETE 0.0.0.0 MASK 0.0.0.0 192.168.99.1
Thu Sep 02 17:53:07 2010 C:\\WINDOWS\\system32\\route.exe ADD 0.0.0.0 MASK 0.0.0.0 192.168.251.5
Thu Sep 02 17:53:07 2010 C:\\WINDOWS\\system32\\route.exe ADD 192.168.251.1 MASK 255.255.255.255 192.168.251.5
Thu Sep 02 17:53:07 2010 Initialization Sequence Completed
Thu Sep 02 17:55:49 2010 TCP/UDP: Closing socket
Thu Sep 02 17:55:49 2010 C:\\WINDOWS\\system32\\route.exe DELETE 192.168.251.1 MASK 255.255.255.255 192.168.251.5
Thu Sep 02 17:55:49 2010 C:\\WINDOWS\\system32\\route.exe DELETE 87.79.75.92 MASK 255.255.255.255 192.168.99.1
Thu Sep 02 17:55:49 2010 C:\\WINDOWS\\system32\\route.exe DELETE 0.0.0.0 MASK 0.0.0.0 192.168.251.5
Thu Sep 02 17:55:50 2010 C:\\WINDOWS\\system32\\route.exe ADD 0.0.0.0 MASK 0.0.0.0 192.168.99.1

//ende vom log

Was ich hier nicht verstehe sind die 99.1er netze :roll:

Freue mich auf Antworten!

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

Beitrag von Erik »

Sie pushen durch den Tunnel eine Default Route. 192.168.99.1 ist die IP des Routers vor dem Client.
Als erstes wird eine Route auf die externe IP der Firewall gesetzt, weil wir in Schritt 2 die Default-Route des Clients löschen und in den Tunnel leiten (Schritt 3).

Beim Tunnel-Abbau werden die Schritte in umgekehrter Reihenfolge durchgeführt

sascha
Beiträge: 8
Registriert: Do 02.09.2010, 17:57

Beitrag von sascha »

Ah ja, stimmt! Das muss ich mir merken!

Können Sie noch Tipps wegen der nicht herzustellenden Verbindung ins Interne Netz sagen?

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

Beitrag von Erik »

Zuerst schauen Sie im Livelog, ob da überhaupt Pakete ankommen (Logging für Regel openvpn->internal aktivieren). Entweder die Pakete sind rot (dann ist die Regel/das Netzwerkobjekt falsch) oder sie sind grün (d.h. sie erreichen den Zielserver).
Im zweiten Fall schauen Sie sich einmal die Routing-Tabelle der Firewall an und prüfen, ob folgende Route existiert:

Code: Alles auswählen

192.168.250.0/24 via 192.168.250.2 dev tun0
Wenn nicht: hinzufügen.

Wenn ja, fügen Sie folgendes HideNAT hinzu:
openvpn-Netz -> eth1 -> internes Netz

So gaukeln Sie dem Zielrechner vor, dass das Paket aus dem internen Netz kommt und umgehen die "langwierigere" Fehlersuche auf diesem Rechner. Einen Nachteil hat das aber: im Log des Ziels sehen Sie nur noch anfragen der internen Firewall-IP - deshalb würde ich zuerst auf dem Server/PC nach der Ursache forschen (macht eh keiner mehr, nachdem man die Sache mit den HideNAT verraten hat :P)

Sec_bc
Beiträge: 4
Registriert: Mi 23.06.2010, 15:44

Beitrag von Sec_bc »

I hope you have a firewall rule which must be openvpn network access to internal network allowed and do not forget to restart the open vpn service.

Gesperrt