Site2Site + VPN Probleme

[lobustemporalis]

Hallo zusammen!
Ich hab schon im Forum gesucht, aber leider nicht das Passende gefunden. Entschuldigung schon mal falls ich es übersehen habe...

Wir haben eine zertifikatsbasierte Site2Site zwischen zwei UF-Firewalls (vor jeder Firewall hängt jeweils ein Router, der aber lediglich die Interneteinwahl bereitstellt und sonst nur die entsprechenden Port offen hat für VPN bzw. S2S).

UF-260 (Standort A; 192.168.0.x) --------S2S-------- UF-200 (Standort B; 172.16.0.x)

Das funktioniert ohne Probleme. Verbindung steht. Die Rechner beider lokalen Netze können kommunizieren.

Nun das Problem: Mitarbeiter wählen sich per zertifikatsbasierten VPN (IKEv2) auf den Standort A ein. Dort vergibt die Firewall IPs aus einem Virtual-IP-Pool (192.168.220.x). Leider haben diese Mitarbeiter keine Verbindung zu Standort B. Nicht mal ein Ping ist möglich (timeout). In den S2S Verbindungseinstellungen ist auch jeweils das Netz des Virtual-IP-Pools als Remote- bzw Lokales Netzwerk eingetragen.

Was machen wir falsch?
Fehlt uns noch irgendwo an irgendeiner Stelle ein Eintrag oder eine Route?
Oder gibt es eine Sicherheitseinstellung, dass man von einem VPN nicht in ein anderes VPN/S2S kommunizieren darf?

Vielen Dank schon mal für eure Hilfe.

Beste Grüße

[UKernchen]

Hallo,
die UF- Firewalls machen per Default alle Netze dicht, für die es keine Regel gibt.

VPN nutzt hier ein eigenes Transfer-Netz.

1. Routing-Tabelle überprüfen, ob die Route zu 192.168.220.x vorhanden ist

2. Desktop-Objekt: VPN-Host erstellen, Verbindung auswählen

3. Desktop-Verbindung(en) VPN-Host zu LAN (oder Host) definieren, gewünschte Dienste frei geben

4. bitte rückmelden, die Infos zu den UF-Geräten sind leider rar

Viel Erfolg!
Uwe

[UKernchen]

Übrigens, Info aus dem gestrigen LanUpdate:

Die nächste Firmware FX 10.12 kann Wireguard!

[mohrth]

Hallo Uwe,

vielen Dank für den Hinweis.

Das heißt, obwohl für die WAN Connection/Transfernetz (192.168.230.1) schon alle Netze freigegeben sind, muss der virtuelle IP Pool für das VPN Netz (192.168.220.x) nochmal extra hinzugefügt werden?

Hier wie es momentan in der Routing Tabelle aussieht:
Ziel:
0.0.0.0/0

Interface:
eth1 (WAN Connection)

GW:
192.168.230.1

Beste Grüße
Tom

[UKernchen]

Hallo,
schau mal hier:
https://support.lancom-systems.com/know ... d=37454803

Die machen das bei Lan-to-Lan ohne Transfernetz.
Mein Fehler. Ich habe dir das für Client-to-LAN erklärt.
Und wahrscheinlich hast du das auch so konfiguriert?

Die Anleitung hilft dir sicher weiter.

[mohrth]

Hallo Uwe,

genau. Wir haben sogar die zertifkatsbasierte Anleitung dafür verwendet.
https://support.lancom-systems.com/know ... d=37454803

Von Zentrale zu Filiale steht alles und funktioniert.

Unser Problem ist der Weg von dem "Homeoffice" VPN in die Zentrale über die IPsec Verbindung zur Filiale. Da kommen wir nicht an.

Normalerweise sollte es eine Möglichkeit geben eine Route dafür anzulegen, aber bei den Lancom Firewalls scheint das aufgrund des gekapselten Virtuellen IP Pool nicht zu funktionieren. Dort gibt es ja auch keine Möglichkeit ein Gateway oder so einzutragen.

Gibt es noch andere Wege, wie man sozusagen zwischen den beiden VPN´s eine Route herstellt?
Es wäre schon sehr unpraktisch, wenn man sich erst per RDP auf einen Server in der Zentrale sich einwählen muss, um mit der Filiale zu kommunizieren.

Weil Wireguard schon angesprochen wurde.
Würde dieser Weg über Wireguard das Problem lösen?

Vielen Dank für die Hilfe!

[UKernchen]

Hallo,

das geht ganz normal über die konfigurierbare Routing-Tabelle.

2023-05-24_154456.png

Ich nutze das nicht produktiv, aber ich hatte das in der Schulung mal durchgespielt.

[mohrth]

Hi Uwe,

ok. Bei uns sieht es da momentan so aus:


Wie muss ich jetzt da den virtuellen IP Pool von VPN (192.168.220.x) da eintragen?

[GrandDixence]

Routingtabelleneinträge in der Firewall vom Standort A und B erstellen gemäss den Angaben unter:
fragen-zum-thema-vpn-f14/sitetosite-vpn ... tml#p91268

fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795

Wichtig: IPv4-Regeln in der Firewall von Standort A und B für die Security Association (SA) nicht vergessen! Siehe oben stehender Link und:
fragen-zum-thema-vpn-f14/frage-zu-vorde ... 17087.html

[mohrth]

@GrandDixence

