androxin
Sep 14, 2015, updated at Sep 15, 2015 (UTC)
view3581
view19
0
Goto Top

VPN Tunnel steht, leitet aber keine Pakete durch

GermansolvedQuestionLAN, WAN, WirelessNetworks
Moin,

ich habe einen jungfräulichen (ausschließlich die für Routing/RAS notwendigen Rollen installiert) Root Server mit Windows Server 2012. Diesen möchte ich gerne als PPTP VPN Server konfigurieren und bin dabei auf eine für mich neue Hürde gestoßen.
Ja, ich weiß, dass PPTP nicht empfehlenswert ist usw. Darum soll es aber hier nicht gehen, da es sich um einen Labor-/Trainingsaufbau handelt.

Da der Server nur eine NIC hat, habe ich beim "Routing und RAS"-Konfigurieren die "Benutzerdefinierte Konfiguration" und "VPN--Zugriff" gewählt. Als IPv4 Bereich für die VPN Verbindungen habe ich 172.17.20.2-172.17.20.254 gewählt. Die IP des Root Servers und die IP des PPTP Clients liegen in komplett anderen Bereichen.

In der Benutzerverwaltung des Servers habe ich einem lokalen Benutzerkonto unter "Einwählen"/"Netzwerkzugriffsberechtigung" den Zugriff gestattet.


Als Client dient ein Windows 10. Dort habe ich die öffentliche IP und die Zugangsdaten im VPN Assistenten hinterlegt und keine weiteren Einstellungen vorgenommen.

Der Tunnel kann mit diesen Einstellungen aufgebaut werden. Den PPTP Adaptern werden die richtigen IPs (Client z.B. 172.17.20.3, Server 172.17.20.2) zugewiesen. Die DNS-Server IPs stimmen auch.

In der Vergangenheit hatte ich mit ähnlich simplen Laboraufbauten u. a. mit Win Server 2008 R2, pfSense und WatchGuard keine Probleme.
Jetzt hat sich mir allerdings die Herausforderung gestellt, dass der Tunnel zwar aufgebaut wird, aber z. B. Pings keinen Weg dadurch finden.

Auf dem Server bekommt man keine Antwort wenn man die 172.17.20.3 anpingt. Auf dem Client, verläuft ein Ping zu 172.17.20.2 im Sande. Auch Richtung Internet geht nicht's durch den Tunnel. Der IPv4 Adapter "Intern" auf dem Server (mit der IP 172.17.20.2) zeigt aber trotzdem empfangene und gesendete Bytes an.


Die Firewalls (Server- und Clientseitig) habe ich testweise komplett ausgeschaltet. Brachte keine Besserung.
Andere PPTP bzw. VPN Verbindungen im allgemeinen funktionieren mit dem Windows 10 Client wunderbar.


Leider bin ich mit meinem Latein am Ende und meine Glaskugel möchte mir auch keine weiteren Einstellschrauben verraten.
Habt ihr noch einen Vorschlag an welchen Ecken man noch einmal schauen könnte?
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 282864

Url: https://administrator.de/contentid/282864

Printed on: April 18, 2024 at 08:04 o'clock

19 Comments
Latest comment
Goto Top
Mitglied: 114757
Solution 114757 Sep 14, 2015, updated at Sep 15, 2015 at 13:56:54 (UTC)
Goto Top
Moin,
ich vermute das stimmt irgendwo eine Route nicht, poste mal route print von Client und Server.

Zum Internetzugriff über das VPN bei einem Server mit einem Interface guckst du hier eine schöne Anleitung von @colinardo zum RRAS
VPN Einrchtung unter Windows Server 2012

Gruß jodel32
Member: aqui
Solution aqui Sep 15, 2015 updated at 13:56:52 (UTC)
Goto Top
Als IPv4 Bereich für die VPN Verbindungen habe ich 172.17.20.2-172.17.20.254
Das sagt gar nicht aus... Welche Maske denn ??
Als Client dient ein Windows 10.
Dort dann wenigstens den PPTP Betrieb eingestellt und nicht auf "Auto" belassen ??
aber z. B. Pings keinen Weg dadurch finden.
Das Ping (ICMP Protokoll) ab Win 7 defaultmässig von der lokalen Firewall geblockt wird ist dir klar ?
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Auch Richtung Internet geht nicht's durch den Tunnel.
Das geht auch einzig nur wenn du das Default Gateway komplett auf den Tunnel umbiegst. Das macht man mit einem "Konfighaken" in den Client Settings !! Wie erklärt dir dieses Forumstutorial im Kapitel "Clients":
VPNs einrichten mit PPTP
Member: Androxin
Androxin Sep 15, 2015 updated at 10:58:55 (UTC)
Goto Top
Vielen Dank für die vielen Denkanstöße.

