Basisfirewall und GRE

[Darkmind 10]

Hallo,

 

Jetzt habe ich mal beide Ports nicht auf die externe NIC sonder auf die interne NIC umgeschaltet 192.168.1.101

 

Alex

 

Ist meiner Meinung nach korrekt.

 

Hast du RRAS nach der ganzen konfiguriereri mal neu gestartet ?

 

/edit: zu spät :D

[xelafield 10]

Hallo,

 

ok, also die Portweiterleitung ist auf die interne Karte geleitet. Habe gerade einen Verbindungsversuch manuell gestartet - aber noch nix rausgekommen.

 

Neu gestartet habe ich den RAS auf dem Server der das Problem mit der Firewall hat. Den entfernten Server habe ich nicht neu gestartet.

 

Die Firewallschnittstelle ist aber schon auf der externen Karte?

 

Alex

[IThome 10]

Ja, auf der externen, die externe ist als öffentlich deklariert, macht NAT und ist durch den Basisfirewall geschützt (nur diese Schnittstelle). Die interne Schnittstelle ist als privat deklariert . Auf der externen Schnittstelle unter Dienste und Ports wird eine Umleitung von PPTP an die interne Schnittstelle konfiguriert ...

[xelafield 10]

Nö, da rührt sich gar nichts.

 

Hab jetzt nochmal die Firewall deaktiviert um andere Fehler auszuschließen. Nach der Deaktivierung dauert die Einwahl 4 Sekunden und funktioniert fehlerfrei.

 

 

Ich habe nur zwei Schnittstellen bei NAT/Basisfirewall drinnen:

- LAN extern (von der wir die ganze Zeit sprechen)

und

- Site2Site VPN (da ist NAT aktiviert damit ich ins Remotenetz komme - sonst nichts)

 

Alex

[Darkmind 10]

Nur mal so intressenshalber..

 

Wieso willst du die Basisfirewall Aktivieren ? ( Sofern der DSL Router Ports Filtert.)

 

 

Grüsse

 

Darkmind

[IThome 10]

Klicke mal mit rechts auf NAT/Basisfirewall - Neue Schnittstelle, füge Deine interne Schnittstelle zu und deklariere sie als privat ...

[xelafield 10]

ich hab in der DMZ als in dem subnetz 192.168.0.0 eine WLAN Funkbrücke dirnnen die nur mit WEP geschützt ist. WEP kann man bekanntlich sehr leicht mit LINUX knacken. Da die beiden Accesspoints als Funkbrücke konfiguriert sind können die kein WPA. Im Accesspointmodus ist das schon möglich. So weit ich weiß liegt das an den Standards, da im Bridgemodus kein WPA vorgesehen ist.

 

Aus diesem Grund möchte ich eben auf Nummer sicher gehen und hier nochmals den Server schützen.

 

Es hängen zwar in der DMZ noch ander Clients drinnen, aber die sehe ich jetzt nicht als die Gefahr an. Zumindest nicht von den Benutzern die diese Clients benutzen. Allerdings werden diese Clients von mir nicht verwaltet - und so weiß man nicht was die sich alles für ungeziefer runterladen.

 

Alex

[Darkmind 10]

ich hab in der DMZ als in dem subnetz 192.168.0.0 eine WLAN Funkbrücke dirnnen die nur mit WEP geschützt ist. WEP kann man bekanntlich sehr leicht mit LINUX knacken. Da die beiden Accesspoints als Funkbrücke konfiguriert sind können die kein WPA. Im Accesspointmodus ist das schon möglich. So weit ich weiß liegt das an den Standards, da im Bridgemodus kein WPA vorgesehen ist.

 

Aus diesem Grund möchte ich eben auf Nummer sicher gehen und hier nochmals den Server schützen.

 

Es hängen zwar in der DMZ noch ander Clients drinnen, aber die sehe ich jetzt nicht als die Gefahr an. Zumindest nicht von den Benutzern die diese Clients benutzen. Allerdings werden diese Clients von mir nicht verwaltet - und so weiß man nicht was die sich alles für ungeziefer runterladen.

 

Alex

 

 

Ist ein driftiger Grund.. absolut korrekte handlung von dir!

 

Danke..

 

Falls mir dazu noch was einfällt und ihr das problem auch nicht lösen konntet, werde ich posten :)

 

 

Grüsse und sorgenfreie Nacht...

 

Darkmind

[xelafield 10]

Hallo,

 

ok interne Schnittstelle hat nun einen Eintrag im Bereich NAT/Basisfirewall und ist auf privat gestellt. Noch keine Einwahl möglich.

 

Ich versuche jetzt folgendes:

- Starte beide Server neu (das ist nie verkehrt)

- wenns dann immer noch nicht geht. Setzte ich die Konfig von RAS auf dem Server zurück und lass die Konfiguration nochmals mit dem Assi durchlaufen. Vielleicht übersehe ich hier irgend etwas.

 

Ich bin in einer Stunde zurück. Vielen Dank an euch beide für die Hilfe. Vielleicht mögt ihr nochmals nachsehen Morgen wies mir ergangen ist.

 

