VPN-Benutzer (WAN) erreicht LAN an eth7 nicht

Hallo Lars,

wieso denn IP aus dem "richtigen" Netz? Dem VPN User musst Du schon ne andere IP Range zuweisen und diese routen; VPN User in Netze "bridgen" geht nu nich....

C.

wieso denn IP aus dem "richtigen" Netz? Dem VPN User musst Du schon ne andere IP Range zuweisen und diese routen; VPN User in Netze "bridgen" geht nu nich....

Ich habe dem Remote-Benutzer eine "Statische Fernzugriffs-IP" verpasst - passend zum Netz an eth7. Diese IP wird dem Client auch korrekt vergeben bei der Einwahl. Aus welchem Netz muss er denn eine IP haben? Aus dem von eth0 (LAN)?

Gruß, Lars

Hi Lars,

nein, für jeden VPN Einwahltypen gibts einen eigenen IP Pool, aus dem die IPs vergeben werden. Also aus z.B. dem SSL VPN Pool. Bei SSL VPN klappt aber die Zuordnung von statischen User IP Addressen nicht, daher kannst Du Dir das auch gepflegt sparen [;)]

LG
Christian

OK, der PPTP-Benutzer bekommt nun eine IP aus dem Bereich 10.242.1.x zugewiesen. Folgende Schnittstellen-Route extisitert: VPN Pool (PPTP) → Interface eth7. Der Paketfilter erlaubt alle Dienste von VPN Pool (PPTP) nach eth7. Über den Tunnel geht der Ping auf eth 7 (10.1.1.6). Alle weiteren Anfrage (z.B. RDP auf 10.1.1.4) funktionieren nicht. Noch eine Idee dazu?

Danke und Gruß, 
Lars

OK, der PPTP-Benutzer bekommt nun eine IP aus dem Bereich 10.242.1.x zugewiesen. Folgende Schnittstellen-Route extisitert: VPN Pool (PPTP) → Interface eth7. Der Paketfilter erlaubt alle Dienste von VPN Pool (PPTP) nach eth7. Über den Tunnel geht der Ping auf eth 7 (10.1.1.6). Alle weiteren Anfrage (z.B. RDP auf 10.1.1.4) funktionieren nicht. Noch eine Idee dazu?

Hast Du das automatisch generierte Interface eth7 Address- oder Network-Objekt in der Regel verwendet? Es hört sich so an, als ob Du nur das Address-Objekt verwendet hast.

Tipp: Lese einfach mal das Handbuch von Anfang an durch. Das ist weder viel noch kompliziert und gibt es sogar auf Deutsch...

@m.fischer: Danke für den Tipp. Es wird aber korrekt das Network-Object verwendet. 

Das Handbuch habe ich gelesen, genauso wie die Anleitung für "Remote Access via PPTP". Die einzige Besonderheit bei mir ist halt, das das Ziel-Netz für Remote-User nicht das interne eth0 ist, sondern ein an eth7 angeschlossenes Netzwerk. SLL wird nicht verwendet, nur PPTP VPN. Auch eine Richtlinien-Route führt nicht zum Ziel. Laut Paketfilet-Log werden die Netzwerk-Anfragen ja auch korrekt weitergeleitet (siehe Anhang).

Ach ja, Web- und Network-Security ist aktiviert. Sollte ich in der Richtung vielleicht weitersuchen?

Doofe Idee, hat das eth7 Netz denn die ASG als default gateway oder zumindest Routen auf die VPN Netze, die auf die ASG zeigen?

LG
Christian

Doofe Idee, hat das eth7 Netz denn die ASG als default gateway oder zumindest Routen auf die VPN Netze, die auf die ASG zeigen?

LG
Christian

eth7 hat als gateway die IP von eth0 (Internal) und es gibt eine statische route von "VPN Pool (PPTP)" nach eth7. 