Ich habe den VPN Server noch einmal anhand des Tutorials neu aufgebaut. Nun auch inkl. NAT, welches ich vorher nicht eingerichtet hatte. Es funktioniert trotzdem nicht. face-sad


Zu den Routen:
Client
192.168.1.20 - IP Adresse des Windows 10 Clients
172.17.20.8 - IP Adresse des PPTP Adapters
IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.20   4235
          0.0.0.0          0.0.0.0   Auf Verbindung       172.17.20.8     11
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1   4531
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1   4531
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1   4531
      172.17.20.8  255.255.255.255   Auf Verbindung       172.17.20.8    266
    www.xxx.yyy.ABC  255.255.255.255      192.168.1.1     192.168.1.20   4236
      192.168.1.0    255.255.255.0   Auf Verbindung      192.168.1.20   4491
     192.168.1.20  255.255.255.255   Auf Verbindung      192.168.1.20   4491
    192.168.1.255  255.255.255.255   Auf Verbindung      192.168.1.20   4491
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1   4531
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.1.20   4491
        224.0.0.0        240.0.0.0   Auf Verbindung       172.17.20.8     11
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1   4531
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.1.20   4491
  255.255.255.255  255.255.255.255   Auf Verbindung       172.17.20.8    266
===========================================================================
Ständige Routen:
  Keine



Server
www.xxx.yyy.ABC - Öffentliche IP des Server. IP des Ethernet Adapters
www.xxx.yyy.1 - Gateway Richtung Internet
172.17.20.2 - IP des PPTP-Adapters

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      www.xxx.yyy.1    www.xxx.yyy.ABC     20
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
      169.254.0.0      255.255.0.0   Auf Verbindung       172.17.20.2    306
     169.254.0.22  255.255.255.255   Auf Verbindung       172.17.20.2    306
  169.254.255.255  255.255.255.255   Auf Verbindung       172.17.20.2    306
      172.17.20.2  255.255.255.255   Auf Verbindung       172.17.20.2    306
      www.xxx.yyy.0    255.255.255.0   Auf Verbindung     www.xxx.yyy.ABC    266
    www.xxx.yyy.ABC  255.255.255.255   Auf Verbindung     www.xxx.yyy.ABC    266
    www.xxx.yyy.255  255.255.255.255   Auf Verbindung     www.xxx.yyy.ABC    266
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung     www.xxx.yyy.ABC    266
        224.0.0.0        240.0.0.0   Auf Verbindung       172.17.20.2    306
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
  255.255.255.255  255.255.255.255   Auf Verbindung     www.xxx.yyy.ABC    266
  255.255.255.255  255.255.255.255   Auf Verbindung       172.17.20.2    306
===========================================================================
Ständige Routen:
  Netzwerkadresse          Netzmaske  Gatewayadresse  Metrik
          0.0.0.0          0.0.0.0      www.xxx.yyy.1      10
===========================================================================



Als Maske kommt beim Client die 255.255.255.255 an. So wie bei den anderen konfigurierten PPTP VPN Verbindungen auch.


Der VPN Typ ist auf PPTP gestellt. Die Anpassung wirkt sich aber nicht aus, da PPTP bei "Auto" auch richtig erkannt wird.


Ja, mir ist klar, dass ICMP per default geblockt wird. Es ist in der Firewall freigegeben. Abgesehen davon, habe ich die Firewall ja auch zeitweise komplett deaktiviert.


Dank eines Bugs in Windows 10 kommt man nicht in die erweiterten TCP/IP Einstellungen. Button ist klickbar, aber nichts passiert.
Die Powershell hat mir aber verraten, dass SplitTunneling auf "False" gesetzt ist. Das ist so korrekt. Schließlich soll ja alles durch den Tunnel.
Mitglied: 114757
Solution 114757 Sep 15, 2015 updated at 13:56:47 (UTC)
Goto Top
169.254.0.0 255.255.0.0 Auf Verbindung 172.17.20.2 306
169.254.0.22 255.255.255.255 Auf Verbindung 172.17.20.2 306
169.254.255.255 255.255.255.255 Auf Verbindung 172.17.20.2 306
Die APIPA Adressen auf dem Server gefallen mir da gar nicht ...poste bitte noch die Ausgabe von ipconfig /all des Servers.