Also bis dann, ich melde mich so oder so.

 

Alex

[IThome 10]

Ich weiss gar nicht, warum Du die Wählverbindung als NAT-Schnittstelle deklariert hast, die solltest Du dort entfernen. Ich denke, dass Deine gesamte RRAS-Einrichtung nicht korrekt ist. Vielleicht solltest Du diese Konfiguration mit Hilfe des Wizzards wiederholen. Wenn Du NAT machen willst, benötigst Du eine private und eine öffentliche Schnittstelle. Die Wählen bei Bedarf Schnittstelle wird der NAT-Konfiguration nicht zugefügt. Das Problem trat sehr wahrscheinlich auf, weil Du keine als privat deklarierte Schnittstelle hattest und die Portumleitung nicht korrekt war.

[xelafield 10]

Hallo,

 

die NAT Schnittstelle für die Wählverbindung habe ich eingerichtet um von den Clients am Standort 2 auf das Netz von Standort 1 zugreifen zu können, z.B. Exchange.

 

Erst als ich diese Schnittstelle als NAT eingerichtet hatte, hat das funktioniert.

 

Ist das so nicht korrekt? Müssten den die Clients auch mit dem Standort 1 Zugriff haben ohne die NAT? Die beiden Netzwerke haben verschiedene IP bereiche. Wenns aber sein muss, dann kann ich beiden standorten die gleichen Adressen geben. Wenn das was hilft. Aber ich dachte immer bei VPN sollten die Gegenstellen verschiedene Subnetze haben

 

Alex

 

edit:

ja, ich werde jetzt die RAS Konfiguration nochmals neue vom Wizard machen lassen. Ich geb bescheid wies gelaufen ist.

[IThome 10]

Da brauchst Du kein NAT, ich denke, das hat ohne NAT nicht funktioniert, weil Du die ganze Zeit keine als privat deklarierte Schnittstelle hattest. Wenn der Wizzard durch ist, wirst Du sehen, dass die Site2Site Schnittstelle nicht als NAT-Schnittstelle geführt wird. Die IP-Bereiche müssen unterschiedlich sein, für die Site2Site Schnittstelle nimmst Du einen Bereich, der ausserhalb aller kabelgebundenen Netze ist ...

[xelafield 10]

Hallo,

 

Da brauchst Du kein NAT, ich denke, das hat ohne NAT nicht funktioniert, weil Du die ganze Zeit keine als privat deklarierte Schnittstelle hattest. Wenn der Wizzard durch ist, wirst Du sehen, dass die Site2Site Schnittstelle nicht als NAT-Schnittstelle geführt wird. Die IP-Bereiche müssen unterschiedlich sein, für die Site2Site Schnittstelle nimmst Du einen Bereich, der ausserhalb aller kabelgebundenen Netze ist ...

Ich hab jetzt echt alles probiert. private Schnittstelle ect. Ein Zugriff auf das Remotenetz kommt bei mir nur mit NAT zu stande.

 

 

 

Also ich hab jetzt folgendes gemacht:

 

1.) R-RAS deaktiviert - Neustart Server

 

2.) RAS mit Assistenten neu konfiguriert. Dabei habe ich die Option für die Verbindung von Netzwerken über VPN gewählt

 

3.) Unter den Eigenschaften von RAS Server die Option RAS-SERVER aktiviert, damit sich die Gegenstelle einwählen kann

 

4.) Unter Ports den Ports PPTP und L2TP die Option RAS-Verbindungen(nur eingehend) aktiviert

 

5.) Wärend der Konfig. durch den Assi wurde eine statische Route zum Remotenetzwerk hinzugefügt

IP: 192.168.123.0

Sub: 255.255.255.0

Metrik: 1

 

6.) Bis hierhin funktionierte:

- Die VPN Verbindung zur Gegenstelle

- Der Zugriff auf das Remotenetzwerk vom Server aus - die Clients hatten noch keinen Zugriff

- Die Einwahl der Gegenstelle funktioniert allerdings nicht.

 

7) Unter (RAS) Eigenschaften => IP die "RAS die Kartenwahl gestatten" auf LAN extern gesetzt.

- Einwahl der Gegenstelle funktioniert nicht

- DHCP Server neu gestartet, da dieser keine ordentlichen IP Adressen zugewiesen hat (Errorlog)

- DHCP funktioniert immer noch nicht (nur bei RAS nicht) - Server Neustart

 

8.) VPN User der Anmeldung für die Gegenstelle geändert (der mit dem Assistent generierte User hat nicht funktioniert)

=> Einwahl der Gegenstelle funktioniert wieder

 

9.) Die Bindung des DHCP Server an die RAS-Clients funktioniert immer noch nicht richtig.

- Die Kartenauswahl wieder auf "RAS die Kartenwahl gestatten" umgestellt.

- Adresszuweisung auf manuell in RAS geändert und wieder zurück gestellt. System Absturz?

- DHCP Bindung in den DHCP Einstellungen auf nur LAN intern geändert

 

10.) DHCP Bindung funktioniert wieder. VPN in beiden Richtungen funktioniert

 

