none
Netzwerkzugriff intern blockiert nach Aufbau VPN Verbindung RRS feed

 > 

  • Allgemeine Diskussion

  • Discussion
    Anmelden
    0
    Anmelden

    Guten Morgen,

    wir haben hier ein nicht verifizierbares Problem - einige Minuten, nachdem eine VPN Verbindung zu einem externen Server aufgebaut ist, wird das interne Netzwerk blockiert. Das heißt, wir können zwar noch Server und Rechner im eigen LAN anpingen, aber weder auf die Shares noch per "Net View SERVERNAME" zugreifen.

    Geraume Zeit, nachdem die VPN Verbindung getrennt wurde, ist der Zugriff im internen LAN wieder möglich. Es gibt leider keinerlei Events, die an der Workstation oder dem Server angezeigt werden.

    In unserem LAN wird ein aktuelles TMG eingesetzt, welches jedoch ebenfalls "nur standardkonfiguriert" ist und keine Events loggt.

    Danke für Info oder "Wegweiser"
    josch

    Freitag, 23. August 2013 10:38
    |

Alle Antworten

  • Discussion
    Anmelden
    0
    Anmelden
    Welche VPN-Software wird verwendet? Ist es egal von welchem Client aus die Verbindung aufgebaut wird? Welche Sicherheitssoftware ist installiert? Wenn die VPN-Verbindung steht, welche Netzwerkerkennung wird im Netzwerk- und Freigabecenter angezeigt?

    Servus
    Winfried

    GPOs: http://www.gruppenrichtlinien.de/
    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/

    Freitag, 23. August 2013 14:22
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Winfried,

    möglicherweise liegt/lag es daran, dass die VPN über DHCP IP Adressen bezieht und auch der DNS Server auf diesem Wege auf das externe LAN "geswitcht" wurde. Ein Test ergab, dass bei aufgebauter VPN keine interne DNS-Auflösung mehr erfolgreich war. Wir testen das gerade und ich melde mich nach Abschluss nochmals.

    Schönes Wochenende
    josch

    Freitag, 23. August 2013 18:38
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Guten Morgen,

    wir haben nun "etwas mehr Verbindung".

    Zunächst zu den o.a. Fragen:
    VPN Software - Microsoft PPTP VPN Verbinung
    Sicherheit - zwischen DC und Internet steht ein TMG
                       Kaspersky auf allen Servern/Clients
    Netzwerkerkennung bei aufgebauter VPN Verbindung - Arbeitsplatznetzwerk / kein Internetzugriff

    Nach Definition des eigenen DNS Servers in den DHCP Einstellungen der VPN Verbindung sehen wir jetzt sowohl alle Shares des DC, haben Zugriff auf den DC, aber nicht auf die anderen Server und Clients im eigenen Netz.

    Net view DC = ok
    Net View Srv2 = Systemfehler 5 / Zugriff verweigert

    Danke und Gruß
    josch

    • Bearbeitet joschl Montag, 26. August 2013 09:08
    Montag, 26. August 2013 09:03
    |
  • Discussion
    Anmelden
    0
    Anmelden
    Zunächst zu den o.a. Fragen:

    VPN Software - Microsoft PPTP VPN Verbinung
    Sicherheit - zwischen DC und Internet steht ein TMG
                       Kaspersky auf allen Servern/Clients
    Netzwerkerkennung bei aufgebauter VPN Verbindung - Arbeitsplatznetzwerk / kein Internetzugriff

    Nach Definition des eigenen DNS Servers in den DHCP Einstellungen der VPN Verbindung sehen wir jetzt sowohl alle Shares des DC, haben Zugriff auf den DC, aber nicht auf die anderen Server und Clients im eigenen Netz.

    Net view DC = ok
    Net View Srv2 = Systemfehler 5 / Zugriff verweigert

    Kaspersky zum Testen bitte auf einem betroffenen Client *rückstandsfrei* deinstallieren. D.h. auch das Removal Tool vom Hersteller benutzen. http://support.kaspersky.com/faq/?qid=208279463

    Dann noch bitte ein, bis auf Domain Namen, uneditiertes ipconfig /all vom Client *vor* einer VPN-Verbindung, und während einer VPN-Verbindung bereit stellen.

    Servus
    Winfried

    GPOs: http://www.gruppenrichtlinien.de/
    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/

    Montag, 26. August 2013 09:47
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo

    ich habe dieses Verhalten mit einem neuen Cisco VPN Client auch. Das Netzwerk wird komplett blockiert. Mit einer etwas älteren Cisco VPN Version habe ich keine Probleme.

    Gruss

    hawk

    Montag, 26. August 2013 12:44
    |
  • Discussion
    Anmelden
    0
    Anmelden

    ich habe dieses Verhalten mit einem neuen Cisco VPN Client auch. Das Netzwerk wird komplett blockiert. Mit einer etwas älteren Cisco VPN Version habe ich keine Probleme.

    Beim CISCO-Client kann man das gezielt an- oder abschalten. Ich weiß auswendig aber nicht mehr wo genau das zu finden ist/war. Auf jeden Fall im CISCO-Client. ;)

    Servus
    Winfried

    GPOs: http://www.gruppenrichtlinien.de/
    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/


    Montag, 26. August 2013 12:46
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Winfried,

    <<<Beim CISCO-Client kann man das gezielt an- oder abschalten. Ich weiß auswendig aber nicht mehr wo genau das zu finden ist/war. Auf jeden Fall im CICCO-Client. ;)>>

    ja, wenn es denn die Netzwerk Administration erlauben würde :-)

    Grüsse

    Hawk

    Montag, 26. August 2013 13:07
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Winfried,

    ex Kaspersky ipconfig vor VPN Aufbau:

    Windows-IP-Konfiguration

       Hostname  . . . . . . . . . . . . : workstation4711
       Prim„res DNS-Suffix . . . . . . . : domain.local
       Knotentyp . . . . . . . . . . . . : Hybrid
       IP-Routing aktiviert  . . . . . . : Nein
       WINS-Proxy aktiviert  . . . . . . : Nein
       DNS-Suffixsuchliste . . . . . . . : domain.local

    Ethernet-Adapter LAN-Verbindung:

       Medienstatus. . . . . . . . . . . : Medium getrennt
       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : TeamViewer VPN Adapter
       Physikalische Adresse . . . . . . : 00-FF-E9-24-8D-1B
       DHCP aktiviert. . . . . . . . . . : Ja
       Autokonfiguration aktiviert . . . : Ja

    Ethernet-Adapter LAN intern:

       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Realtek PCIe GBE Family Controller
       Physikalische Adresse . . . . . . : 00-19-99-3A-40-BC
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja
       Verbindungslokale IPv6-Adresse  . : fe80::ad2e:8651:5a0d:d835%10(Bevorzugt)
       IPv4-Adresse  . . . . . . . . . . : 192.168.100.22(Bevorzugt)
       Subnetzmaske  . . . . . . . . . . : 255.255.255.224
       Standardgateway . . . . . . . . . : 192.168.100.2
       DHCPv6-IAID . . . . . . . . . . . : 234887577
       DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-14-CC-A8-87-00-19-99-3A-40-BC
       DNS-Server  . . . . . . . . . . . : 192.168.100.1
       NetBIOS ber TCP/IP . . . . . . . : Aktiviert

    Tunneladapter isatap.{E9248D1B-14E9-47FD-B53D-CFBFD6E3AB24}:

       Medienstatus. . . . . . . . . . . : Medium getrennt
       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
       Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja

    Tunneladapter Teredo Tunneling Pseudo-Interface:

       Medienstatus. . . . . . . . . . . : Medium getrennt
       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
       Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja

    Tunneladapter isatap.{1C7773F9-93C1-48A2-B33C-F0624C13761C}:

       Medienstatus. . . . . . . . . . . : Medium getrennt
       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #2
       Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja

    und nach VPN Aufbau:

    Windows-IP-Konfiguration

       Hostname  . . . . . . . . . . . . : workstation4711
       Prim„res DNS-Suffix . . . . . . . : domain.local
       Knotentyp . . . . . . . . . . . . : Hybrid
       IP-Routing aktiviert  . . . . . . : Nein
       WINS-Proxy aktiviert  . . . . . . : Nein
       DNS-Suffixsuchliste . . . . . . . : domain.local

    PPP-Adapter VPN blahblah:

       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : VPN blahblah
       Physikalische Adresse . . . . . . :
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja
       IPv4-Adresse  . . . . . . . . . . : 192.168.10.18(Bevorzugt)
       Subnetzmaske  . . . . . . . . . . : 255.255.255.255
       Standardgateway . . . . . . . . . :
       DNS-Server  . . . . . . . . . . . : 192.168.100.1
       NetBIOS ber TCP/IP  . . . . . . . : Aktiviert

    Ethernet-Adapter LAN-Verbindung:

       Medienstatus. . . . . . . . . . . : Medium getrennt
       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : TeamViewer VPN Adapter
       Physikalische Adresse . . . . . . : 00-FF-E9-24-8D-1B
       DHCP aktiviert. . . . . . . . . . : Ja
       Autokonfiguration aktiviert . . . : Ja

    Ethernet-Adapter LAN PPCW:

       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Realtek PCIe GBE Family Controller
       Physikalische Adresse . . . . . . : 00-19-99-3A-40-BC
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja
       Verbindungslokale IPv6-Adresse  . : fe80::ad2e:8651:5a0d:d835%10(Bevorzugt)
       IPv4-Adresse  . . . . . . . . . . : 192.168.100.22(Bevorzugt)
       Subnetzmaske  . . . . . . . . . . : 255.255.255.224
       Standardgateway . . . . . . . . . : 192.168.100.2
       DHCPv6-IAID . . . . . . . . . . . : 234887577
       DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-14-CC-A8-87-00-19-99-3A-40-BC
       DNS-Server  . . . . . . . . . . . : 192.168.100.1
       NetBIOS ber TCP/IP . . . . . . . : Aktiviert

    Tunneladapter isatap.{E9248D1B-14E9-47FD-B53D-CFBFD6E3AB24}:

       Medienstatus. . . . . . . . . . . : Medium getrennt
       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
       Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja

    Tunneladapter Teredo Tunneling Pseudo-Interface:

       Medienstatus. . . . . . . . . . . : Medium getrennt
       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
       Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja

    Tunneladapter isatap.{1C7773F9-93C1-48A2-B33C-F0624C13761C}:

       Medienstatus. . . . . . . . . . . : Medium getrennt
       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #2
       Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja

    Tunneladapter isatap.{BEB902F0-20DE-4902-B029-4E841A916D25}:

       Medienstatus. . . . . . . . . . . : Medium getrennt
       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #3
       Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja

    P.S. Teamviewer VPN wird hier nicht verwendet

    Danke und Gruß
    josch

    Montag, 26. August 2013 13:26
    |
  • Discussion
    Anmelden
    0
    Anmelden

    <<<Beim CISCO-Client kann man das gezielt an- oder abschalten. Ich weiß auswendig aber nicht mehr wo genau das zu finden ist/war. Auf jeden Fall im CICCO-Client. ;)>>

    ja, wenn es denn die Netzwerk Administration erlauben würde :-)

    Tja, man kann nicht alles haben. ;)

    Servus
    Winfried

    GPOs: http://www.gruppenrichtlinien.de/
    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/

    Montag, 26. August 2013 17:57
    |
  • Discussion
    Anmelden
    0
    Anmelden
    Hast du in den Erweiterten TCP/IP Einstellungen den Haken drin: Standardgateway für das Remotenetzwerk setzen.

    Servus
    Winfried

    GPOs: http://www.gruppenrichtlinien.de/
    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/

    Montag, 26. August 2013 18:22
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo,

    nein - hatten wir bei den VPN Verbindungen generell nicht.
    Dennoch - getestet, allerdings mit dem gleichen Ergebnis.
    Das hat immer sofortige Auswirkung (ohne Verzögerung):

    Datei-Explorer SRV2 - Shares ok
    VPN aufgebaut         - Shares nicht mehr im Zugriff
    VPN getrennt            - Shares wieder ok

    Gruß
    josch

    Montag, 26. August 2013 21:25
    |
  • Discussion
    Anmelden
    0
    Anmelden

    nein - hatten wir bei den VPN Verbindungen generell nicht.
    Dennoch - getestet, allerdings mit dem gleichen Ergebnis.
    Das hat immer sofortige Auswirkung (ohne Verzögerung):

    Datei-Explorer SRV2 - Shares ok
    VPN aufgebaut         - Shares nicht mehr im Zugriff
    VPN getrennt            - Shares wieder ok

    Seit wann besteht das Problem? Schon immer? Was wurde zum Zeitpunkt X verändert?

    Servus
    Winfried

    GPOs: http://www.gruppenrichtlinien.de/
    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/

    Montag, 26. August 2013 21:28
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Gute Frage! - Die nächste bitte  ;)

    Leider können wir das nicht wirklich fixieren, weil die VPN Benutzer das Blockieren der Netzwerk-Laufwerke nicht sofort bemerkten resp. nicht sofort mitteilten.

    Da es alle Clients betrifft ...

    - kein Update / neue Version eines individuell installierten Programms
    - kein Kaspersky Update (heute auf einem Client removed)
    - Microsoft Update auf Clients oder TMG (halte ich für sehr unwahrscheinlich)

    Gruß
    josch

    Montag, 26. August 2013 21:49
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Leider können wir das nicht wirklich fixieren, weil die VPN Benutzer das Blockieren der Netzwerk-Laufwerke nicht sofort bemerkten resp. nicht sofort mitteilten.

    Da es alle Clients betrifft ...

    - kein Update / neue Version eines individuell installierten Programms
    - kein Kaspersky Update (heute auf einem Client removed)
    - Microsoft Update auf Clients oder TMG (halte ich für sehr unwahrscheinlich)

    Den sauberen Neustart hast Du schon ausprobiert? Mit Windows 7 einen sauberen Start / Neustart durchführen

    Ansonsten W7 neu installieren auf einem Testclient, SP1 drauf, testen, Updates installieren, testen.

    Servus
    Winfried

    GPOs: http://www.gruppenrichtlinien.de/
    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/

    Montag, 26. August 2013 21:52
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Nachtrag ...

    Das Problem scheint sich auf Windows 7 zu beschränken, bei XP möglicherweise nicht der Fall. Ich lasse die nächsten Stunden eine VPN auf einer XP Workstation connected und werde prüfen, ob sich dort etwas bezüglich der internen LAN Konnektivität ändert.

    josch

    Montag, 26. August 2013 21:57
    |
  • Discussion
    Anmelden
    0
    Anmelden
    Einfaches Problem, einfache Lösung (meistens jedenfalls): Rasphone.pbk editieren, "UseRasCredentials=0". Geht sogar per GPO (GPP "INI-Dateien").

    Martin

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))

    Restore the forum design - my user defined Cascading Style Sheet!

    Donnerstag, 29. August 2013 11:01
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Martin,

    auf den ersten Blick (Test) scheint diese Einstellung tatsächlich die "einfache" Lösung gewesen zu sein. Vielleicht für den Unwissenden noch ein Tipp, was genau UseRasCredentials=1 auslöst, um die internen LAN-Verbindungen zu stören? - Ich finde nun zwar tonnenweise Hinweise zu "... set to =0 ...", aber keine Erläuterung dazu.

    Auf jeden Fall danke - auch Richtung Winfried für die Unterstützung!

    josch

    Donnerstag, 29. August 2013 13:58
    |
  • Discussion
    Anmelden
    0
    Anmelden

    auf den ersten Blick (Test) scheint diese Einstellung tatsächlich die "einfache" Lösung gewesen zu sein. Vielleicht für den Unwissenden noch ein Tipp, was genau UseRasCredentials=1 auslöst, um die internen LAN-Verbindungen zu stören? - Ich finde nun zwar tonnenweise Hinweise zu "... set to =0 ...", aber keine Erläuterung dazu.



    Benutze zur Authentifizierung die Credentials der bestehenden RAS-Verbindung. Zumindest deute ich das so. Kannte ich auch noch nicht. @Martin, Danke. ;)

    Servus
    Winfried

    GPOs: http://www.gruppenrichtlinien.de/
    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/

    Donnerstag, 29. August 2013 16:48
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Jepp - Erläuterung:. Default ist "userascredentials=1". Das bringt Windows dazu, nach dem Herstellen einer (Windows-) VPN-Verbindung für ALLE Zugriffe den RAS-User zu verwenden. Der ist aber oft nicht identisch mit dem Domänenbenutzer -> alle internen Shares sind nicht mehr zugreifbar.

    OT: Irgendwie muß ich mir ja den MVP auch verdienen - da muss ich ja ein paar Dinge wissen, die andere nicht wissen <gggg> (SCNR)

    Martin

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))

    Restore the forum design - my user defined Cascading Style Sheet!

    Donnerstag, 29. August 2013 18:49
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo,

    Klasse! - und danke MVP ;)

    Gruß
    josch

    Donnerstag, 29. August 2013 20:37
    |