Und du hast auf dem Client eine Route für xx.xx.xx.137 gesetzt ?? und auf dem Server ist ebenfalls ein Subnetz aus diesem Bereich xx.xx.xx.0. Diese Route auf dem Client wäre ebenfalls falsch wenn du es über den Tunnel erreichen wolltest.
Member: Androxin
Androxin Sep 15, 2015 at 11:03:18 (UTC)
Goto Top
Nimm mal bitte die IP Adresse und das Subnetz aus deinem Kommentar.


Ich kann nicht nachvollziehen woher die APIPA Adressen stammen. Ipconfig zeigt sie jedenfalls nicht an.

Ich habe keine Routen per Hand gesetzt. Sind alles Windows-Wizard-Standardeinstellungen.
Die von dir angesprochene Route wird übrigens automatisch erstellt, wenn Windows eine VPN Verbindung aufbaut. Das passiert auch bei allen anderen konfigurierten Verbindungen.
Mitglied: 114757
Solution 114757 Sep 15, 2015 updated at 13:56:41 (UTC)
Goto Top
Zitat von @Androxin:
Nimm mal bitte die IP Adresse und das Subnetz aus deinem Kommentar.
OK, done ...
Ich kann nicht nachvollziehen woher die APIPA Adressen stammen. Ipconfig zeigt sie jedenfalls nicht an.

Ich habe keine Routen per Hand gesetzt. Sind alles Windows-Wizard-Standardeinstellungen.
Die von dir angesprochene Route wird übrigens automatisch erstellt, wenn Windows eine VPN Verbindung aufbaut. Das passiert auch bei allen anderen konfigurierten Verbindungen.
Dann liegts wohl auch an Windows 10. Ein weiterer Grund von PPTP Abstand zu nehmen face-wink wird wohl von MS nicht mehr gepflegt, sieht man ja am Bug das man noch nicht mal mehr den Dialog öffnen kann.
Checke erst mal die anderen VPN-Protokolle, ob die ein ähnliches Verhalten an den Tag legen.

Wireshark sollte ebenfalls etwas mehr Klarheit in die Angelegenheit bringen.
Member: Androxin
Androxin Sep 15, 2015 updated at 11:54:20 (UTC)
Goto Top
Zitat von @114757:

Dann liegts wohl auch an Windows 10. Ein weiterer Grund von PPTP Abstand zu nehmen face-wink wird wohl von MS nicht mehr gepflegt, sieht man ja am Bug das man noch nicht mal mehr den Dialog öffnen kann.
Checke erst mal die anderen VPN-Protokolle, ob die ein ähnliches Verhalten an den Tag legen.

Ich habe einige PPTP/IKEv2 VPN Verbindungen unter Windows 10, die alle genau das machen was sie sollen.


Wireshark sollte ebenfalls etwas mehr Klarheit in die Angelegenheit bringen.

Ja.... Es ist immer das gleiche. Wie soll einem geholfen werden, wenn man nicht mal die simpelsten Infos recherchiert.

Test:
- VPN Verbindung aufgebaut
- Ping vom Windows 10 Client zu google.de (173.194.113.159)
- ICMP Paket kommt auf dem VPN Server an
778037c70d9f7bed0a6107884147a130
Mehr passiert dann aber nicht.

Ein Ping direkt vom VPN Server zu besagter IP klappt.

Auch das ganze andere Netzwerkgerödel vom VPN Client kommt am Server an. Windows 10 scheint daher aus dem Schneider zu sein. face-wink


Auf dem Server müsste bei aktiver VPN Verbindung doch eigentlich noch eine Route, wie folgt, auftauchen, richtig?
 172.17.20.8  255.255.255.255       172.17.20.8       172.17.20.2     31
Mitglied: 114757
Solution 114757 Sep 15, 2015 updated at 13:56:32 (UTC)
Goto Top
Ist das IP-Routing auf dem Server aktiv ?
Auf dem Server müsste bei aktiver VPN Verbindung doch eigentlich noch eine Route, wie folgt, auftauchen, richtig?
Muss ich nachher mal im Testaufbau nachstellen wie Windows das mit dem expliziten vergebenen Subnetz für die VPN Clients macht, melde mich dann nochmal wie es korrekt aussehen muss.
Eine Route in dieses Netz ist oben zumindest nicht ersichtlich weswegen die Pakete am Server vermutlich fehlgeleitet werden.
Mitglied: 114757
Solution 114757 Sep 15, 2015 updated at 13:56:24 (UTC)
Goto Top
Also hier sieht es so auf dem Server aus:
Der Server bekommt in dem virtuellen VPN-Subnetz die .2 und der Client hat die .3 zugewiesen bekommen. Externes IF des Servers hat hier die 192.168.1.21 (VM Umgebung)
IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.21    266
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
      172.17.20.2  255.255.255.255   Auf Verbindung       172.17.20.2    286
      172.17.20.3  255.255.255.255      172.17.20.3      172.17.20.2     31
      192.168.1.0    255.255.255.0   Auf Verbindung      192.168.1.21    266
     192.168.1.21  255.255.255.255   Auf Verbindung      192.168.1.21    266
    192.168.1.255  255.255.255.255   Auf Verbindung      192.168.1.21    266
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.1.21    266
        224.0.0.0        240.0.0.0   Auf Verbindung       172.17.20.2    286
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.1.21    266
  255.255.255.255  255.255.255.255   Auf Verbindung       172.17.20.2    286