11.) In Bereich NAT/Basisfirewall sind keine ! Schnittstellen vorhanden.

 

12.) Wählschnittstelle auf privat gesetzt - Das Remotenetzwerk kann von den Clients nicht erreicht werden - nur vom Server

 

13.) NAT an Wählschnittstelle hinzugefügt, damit die Clients im Netz wieder Zugriff auf das Remotenetz erhalten.

Zugriff funktioniert.

 

13.) NAT (ohne Firewall) der Schnittstelle LANextern hinzugefügt - Internet funktioniert wieder.

 

14.) Firewall der Schnittstelle Lan extern hinzugefügt und die Ports TCP 1723 sowie UDP 1701 an 192.168.1.101 (LAN intern) weitergeleitet

 

15.) Die Gegenstelle kann sich nicht einwählen. Sonst funktioniert alles im Netzwerk

 

 

 

Ich habe fast den Verdacht, dass RAS nicht anerkennt das die LAn extern die Externe Schnittstelle ist. Im Assistenten steht, das man nach der Karte gefragt wird an welcher das Internet angeschlossen ist. Dies war aber nicht der Fall. An der externen Karte ist nur QoS und TCP/IP aktiviert.

 

Wie gesagt - ohne die aktivierte Firewall geht alles wunderbar.

 

Also ich weiß nicht mehr weiter und geh jetzt erst mal schlafen,

 

Bis morgen, und nochmals vielen Dank für die Geduld und Hilfe.

 

Alex

[IThome 10]

Warum nimmst Du nicht den VPN/NAT Assistenten und fügst dann händisch eine Schnittstelle für Wählen bei Bedarf hinzu. In diesem Dialog wird erstmal NAT vernünftig konfiguriert (wenn Du die richtigen Schnittstellen angibst). Es wird während der Einrichtung gefragt, welche die öffentliche Schnittstelle und welche die private Schnittstelle ist. Die Verbindung zum Router ist die NAT-Schnittstelle mit Basisfirewall und die interne die private ohne Basisfirewall. Dann erstmal den Internetzugriff testen und prüfen, welche Schnittstellen unter NAT/Basisfirewall stehen.

Danach händisch eine Schnittstelle für Wählen bei Bedarf erstellen und einen statischen Pool für die Einwahl angeben, der sich ausserhalb der internen Bereiche befindet und wieder testen.

Zum Schluss kannst Du noch die Feinabstimmung machen, z.B. dynamische Registrierung NetBIOS über TCP/IP der externen Karte deaktivieren, die Bindungsreihenfolge anpassen, die Konfiguration der RAS-Ports usw.

[xelafield 10]

Hallo,

 

ich glaube du hast recht.

 

Also ich hab jetzt gemacht was du gesagt hast:

 

- NAT/VPN Assistenten ausgeführt

- Externe Schnittstelle definiert

- Statischen Pool vergeben

- In der Firewall LAN extern sind nun die Ports 1723, 1701, 500 4500 freigeschaltet auf 127.0.0.1

- Unter IGMP sind die Schnittstellen Intern, LAN intern (Router), LAN extern (proxy)

- Internet geht

- Unter NAT sind LAN intern und intern als privat deklariert

- Der Zugriff auf das Remotenetzwerk funktioniert nicht.

- statische Route

192.168.123.0

255.255.2550

1

 

- RAS Neu gestartet

 

Jetzt hab ich mal die Firewall (DSL-Router) auf Durchzug geschaltet - Verbindung klappt noch nicht. Immer noch diese Fehlermeldung um VPN Server:

Es wurde eine Verbindung zwischen dem VPN-Server und dem VPN-Client 84.151.1.19 initiiert, aber die VPN-Verbindung konnte nicht hergestellt werden. Der wahrscheinlichste Ursache dafür ist, dass der Firewall bzw. der Router zwischen dem VPN-Server und dem VPN-Client nicht so konfiguriert ist, dass GRE-Pakete (Generic Routing Encapsulation) zugelassen sind (Protokoll 47). Stellen Sie sicher, dass die Firewalls bzw. Router zwischen dem VPN-Server und dem Internet GRE-Pakete zulassen. Stellen Sie ebenfalls sicher, dass die Firewalls bzw. Router im Netzwerk des Benutzers auch so konfiguriert sind, dass GRE-Pakete zugelassen sind. Wenn das Problem weiterhin besteht, sollte der Benutzer sich an den Internetdienstanbieter wenden, um zu ermitteln, ob der Internetdienstanbieter eventuell GRE-Pakete blockt.

 

Ich habe jetzt, damit ich weiterarbeiten kann NAT für die Wählschnittstelle aktiviert und die Fireall für LAN extern deaktiviert. Das kann ich aber wieder ändern. wie gesagt ist jetzt erst mal temporär.

 

 

Alex

 

edit:

ich glaube schön langsam nicht mehr das es am Server liegt. Könnte es nicht doch irgendwie ein Problem mit dem Zusammenspiel zwischen Router (FritzBox) und der Firewall von 2003er Server sein? Das der Router die Ports nicht so weitergibt wie in der Konfig eingestellt oder sonst was?