Vielen Dank für die Infos.
Das Problem ist nicht primär die Verbindung zwischen Standort A (192.168.0.x) und Standort B (172.16.0.x)
Die ist über die offizielle Anleitung von Lancom einwandfrei zwischen den beiden Firewalls realisiert worden.
Auch mit den Subnetzen wie oben auf dem Bild zu sehen, die auf Standort A eingerichtet worden sind.

Das Problem ist der Weg von einem "HomeOffice" User...nennen wir ihn Standort C (192.168.220.x), der sich per IPsec Verbindung auf Standort A einwählt um auf Standort B zu kommen. Das funktioniert nicht.

Vielleicht noch etwas zum Hintergrund:
Wir haben jeweils vor der Firewall in Reihenschaltung einen Router hängen und dort ist für VPN die UDP Port 500 und 4500 eine Portweiterleitung eingerichtet worden.

Vielen Dank für die Erklärung

[UKernchen]

Wir reden eigentlich von diesem Szenario, stimmts?
https://support.lancom-systems.com/know ... d=37454451

Danach nutzen die Clients einen "Default Virtual-IP Pool" in einem separaten VPN-Transfer-Netz.
Zwischen LAN und VPN-Netz ist ja kein Routing nötig.

Willst du aber das LAN von Standort B erreichen, würde ich es mal mit einem Routingeintrag auf dem VPN-Client versuchen.
Etwa: route add 172.16.0.0 Mask 255.255.x.x 192.168.0.IP-der-UF
Geht bestimmt auch eleganter im Advanced VPN-Client.

Und am Standort B muß natürlich eine Rück-Route zum Transfernetz (192.168.220.x über UF Standort-A) rein.

Dann mal mit traceroute gucken

Viel Erfolg!

[mohrth]

Hi Uwe,

nein das ist nicht das Szenario.
Die VPN Verbindung von Standort C zu Standort A funktioniert einwandfrei.
Auch die S2S VPN Verbindung zwischen Standort A und Standort B funktioniert einwandfrei.

Aber die eingewählten VPN Clients bei Standort C über Standort A erreichen nicht Standort B.

Wir haben mal bei Standort B einen Tracert laufen lassen, mit folgendem Ergebnis:


d.h. er kommt aus dem Standort B (172.16.0.x) über den VPN Tunnel zu Standort A (192.168.0.252) und bleibt dort bei der WAN Schnittstelle (192.168.230.254 > Hinweis. Das 230 er Netz ist das Transfernetz zwischen Router und Firewall) hängen und weiß mit Standort C (Default IP Pool für VPN 192.168.220.x) nichts anzufangen.

Hier nochmal die WAN Schnittstelle von Standort A:


Vielen Dank für die Unterstützung!

[UKernchen]

Hallo Tom,
ich fasse mal zusammen.

Standort A
LAN: 192.168.0.x
WAN: 192.168.230.254 (Transfernetz zum DSL-Router)

Standort B
LAN: 172.16.0.x

* VPN Standort A <-> Standort B funktioniert

Standort(e) C:
VPN-Clients im IP-Pool 192.168.220.x
- angebunden an Standort A -> geht
- Zugriff auf Standort B (über Standort A) -> geht nicht

Korrekt so weit?

Dein TRACE von Standort B zu Standort C (192.168.220.7)
- läuft zu 172.16.0.252 (Router Standort B)
- läuft zu 192.168.230.254 (WAN/Transfer Standort A)
- kommt nicht ins LAN oder VPN-Pool.

Von Standort B aus:
- kannst du die LAN-IP von Standort A anpingen? (sicher, dein VPN geht ja?)
- kannst du die Gateway-IP der Firewall Standort A im LAN 192.168.220.x anpingen? (ich denke nein)
Dann wird die Firewall A offenbar eine Route zu 192.168.220.0 benötigen.
Ein Netzwerkregel zwischen LAN und VPN-Gruppe für ICMP, Ping, HTTPS.. hast du?

[lobustemporalis]

Hallo Uwe!

Entschuldige bitte die Verzögerung. Das Problem ist immer noch da und wir benötigen immer noch Rat.
Tom ist leider nicht abkömmlich. Aber deine Zusammenfassung der Erkenntnisse ist soweit richtig.

Um auf deine Fragen zu antworten:
> kannst du die LAN-IP von Standort A anpingen? (sicher, dein VPN geht ja?)
>> ja, das geht

> kannst du die Gateway-IP der Firewall Standort A im LAN 192.168.220.x anpingen? (ich denke nein)
>> ja, ich kann von einem VPN Client mit einer 192.168.220.x Adresse die Gateway IP der Firewall Standort A (192.168.230.1) anpingen

> Dann wird die Firewall A offenbar eine Route zu 192.168.220.0 benötigen.
>> den Verdacht habe ich auch - aber keine Idee, wo man diese hinzufügen könnte

> Ein Netzwerkregel zwischen LAN und VPN-Gruppe für ICMP, Ping, HTTPS.. hast du?
>> ja, ist eingerichtet

Beste Grüße
Chris

[mohrth]

Hallo Uwe,

vielen Dank für deine Unterstützung!

Der Lancom Support hatte sich zwischenzeitlich gemeldet und wir haben die Lösung gefunden.

Bei der VPN Verbindung in der Zentrale muss als lokales Netzwerk auch das Netzwerk von der Filiale hinterlegt werden.
Irritierend ist hier nur, das dabei eine Fehlermeldung kommt, die man aber mit "Dennoch speichern" ignorieren kann. Das will Lancom in einer nächsten Firmware Version beheben.

Ansonsten muss man natürlich beim Client noch die Route des Netzwerkes von der Filiale hinzufügen.

LG Tom