===========================================================================

Der Windows 10 Client hat folgende Routing-Tabelle. Habe hier jetzt Split-Tunneling aktiv also kein Gateway über den Tunnel (kann ich aber noch nachliefern wenn du willst -edit siehe weiter unten):
IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.35     10
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
       172.17.0.0      255.255.0.0      172.17.20.2      172.17.20.3     11
      172.17.20.3  255.255.255.255   Auf Verbindung       172.17.20.3    266
      192.168.1.0    255.255.255.0   Auf Verbindung      192.168.1.35    266
     192.168.1.21  255.255.255.255   Auf Verbindung      192.168.1.35     11
     192.168.1.35  255.255.255.255   Auf Verbindung      192.168.1.35    266
    192.168.1.255  255.255.255.255   Auf Verbindung      192.168.1.35    266
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.1.35    266
        224.0.0.0        240.0.0.0   Auf Verbindung       172.17.20.3    266
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.1.35    266
  255.255.255.255  255.255.255.255   Auf Verbindung       172.17.20.3    266
===========================================================================
Verbindung läuft problemlos...

e5749eccb5fe78f158daa99b8e800432

Nachtrag: Hier noch die Routing-Tabelle des Clients wenn die Internet-Verbindung über den Tunnel läuft
(NAT auf dem externen IF des Servers aktiv)
Man sieht das DefaultGW läuft jetzt über das VPN-Interface, wegen der niedrigeren Metrik:
0.0.0.0          0.0.0.0   Auf Verbindung       172.17.20.3     11
Pings und Tracert bestätigen mir das der Traffic erfolgreich über den Tunnel läuft.
IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.35   4235
          0.0.0.0          0.0.0.0   Auf Verbindung       172.17.20.3     11
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1   4531
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1   4531
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1   4531
      172.17.20.3  255.255.255.255   Auf Verbindung       172.17.20.3    266
      192.168.1.0    255.255.255.0   Auf Verbindung      192.168.1.35   4491
     192.168.1.21  255.255.255.255   Auf Verbindung      192.168.1.35   4236
     192.168.1.35  255.255.255.255   Auf Verbindung      192.168.1.35   4491
    192.168.1.255  255.255.255.255   Auf Verbindung      192.168.1.35   4491
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1   4531
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.1.35   4491
        224.0.0.0        240.0.0.0   Auf Verbindung       172.17.20.4     11
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1   4531
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.1.35   4491
  255.255.255.255  255.255.255.255   Auf Verbindung       172.17.20.4    266
===========================================================================

Wie schon vermutet sind bei dir irgendwo Probleme mit den APIPA-Adressen, woher die herkommen hmmm?? Irgendwas läuft da noch auf dem Server krumm.
Member: Androxin
Androxin Sep 15, 2015 at 12:46:04 (UTC)
Goto Top
Bis auf die Zeile
      172.17.20.3  255.255.255.255      172.17.20.3      172.17.20.2     31
und die APIPA IP Adressen auf dem Server sehen die Routing Tabellen bei mir identisch aus.
Warum fehlt diese Zeile? Warum wird die nicht automatisch erstellt?

Im Dialogfenster für die IPv4 Adresszuweisung fehlt bei mir übrigens das Dropdown Feld "Adapter"...
Mitglied: 114757
114757 Sep 15, 2015 updated at 12:55:32 (UTC)
Goto Top
Zitat von @Androxin:
Warum fehlt diese Zeile? Warum wird die nicht automatisch erstellt?
Wenn du mal alle deine RRAS Settings postest würde das vielleicht helfen, aber so "Glasskugel" ...
Im Dialogfenster für die IPv4 Adresszuweisung fehlt bei mir übrigens das Dropdown Feld "Adapter"...
hmm ? Vielleicht weil du nur ein einziges Interface hast.
Member: Androxin
Androxin Sep 15, 2015 at 12:59:32 (UTC)
Goto Top
Zitat von @114757:

