locked
VPN - Sicherheit RRS feed

  • Frage

  • Hallo zusammen.

    Ist-Zustand :

    Ist der User nicht über VPN angemeldet kann er sich im Internet frei bewegen.

    Soll-Zustand:

    User soll wenn keine VPN Verbindung besteht nur Teamviewer können und VPN

    Ich habe jetzt eine GPO erstellt, die über die Windows-Firewall sämtlich Verbindungen blockiert außer VPN und Teamviewer. Jedoch erkennt die Netzwerkidentifizierung jetzt die VPN Verbindung als öffentliches Netz und nicht mehr als Domänen-Netzwerk. Welchen Port muss ich freischalten bzw. generell machen damit die Verbindung wieder das Domänennetzwerk erkennt ? Den sobald ich Firewall ausmache erkennt er das Domänennetzwerk richtig, daher muss es eine Freigabe in der Firewall sein.

    Für eine andere Lösung um die VPN Sicherheit zu gewähren, das die User ohne VPN nichts machen dürfen, bin ich natürlich offen.

    Danke schonmal

    Dienstag, 29. Juli 2014 07:46

Antworten

  • So .. nach langer Zeit mit Verzweiflung ist der Fehler gefunden und ich wollte hier noch kurz Rückmeldung geben und nochmals danke sagen für die Hilfe.

    Es war der Avira !!! Der hat in seiner Einstellung die Windows Firewall überschrieben, daher wurden die GPOs und die Regeln nicht richtig gezogen.

    Nachdem wir die Firewall im Avira (interne von Avira und die Einstellungen für die Windows-Firewall) ausgeschaltet hatten funktioniert alles zu 100%.

    Gruß

    Rene

    Dienstag, 12. August 2014 06:53

Alle Antworten

  • Hi,

    Am 29.07.2014 um 09:46 schrieb rschneider80:

    Jedoch erkennt die Netzwerkidentifizierung jetzt die VPN Verbindung
    als öffentliches Netz und nicht mehr als Domänen-Netzwerk.

    Das Problem ist:
    Microsoft unterscheidet die Firewall Konfigurationen nicht anhand des Adapters über den die Verbindung aufgebaut wird, sondern anhand des erkannten Profils.
    Das Profil ist unabhängig vom Adapter und kann von einem beliebigen verwendet werden.

    Du musst im öffentlichen Profil DNS, LDAP und Kerberos zulassen, damit das System überhaupt bei "Firewall an" Kontakt zum DC aufnehmen kann, dann erkennt wo es ist und auf "Domänen Profil" umschaltet.
    Die Ziele auf die du den Zugriff erlaubst kannst du widerum auf deine DCs einschränken.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Dienstag, 29. Juli 2014 08:01
  •  
    > Welchen Port muss ich freischalten bzw. generell machen damit die
    > Verbindung wieder das Domänennetzwerk erkennt ?
     
    DNS, Kerberos, LDAP, SMB (53, 88, 389, 445) sollte reichen. Der Client
    muß einen DC auf der Verbindung finden, damit sie zum Domänennetzwerk
    gehört.
     

    Martin

    Mal ein GUTES Buch über GPOs lesen?

    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 :))
    Dienstag, 29. Juli 2014 09:46
  • Ja cool. dann werde ich das direkt mal austesten.

    Das mit den Adaptern ist mir ja bekannt, deswegen will ich es ja über die Netzwerkidentifizierung lösen.

    Gebe  später mal bescheid. aber schon mal danke für die Hilfe

    Dienstag, 29. Juli 2014 12:06
  • Hi,

    Am 29.07.2014 um 11:46 schrieb "Martin Binder [MVP]":

    DNS, Kerberos, LDAP, SMB (53, 88, 389, 445) sollte reichen.

    SMB ist ausnahmsweise nicht dabei ;-)

    Ich habe hier nur die anderen 3 drin ...

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Dienstag, 29. Juli 2014 13:28
  • Leider klappt das ganze nicht so richtig. Ich gehe mal ins Detail was ich alles eingestellt habe über GPO:

    Firewall für Domänennetzwerk --> offen

    Firewall für Privates/Öffentliches Profil --> Alle blockieren

    Ausnahmen zulassen --> DHCP(67,68) DNS(53) Kerberos(88) LDAP(389) und die Anwendung Teamviewer.

    Wenn ich mich am Client anmelde bekomme ich jetzt eine IP-Adresse und kann mich anschließend über IKEV2 mit der Firma verbinden. Jedoch steht hinter der VPN Verbindung nach längerer Zeit Öffentliches Netzwerk.

    Mache ich das ganze ohne Firewall steht hinter der VPN Verbindung Domänennetzwerk.

    Würde ich es schaffen mit Firewall Domänennetzwerk zu bekommen wäre mein Problem gelöst.

    Scheint so das noch Port-Freigaben fehlen. leider weiß ich nicht genau welche und ich habe schon lange gegoogelt.


    Dienstag, 29. Juli 2014 14:16
  •  
    > DHCP(67,68) DNS(53) Kerberos(88) LDAP(389)
    TCP, UDP oder beides?
     

    Martin

    Mal ein GUTES Buch über GPOs lesen?

    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 :))
    Dienstag, 29. Juli 2014 16:11
  • Am 29.07.2014 um 18:11 schrieb "Martin Binder [MVP]":

    DHCP(67,68) DNS(53) Kerberos(88) LDAP(389)

    TCP, UDP oder beides?

    Ich habe 5 Einträge mit jeweils definierten Zielen:
    DNS: TCP und UDP
    Kerberos: TCP
    LDAP: TCP und UDP

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Dienstag, 29. Juli 2014 18:28
  •  
    > Kerberos: TCP
     
    Solange der TO nicht MaxPacketSize gesetzt hat, muss da per Default auch
    UDP rein :)
     
     

    Martin

    Mal ein GUTES Buch über GPOs lesen?

    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 :))
    Mittwoch, 30. Juli 2014 07:18
  • ok. die anderen Ports hatte ich jetzt schon als UDP mit drinnen. Werde den Kerberos mal nachziehen und testen. gebe dann später bescheid.

    Danke schon mal für die vielen Tipps

    Mittwoch, 30. Juli 2014 10:29
  • So irgendwie klappt es leider immer noch nicht. Denke aber das der Fehler woanders liegt.

    Habe mich mal http://technet.microsoft.com/de-de/library/dd772723(v=ws.10).aspx an diese Port Freigaben gehalten, die ja quasi decken mit denen die wir vorher genannt hatten.

    Jetzt habe ich mal TCP/UDP Port 1-65535 freigeschaltet und es geht immer noch nicht, daher glaube ich, dass ich den Fehler an der falschen Stelle suche.

    Morgens geht's weiter.

    Mittwoch, 30. Juli 2014 15:30
  • So .. nach langer Zeit mit Verzweiflung ist der Fehler gefunden und ich wollte hier noch kurz Rückmeldung geben und nochmals danke sagen für die Hilfe.

    Es war der Avira !!! Der hat in seiner Einstellung die Windows Firewall überschrieben, daher wurden die GPOs und die Regeln nicht richtig gezogen.

    Nachdem wir die Firewall im Avira (interne von Avira und die Einstellungen für die Windows-Firewall) ausgeschaltet hatten funktioniert alles zu 100%.

    Gruß

    Rene

    Dienstag, 12. August 2014 06:53