Ich verstehe das nicht. Der Paketfilter zeigt doch an, das die Pakete übertragen werden. Das Ziel (ein Host im eth7-Netz) müsste daher doch auch erreichbar sein. Oder sagt das Log nur aus, das Pakete zum Ziel erlaubt wären - nicht aber das sie korrekt am Zielhost gelandet sind? [:S]

Gruß, Lars

Nein, anders.... 

Damit eine IP basierte Kommunikation (bspw. auf Basis von ICMP Ping oder TCP) funktioniert, muss sowohl der Client den Weg zum Server als auch der Server den Weg zum Client kennen. Beide müssen also ihre IP Adressen gegenseitig routen können, ansonsten musst Du dazwischen NATten (wie Du es ja auch beim Masquerading machst, wenn Du private IP Ranges in Deinem LAN nutzt und das LAN mit Servern im Internet kommunizieren will).

Du hast ein Netz (10.1.1.0/24). Die ASG ist ja Teil dieses Netzes (.6) und sowohl die ASG als auch die verbundenen Clients des PPTP Netzes (10.242.1.0/24) wissen, wie sie dieses Netz erreichen. Allerdings müssen natürlich auch die Clients und Server des 10.1.1.0/24er Netzes wissen, wie sie wiederum auf Anfragen aus dem 10.242.1.0er Netz antworten können. Für dieses Netz muss also diesen Clients eine Route bekannt sein.

Sofern die ASG das default gateway dieser Clients sein sollte (da fände ich aber .6 für eine Gateway IP leicht schräg), landen Pakete an 10.242.1.0/24 eh bei ihr (da die Clients und Server das default Gateway damit beauftragen, diesen Netzbereich zu finden). Sofern aber die ASG _nicht_ das Default GW dieses Netzes ist, solltest Du sie entweder dazu machen oder alternativ Deinem default Gateway dieses Netzes eine statische Netzroute für das Ziel 10.242.1.0/24 auf die ASG (10.1.1.6) verpassen. Weitere Alternative wäre, auf allen Clients dieses Netzes eine manuelle Netzroute für 10.242.1.0 auf die ASG zeigend zu konfigurieren.

Weitere Alternative wäre es, auf der ASG ein SNAT für das 10.1.1.0er Netz als Ziel zu konfigurieren, bei dem die source IP jedes Paketes, dass in dieses Netz geschickt wird, durch die 10.1.1.6 der ASG ersetzt wird. Dadurch entfällt ein Umkonfigurieren von Routen, allerdings verschleiert das auch die Quell-IP und Zugriffe, die vom 10.1.1.0er Netz auf Deine PPTP Clients ausgelöst werden, funktionieren nicht (weil ja immer noch kein Weg in dieses Netz bekannt ist).

Jetzt deutlicher, was gemeint ist?

Vielen Dank für die ausführliche Aufklärung. Leider funktioniert immer noch nichts...

Ich habe nun den Remote-Zugang zum Test mal nur für das Ziel-Netz "Internal" (eth0; 172.16.0.254) eingerichtet; eth7 ist z.Zt. inaktiv. Der Paketfilter erlaubt die Weiterleitung von  "VPN Pool PPTP" auf "Internal" sowie umgekehrt auch von "Internal" auf "VPN Pool PPTP". Trotzdem erreiche ich vom verbundenen Client aus absolut gar nichts in diesem Netz - nichtmal ein Ping direkt auf die eth0-IP geht durch...

Die ASG ist für die Host im 172.16.0.x-Netz das Standardgateway. Eine Route von Netzwerk "VPN Pool PPTP" nach Schnittstelle "Internal" ist angelegt und aktiviert. Ich kann jedoch keine Route von "Internal" auf "VPN Pool PPTP" einrichten. Oder muss dabei Schnittstelle "WAN" benutzt werden? Die PPTP-Clients sollen übrigens gar nicht über die Astaro surfen können, es muss lediglich über RDP ein spezieller Host erreicht werden....

Anhand dieser Anleitung ging ich irrtümlich wohl davon aus, die Einrichtung sei quasi ein Kinderspiel... [;)]