Zitat von @Androxin:
Warum fehlt diese Zeile? Warum wird die nicht automatisch erstellt?
Wenn du mal alle deine RRAS Settings postest würde das vielleicht helfen, aber so "Glasskugel" ...

fff616d3e609e3f4c4bd35b0589ce0a2
9305e26252f4c69df23b27eb5c03a9df
0d9515dc36e7eb22a115f174e2104845
004dc8924775ffcd7d44440fbfcfc517
77cc8cfc374b8e10dc4b2cca8587f1e8
20635ab1ae7d2fa042c545b8b39d7121

Alles wovon ich keinen Screenshot gemacht habe, habe ich auch nicht angefasst.
Mitglied: 114757
Solution 114757 Sep 15, 2015 updated at 13:56:15 (UTC)
Goto Top
Existiert unter DHCP ein Relay-Agent für die Schnittstelle Intern ?

Was sagt ein netsh int ipv4 show addresses ?
Member: Androxin
Androxin Sep 15, 2015 at 13:20:30 (UTC)
Goto Top
Zitat von @114757:

Existiert unter DHCP ein Relay-Agent für die Schnittstelle Intern ?

Jetzt ja. Habe mal einen hinzugefügt.
3bae78f0a118fd29f661ea9ee6d5f457
Hat aber auch nichts an der Gesamtsituation geändert.



Was sagt ein netsh int ipv4 show addresses ?

Konfiguration der Schnittstelle "RAS (Dial In) Interface"  
    DHCP aktiviert:                       Nein
    IP-Adresse:                           172.17.20.2
    Subnetzpräfix:                        172.17.20.2/32 (Maske 255.255.255.255)

    Schnittstellenmetrik:                      50

Konfiguration der Schnittstelle "Ethernet"  
    DHCP aktiviert:                       Nein
    IP-Adresse:                           www.xxx.yyy.137
    Subnetzpräfix:                        www.xxx.yyy.0/24 (Maske 255.255.255.0)
    Standardgateway:                      www.xxx.yyy.1
    Gatewaymetrik:                        10
    Schnittstellenmetrik:                      10

Konfiguration der Schnittstelle "Loopback Pseudo-Interface 1"  
    DHCP aktiviert:                       Nein
    IP-Adresse:                           127.0.0.1
    Subnetzpräfix:                        127.0.0.0/8 (Maske 255.0.0.0)
    Schnittstellenmetrik:                      50
Mitglied: 114757
Solution 114757 Sep 15, 2015 updated at 13:55:25 (UTC)
Goto Top
Hast du schon mal den RRAS deaktiviert dann die RRAS Rolle komplettt entfernt, den Server neu gestartet und dann erneut installiert und konfiguriert ?
Member: Androxin
Androxin Sep 15, 2015 updated at 13:56:03 (UTC)
Goto Top
Zitat von @114757:

Hast du schon mal den RRAS deaktiviert dann die RRAS Rolle komplettt entfernt, den Server neu gestartet und dann erneut installiert und konfiguriert ?

Jop. Und jetzt geht's. face-wink

Ich habe tatsächlich einmal alles was RRAS betrifft runtergeworfen, die Kiste neu gestartet und die Rollen dann wieder hinzugefügt.

Die Konfiguration habe ich so einfach wie möglich gehalten:
- IP Adressbereich
- NAT auf den Ethernet Adapter

fertig.

Vielen Dank für die vielen Hinweise, die Unterstützung und die Anteilnahme. face-smile
Mitglied: 114757
114757 Sep 15, 2015 updated at 14:00:26 (UTC)
Goto Top
Zitat von @Androxin:
Jop. Und jetzt geht's. face-wink
Nich wahr x-)
Vielen Dank für die vielen Hinweise, die Unterstützung und die Anteilnahme. face-smile
Keine Ursache face-smile

jodel
Member: aqui
aqui Sep 16, 2015 at 18:43:02 (UTC)
Goto Top
Ein weiterer Grund warum VPNs auf Servern nichts zu suchen hat. Dafür gibts Firewalls die das nicht nur sicherer an der Peripherie sondern generell auch besser können face-wink
Member: Androxin
Androxin Sep 16, 2015 at 18:47:24 (UTC)
Goto Top
Zitat von @aqui:

Ein weiterer Grund warum VPNs auf Servern nichts zu suchen hat. Dafür gibts Firewalls die das nicht nur sicherer an der Peripherie sondern generell auch besser können face-wink

Aber auch sowas darf man zumindest mal ausprobieren. face-wink
GermansolvedQuestionLAN, WAN, WirelessNetworks
Hotly discussed
AlexWishaHow to set up and configure a Linux GRE tunnelAlexWisha - 3 CommentsDaniEnd of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment