OpenVPN-Problem DHCP geht, PING nicht
Hallo,
ich habe in einem LAN versuchsweise eine OPVPN-Verbindung zwischen einem Client und einem Server (SBS2003) aufgebaut. Die Verbindung steht scheinbar. Das Client bekommt die IP 192.168.10.6, DHCP geht also über das OVPN-Netz.
Meine Fragen:
1. was kann der Grund der folgenden Zeile sein?
"WARNING: No server certificate verification method has been enabled"
"Mon Feb 21 23:26:58 2011 ROUTE: route addition failed using CreateIpForwardEntry: Falscher Parameter. [status=87 if_index=65540]
2. wie kann ich erreichen, dass die Verbindung bei jedem Neustart automatisch aufgebaut wird?
3. Wie kann der User mit seinem lokalen NT-Login durch VPN angemeldet sein? (Ich möchte ja auf dem Server keine weitere User erstellen.)
4. warum können Server und Client einander nicht "anpingen"? Die Verbindung steht scheinbar.
5. wenn ich mir die Status-Info der TUN-Adapter in den Netzwereinstellungen des Server und des Clients anschaue ist Subnetz-Mask überall 255.255.255.252 obwohl ich 255.255.255.0 festgelegt habe (es ist möglicherweise i. O. so).
6. In denselben Status-Info gibt es kein Standard-Gateway, was in meinem Fall 192.168.10.1 sein sollte.
7. Ich habe gedacht, dass DHCP-Server identisch wäre mit dem Server. Es hat aber in meinem Fall die IP-Adresse 192.168.10.5. Ist es normal?
Danke für die Hilfe.
Gr. I.
hier ist die Config-Datei des Servers:
script-security 2
port 1194
proto udp
dev tun
tun-mtu 1500
fragment 1300
mssfix
tls-server
auth SHA1
pkcs12 C:\\Programme\\OpenVPN\\easy-rsa\\keys\\xxxx_Server.p12
dh C:\\Programme\\OpenVPN\\easy-rsa\\keys\\dh1024.pem
mode server
server 192.168.10.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.0.0.250 255.255.255.0"
client-to-client
keepalive 10 120
cipher AES-256-CBC
comp-lzo
user OpenVPN
status C:\\Programme\\OpenVPN\\config\\openvpn-status.log
verb 3
hier ist noch die Config-Datei des Clients:
client
dev tun
remote xxxxxxxxxxxxxxxxxx
port 1194
proto udp
tun-mtu 1500
fragment 1300
mssfix
pull
tls-client
auth SHA1
resolv-retry infinite
nobind
persist-key
persist-tun
pkcs12 C:\\Programme\\OpenVPN\\easy-rsa\\Keys\\xxxxxxxxxxxx.crt
cipher AES-256-CBC
comp-lzo
verb 3
hier ist das Log des Clients:
Mon Feb 21 23:26:43 2011 OpenVPN 2.1.4 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Nov 8 2010
Mon Feb 21 23:26:43 2011 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Mon Feb 21 23:26:43 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Mon Feb 21 23:26:49 2011 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Feb 21 23:26:49 2011 LZO compression initialized
Mon Feb 21 23:26:49 2011 Control Channel MTU parms [ L:1562 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Feb 21 23:26:49 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Feb 21 23:26:49 2011 Data Channel MTU parms [ L:1562 D:1300 EF:62 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Feb 21 23:26:49 2011 Fragmentation MTU parms [ L:1562 D:1300 EF:61 EB:135 ET:1 EL:0 AF:3/1 ]
Mon Feb 21 23:26:49 2011 Local Options hash (VER=V4): 'caff5189'
Mon Feb 21 23:26:49 2011 Expected Remote Options hash (VER=V4): '43a81564'
Mon Feb 21 23:26:49 2011 UDPv4 link local: [undef]
Mon Feb 21 23:26:49 2011 UDPv4 link remote: XXXXXXXXX
Mon Feb 21 23:26:49 2011 TLS: Initial packet from XXXXXXXXX:1194, sid=21658f71 e80530da
Mon Feb 21 23:26:50 2011 VERIFY OK: depth=1, /C=DE/ST=BW/L=Karlsruhe/O=xxxxxxxxxxxxx/CN=Tank_CA/emailAddress=xxxxxxxxxxxxxxxxx
Mon Feb 21 23:26:50 2011 VERIFY OK: depth=0, /C=DE/ST=BW/L=Karlsruhe/O=xxxxxxxxxxxxx/CN=Tank_Server/emailAddress=xxxxxxxxxxxxxxx
Mon Feb 21 23:26:50 2011 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Mon Feb 21 23:26:50 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Feb 21 23:26:50 2011 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Mon Feb 21 23:26:50 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Feb 21 23:26:50 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Feb 21 23:26:50 2011 [Tank_Server] Peer Connection Initiated with 46.5.199.53:1194
Mon Feb 21 23:26:52 2011 SENT CONTROL [Tank_Server]: 'PUSH_REQUEST' (status=1)
Mon Feb 21 23:26:52 2011 PUSH: Received control message: 'PUSH_REPLY,route 192.0.0.250 255.255.255.0,route 192.168.10.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 192.168.10.6 192.168.10.5'
Mon Feb 21 23:26:52 2011 OPTIONS IMPORT: timers and/or timeouts modified
Mon Feb 21 23:26:52 2011 OPTIONS IMPORT: --ifconfig/up options modified
Mon Feb 21 23:26:52 2011 OPTIONS IMPORT: route options modified
Mon Feb 21 23:26:52 2011 ROUTE default_gateway=192.0.0.250
Mon Feb 21 23:26:52 2011 TAP-WIN32 device [LAN-Verbindung 4] opened: \\.\Global\{E4AFCF4C-2EDE-4996-9932-CC64AE8326B4}.tap
Mon Feb 21 23:26:52 2011 TAP-Win32 Driver Version 9.7
Mon Feb 21 23:26:52 2011 TAP-Win32 MTU=1500
Mon Feb 21 23:26:52 2011 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.10.6/255.255.255.252 on interface {E4AFCF4C-2EDE-4996-9932-CC64AE8326B4} [DHCP-serv: 192.168.10.5, lease-time: 31536000]
Mon Feb 21 23:26:52 2011 Successful ARP Flush on interface [65540] {E4AFCF4C-2EDE-4996-9932-CC64AE8326B4}
Mon Feb 21 23:26:58 2011 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Mon Feb 21 23:26:58 2011 WARNING: potential route subnet conflict between local LAN [192.0.0.0/255.255.255.0] and remote VPN [192.0.0.0/255.255.255.0]
Mon Feb 21 23:26:58 2011 C:\WINDOWS\system32\route.exe ADD 192.0.0.250 MASK 255.255.255.0 192.168.10.5
Mon Feb 21 23:26:58 2011 Warning: address 192.0.0.250 is not a network address in relation to netmask 255.255.255.0
Mon Feb 21 23:26:58 2011 ROUTE: route addition failed using CreateIpForwardEntry: Falscher Parameter. [status=87 if_index=65540]
Mon Feb 21 23:26:58 2011 Route addition via IPAPI failed [adaptive]
Mon Feb 21 23:26:58 2011 Route addition fallback to route.exe
Hinzufgen der Route fehlgeschlagen: Der angegebene Maskenparameter ist ungltig. (Ziel & Maske) != Ziel.
Mon Feb 21 23:26:58 2011 C:\WINDOWS\system32\route.exe ADD 192.168.10.0 MASK 255.255.255.0 192.168.10.5
Mon Feb 21 23:26:58 2011 Route addition via IPAPI succeeded [adaptive]
Mon Feb 21 23:26:58 2011 Initialization Sequence Completed
ich habe in einem LAN versuchsweise eine OPVPN-Verbindung zwischen einem Client und einem Server (SBS2003) aufgebaut. Die Verbindung steht scheinbar. Das Client bekommt die IP 192.168.10.6, DHCP geht also über das OVPN-Netz.
Meine Fragen:
1. was kann der Grund der folgenden Zeile sein?
"WARNING: No server certificate verification method has been enabled"
"Mon Feb 21 23:26:58 2011 ROUTE: route addition failed using CreateIpForwardEntry: Falscher Parameter. [status=87 if_index=65540]
2. wie kann ich erreichen, dass die Verbindung bei jedem Neustart automatisch aufgebaut wird?
3. Wie kann der User mit seinem lokalen NT-Login durch VPN angemeldet sein? (Ich möchte ja auf dem Server keine weitere User erstellen.)
4. warum können Server und Client einander nicht "anpingen"? Die Verbindung steht scheinbar.
5. wenn ich mir die Status-Info der TUN-Adapter in den Netzwereinstellungen des Server und des Clients anschaue ist Subnetz-Mask überall 255.255.255.252 obwohl ich 255.255.255.0 festgelegt habe (es ist möglicherweise i. O. so).
6. In denselben Status-Info gibt es kein Standard-Gateway, was in meinem Fall 192.168.10.1 sein sollte.
7. Ich habe gedacht, dass DHCP-Server identisch wäre mit dem Server. Es hat aber in meinem Fall die IP-Adresse 192.168.10.5. Ist es normal?
Danke für die Hilfe.
Gr. I.
hier ist die Config-Datei des Servers:
script-security 2
port 1194
proto udp
dev tun
tun-mtu 1500
fragment 1300
mssfix
tls-server
auth SHA1
pkcs12 C:\\Programme\\OpenVPN\\easy-rsa\\keys\\xxxx_Server.p12
dh C:\\Programme\\OpenVPN\\easy-rsa\\keys\\dh1024.pem
mode server
server 192.168.10.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.0.0.250 255.255.255.0"
client-to-client
keepalive 10 120
cipher AES-256-CBC
comp-lzo
user OpenVPN
status C:\\Programme\\OpenVPN\\config\\openvpn-status.log
verb 3
hier ist noch die Config-Datei des Clients:
client
dev tun
remote xxxxxxxxxxxxxxxxxx
port 1194
proto udp
tun-mtu 1500
fragment 1300
mssfix
pull
tls-client
auth SHA1
resolv-retry infinite
nobind
persist-key
persist-tun
pkcs12 C:\\Programme\\OpenVPN\\easy-rsa\\Keys\\xxxxxxxxxxxx.crt
cipher AES-256-CBC
comp-lzo
verb 3
hier ist das Log des Clients:
Mon Feb 21 23:26:43 2011 OpenVPN 2.1.4 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Nov 8 2010
Mon Feb 21 23:26:43 2011 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Mon Feb 21 23:26:43 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Mon Feb 21 23:26:49 2011 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Feb 21 23:26:49 2011 LZO compression initialized
Mon Feb 21 23:26:49 2011 Control Channel MTU parms [ L:1562 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Feb 21 23:26:49 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Feb 21 23:26:49 2011 Data Channel MTU parms [ L:1562 D:1300 EF:62 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Feb 21 23:26:49 2011 Fragmentation MTU parms [ L:1562 D:1300 EF:61 EB:135 ET:1 EL:0 AF:3/1 ]
Mon Feb 21 23:26:49 2011 Local Options hash (VER=V4): 'caff5189'
Mon Feb 21 23:26:49 2011 Expected Remote Options hash (VER=V4): '43a81564'
Mon Feb 21 23:26:49 2011 UDPv4 link local: [undef]
Mon Feb 21 23:26:49 2011 UDPv4 link remote: XXXXXXXXX
Mon Feb 21 23:26:49 2011 TLS: Initial packet from XXXXXXXXX:1194, sid=21658f71 e80530da
Mon Feb 21 23:26:50 2011 VERIFY OK: depth=1, /C=DE/ST=BW/L=Karlsruhe/O=xxxxxxxxxxxxx/CN=Tank_CA/emailAddress=xxxxxxxxxxxxxxxxx
Mon Feb 21 23:26:50 2011 VERIFY OK: depth=0, /C=DE/ST=BW/L=Karlsruhe/O=xxxxxxxxxxxxx/CN=Tank_Server/emailAddress=xxxxxxxxxxxxxxx
Mon Feb 21 23:26:50 2011 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Mon Feb 21 23:26:50 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Feb 21 23:26:50 2011 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Mon Feb 21 23:26:50 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Feb 21 23:26:50 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Feb 21 23:26:50 2011 [Tank_Server] Peer Connection Initiated with 46.5.199.53:1194
Mon Feb 21 23:26:52 2011 SENT CONTROL [Tank_Server]: 'PUSH_REQUEST' (status=1)
Mon Feb 21 23:26:52 2011 PUSH: Received control message: 'PUSH_REPLY,route 192.0.0.250 255.255.255.0,route 192.168.10.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 192.168.10.6 192.168.10.5'
Mon Feb 21 23:26:52 2011 OPTIONS IMPORT: timers and/or timeouts modified
Mon Feb 21 23:26:52 2011 OPTIONS IMPORT: --ifconfig/up options modified
Mon Feb 21 23:26:52 2011 OPTIONS IMPORT: route options modified
Mon Feb 21 23:26:52 2011 ROUTE default_gateway=192.0.0.250
Mon Feb 21 23:26:52 2011 TAP-WIN32 device [LAN-Verbindung 4] opened: \\.\Global\{E4AFCF4C-2EDE-4996-9932-CC64AE8326B4}.tap
Mon Feb 21 23:26:52 2011 TAP-Win32 Driver Version 9.7
Mon Feb 21 23:26:52 2011 TAP-Win32 MTU=1500
Mon Feb 21 23:26:52 2011 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.10.6/255.255.255.252 on interface {E4AFCF4C-2EDE-4996-9932-CC64AE8326B4} [DHCP-serv: 192.168.10.5, lease-time: 31536000]
Mon Feb 21 23:26:52 2011 Successful ARP Flush on interface [65540] {E4AFCF4C-2EDE-4996-9932-CC64AE8326B4}
Mon Feb 21 23:26:58 2011 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Mon Feb 21 23:26:58 2011 WARNING: potential route subnet conflict between local LAN [192.0.0.0/255.255.255.0] and remote VPN [192.0.0.0/255.255.255.0]
Mon Feb 21 23:26:58 2011 C:\WINDOWS\system32\route.exe ADD 192.0.0.250 MASK 255.255.255.0 192.168.10.5
Mon Feb 21 23:26:58 2011 Warning: address 192.0.0.250 is not a network address in relation to netmask 255.255.255.0
Mon Feb 21 23:26:58 2011 ROUTE: route addition failed using CreateIpForwardEntry: Falscher Parameter. [status=87 if_index=65540]
Mon Feb 21 23:26:58 2011 Route addition via IPAPI failed [adaptive]
Mon Feb 21 23:26:58 2011 Route addition fallback to route.exe
Hinzufgen der Route fehlgeschlagen: Der angegebene Maskenparameter ist ungltig. (Ziel & Maske) != Ziel.
Mon Feb 21 23:26:58 2011 C:\WINDOWS\system32\route.exe ADD 192.168.10.0 MASK 255.255.255.0 192.168.10.5
Mon Feb 21 23:26:58 2011 Route addition via IPAPI succeeded [adaptive]
Mon Feb 21 23:26:58 2011 Initialization Sequence Completed
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 161295
Url: https://administrator.de/forum/openvpn-problem-dhcp-geht-ping-nicht-161295.html
Ausgedruckt am: 23.12.2024 um 03:12 Uhr
19 Kommentare
Neuester Kommentar
Hallöle,
ansich ist das LOG aussagekräftig genug.
Mon Feb 21 23:26:58 2011 Route addition fallback to route.exe
Hinzufgen der Route fehlgeschlagen: Der angegebene Maskenparameter ist ungltig. (Ziel & Maske) != Ziel.
Mon Feb 21 23:26:58 2011 C:\WINDOWS\system32\route.exe ADD 192.168.10.0 MASK 255.255.255.0 192.168.10.5
Welches Netz willst Du erreichen?? 192.0.0.x /24?? Dieser Bereich ist eigentlich reserviert...
Deine OVPN Clients stehen in einem virtuellen Netz (192.168.10.x , wobei der DHCP Server für dieses Netz die 192.168.10.5 ist (gleichzeitig das Standard GW fü die VPN Clients))
Du versuchst aber deinen Server im 192.168.0.x /24 Netz zu erreichen. Die Route kann jedoch am Client nicht hinzugefügt werden (Fehler im Log), da die Syntax nicht stimmt (192.0.0.250 ist keine Netzadresse sondern wahrscheinlich der Server den du erreichen möchtest.) Die Route sollte am Server so aussehen, wenn Du das gesamte Netz erreichen möchtest : push "route 192.0.0.250 255.255.255.0"
Gruß
ansich ist das LOG aussagekräftig genug.
Mon Feb 21 23:26:58 2011 Route addition fallback to route.exe
Hinzufgen der Route fehlgeschlagen: Der angegebene Maskenparameter ist ungltig. (Ziel & Maske) != Ziel.
Mon Feb 21 23:26:58 2011 C:\WINDOWS\system32\route.exe ADD 192.168.10.0 MASK 255.255.255.0 192.168.10.5
Welches Netz willst Du erreichen?? 192.0.0.x /24?? Dieser Bereich ist eigentlich reserviert...
Deine OVPN Clients stehen in einem virtuellen Netz (192.168.10.x , wobei der DHCP Server für dieses Netz die 192.168.10.5 ist (gleichzeitig das Standard GW fü die VPN Clients))
Du versuchst aber deinen Server im 192.168.0.x /24 Netz zu erreichen. Die Route kann jedoch am Client nicht hinzugefügt werden (Fehler im Log), da die Syntax nicht stimmt (192.0.0.250 ist keine Netzadresse sondern wahrscheinlich der Server den du erreichen möchtest.) Die Route sollte am Server so aussehen, wenn Du das gesamte Netz erreichen möchtest : push "route 192.0.0.250 255.255.255.0"
Gruß
Es ist soweit alles OK, das VPN Netz kann so bleibe wie es ist.
Habe einen Fehler in dem Push-Route Befehl eingebaut. So muss es aussehen:
push "route 192.0.0.0 255.255.255.0"
192.0.0.250 ist ja dein Server und nicht das Netz!
Du kannst es auch am Client testen (bei bestehender VPN Verbindung) indem Du die Route manuell setzt.
route add 192.0.0.0 MASK 255.255.255.0 192.168.10.5
Möglicherweise eine Rückroute am Server setzen.
Gruß
Habe einen Fehler in dem Push-Route Befehl eingebaut. So muss es aussehen:
push "route 192.0.0.0 255.255.255.0"
192.0.0.250 ist ja dein Server und nicht das Netz!
Du kannst es auch am Client testen (bei bestehender VPN Verbindung) indem Du die Route manuell setzt.
route add 192.0.0.0 MASK 255.255.255.0 192.168.10.5
Möglicherweise eine Rückroute am Server setzen.
Gruß
Halt dich einfach ans OpenVPN Tutorial:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Da hast du eine laufende und funktionierende Konfig die auch noch Plattform unabhängig ist. Dann hast du auch solche Routing Probleme nicht.
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Da hast du eine laufende und funktionierende Konfig die auch noch Plattform unabhängig ist. Dann hast du auch solche Routing Probleme nicht.
Relevant ist was am tun interface steht. Also wenn der Tunnel steht, dann solltest du einmal ein ipconfig eingeben und sehen was am tun/tap device steht ! Dort muss ein Interface mit diesem Namen zu sehen sein !!
Weiterhin relevant ist wie die Routing Tabelle bei aktivem Tunnel Link aussieht !!?
Ein route print zeigt dir das an !
Hier kannst du dann sehen ob die remoten Netze mit "push route x.y.z..." richtig propagiert sind.
Zwei Dinge sind sehr auffällig bei dir in der ansonsten korrekten Konfig:
Folgende weitere Dinge solltest du unbedingt prüfen wenn du remote Endgeräte pingst:
Benötigen tut man dieses Kommando so oder so nicht !
Wenn du das alles beachtest sollte das im Handumdrehen laufen ! Das ist eine simple Standardkonfig die millionenfach so im aktiven Einsatz ist !
Weiterhin relevant ist wie die Routing Tabelle bei aktivem Tunnel Link aussieht !!?
Ein route print zeigt dir das an !
Hier kannst du dann sehen ob die remoten Netze mit "push route x.y.z..." richtig propagiert sind.
Zwei Dinge sind sehr auffällig bei dir in der ansonsten korrekten Konfig:
- Die Fehlermeldung "...ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweigert [status=5 if_index=119] " zeigt das du unter dem User mit dem OpenVPN rennt vermutlich keine ausreichenden Rechte hast um das tun/tap Interface zu aktivieren. Die "Zugriff verweigert" Message dadrüber erhärtet diese Vermutung ?!
- push "route 192.0.0.0 255.255.255.0" ist natürlich schon ein mehr als grenzwertiger Befehl in der Beziehung das 192.0.0.0 kein privates_RFC_1918_IP_Netzwerk ist, also kein privates Netzwerk !!
Folgende weitere Dinge solltest du unbedingt prüfen wenn du remote Endgeräte pingst:
- Das du die #comment-toc6 VPN_Adress_Design_Regeln eingehalten ?
- Hast du bedacht das das Routing für die remoten Netze auf den OpenVPN Router zeigen muss. Wichtig wenn du DSL Router und OpenVPN Server getrennt hast. Siehe #comment-toc8 hier ! Dann geht das NICHT ohne statische Routen !
- Ganz wichtig: die lokale Firewall dieser Engeräte muss angepasst werden in den erweiterten Einstellungen, das sie Pakete aus diesen remoten Netzen erlaubt ! Sonst blockt sie alles was NICHT lokal ist ! Passe das also an und achte zudem darauf das ICMP Ping dort erlaubt ist unter dem Button "ICMP" (Ping) muss der Haken bei "Auf eingehende Echos antworten" aktiviert sein !
Benötigen tut man dieses Kommando so oder so nicht !
Wenn du das alles beachtest sollte das im Handumdrehen laufen ! Das ist eine simple Standardkonfig die millionenfach so im aktiven Einsatz ist !
Ja sicher ! Das ist die wichtigste Einstellung mit !
Und.... dein Punkt 1 ist die denkbar dümmste Idee gewesen in verbindung mit VPNs.
Besser du liest das hier bevor du solche contraproduktiven Einstellungen machst:
VPNs einrichten mit PPTP
Und.... dein Punkt 1 ist die denkbar dümmste Idee gewesen in verbindung mit VPNs.
Besser du liest das hier bevor du solche contraproduktiven Einstellungen machst:
VPNs einrichten mit PPTP
Achte daruf das der Winblows Server kein NAT/ICS macht, denn das ist ebenso eine Stolperstelle:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Transparentes Routing ist für dich Pflicht !
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Transparentes Routing ist für dich Pflicht !
Du benötigst das Routing wenn du zwischen beiden Segmenten im Server routen musst ! Ohne das sind alle Segmente isoliert.
Vom Bridging der Karten kann man dir nur dringend abraten. Aus Performancesicht ist das ein erheblicher Rückschritt da du alles mit Broad- und Multicasts flutest....
Irgendwas stimmt an deinem Setup noch nicht oder du hast ein Problem mit der Firewall.
Das ist ein simples Standard OpenVPN setup was eigentlich in 20 Minuten mit ein paar Mausklicks erledigt ist.
Vom Bridging der Karten kann man dir nur dringend abraten. Aus Performancesicht ist das ein erheblicher Rückschritt da du alles mit Broad- und Multicasts flutest....
Irgendwas stimmt an deinem Setup noch nicht oder du hast ein Problem mit der Firewall.
Das ist ein simples Standard OpenVPN setup was eigentlich in 20 Minuten mit ein paar Mausklicks erledigt ist.
Nur nochmal zum Verständnis nachgefragt: Dein Design sieht so aus:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
D.h. dein OpenVPN Win Server hat 2 NICs von denen eine das lokale LAN mit den Clients bedient und eine das LAN zum DSL Router, richtig ?
Mit
push "route 192.168.1.0 255.255.255.0"
machst du dann in der Konfig dein lokales LAN am Server zum remoten VPN Client bekannt, auch richtig ?
Das dein Client nicht auch in einem 192.168.1.0er IP Netz betrieben wird (IP Konflikt !!) hast du gelesen und diese folgenden Design Regeln befolgt ??
VPNs einrichten mit PPTP
Das sind zwingende Voraussetzungen !!
Wenn du nun die Client Verbindung öffnest kannst du dann...:
a.) die interne OpenVPN Server IP 172.16.2.1 anpingen ?
b.) Kannst du das lokale LAN Interface des Servers 192.168.1.x anpingen ? Achtung FW Einstellungen hier am Server beachten !
c.) Oben sieht man das da noch ein Hamachi Interface aktiv ist. Sowas ist bei VPN Tests immer kontraproduktiv da es zu gegenseitigen Beeinflussungen kommen kann. Für OpenVPN Tests sowas immer deaktivieren.
Diese Minimaltests solltest du erstmal zum Fliegen bringen !
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
D.h. dein OpenVPN Win Server hat 2 NICs von denen eine das lokale LAN mit den Clients bedient und eine das LAN zum DSL Router, richtig ?
Mit
push "route 192.168.1.0 255.255.255.0"
machst du dann in der Konfig dein lokales LAN am Server zum remoten VPN Client bekannt, auch richtig ?
Das dein Client nicht auch in einem 192.168.1.0er IP Netz betrieben wird (IP Konflikt !!) hast du gelesen und diese folgenden Design Regeln befolgt ??
VPNs einrichten mit PPTP
Das sind zwingende Voraussetzungen !!
Wenn du nun die Client Verbindung öffnest kannst du dann...:
a.) die interne OpenVPN Server IP 172.16.2.1 anpingen ?
b.) Kannst du das lokale LAN Interface des Servers 192.168.1.x anpingen ? Achtung FW Einstellungen hier am Server beachten !
c.) Oben sieht man das da noch ein Hamachi Interface aktiv ist. Sowas ist bei VPN Tests immer kontraproduktiv da es zu gegenseitigen Beeinflussungen kommen kann. Für OpenVPN Tests sowas immer deaktivieren.
Diese Minimaltests solltest du erstmal zum Fliegen bringen !
Das ist auch alles klar warum das nicht geht ! Dein Szenario sieht vermutlich so aus, oder:
Das du nicht pingen kannst hat 2 wichtige Ursachen:
Deine Firewall im Notebook erlaubt keine ICMPs und auch keinen Zugang von fremden IPs was die Firewall in der Regel ja blockt !
Gehe also in die erweiterten Einstellungen, dann ICMP (Ping) und setze hier den Haken Auf eingehende Eches antworten !
Für alle anderen Dienste musst du ggf. den Port Bereich der Firewall entsprechend auf dein VPN Netz anpassen sonst blockt die Firewall Zugriffe darauf !
Das du keine anderen Geräte im Netz anpingen kannst ist doch ganz logisch !
Vermutlich haben die alle als Default Gateway den Router mit der 10.1.1.250 eingetragen ! Wenn du nun ein Gerät via VPN anpingst hast du einen 172.16.2.0er IP Adresse als Absender...logisch ! Damit senden lokale Geräte im 10er Netz nun alle alle Antwortpakete statt in den VPN Tunnel via VPN Server direkt zum Router. Klar, müssen sie auch, denn sie merken ja das das Zielnetz 172.16.2.0 nicht ihr lokales netzwerk ist also ab damit zum Router....
Der aber wiederum routet das ins Internet weil ihm (vermutlich) die statische Route auf den OpenVPN Server fehlt. Dort werden diese Pakete dann in den Filterlisten des Providers gleich in den Müll gedrückt werden. (Private nicht geroutete RFC 1918 IP Netze !)
Fazit: Was dir fehlt ist eine statische Route auf deinem Router die sagt: "Alle 172.16.2.0er Pakete bitte NICHT ins Internet sondern an die 10.1.1.200 !!". Dann gehen diese damit auch sauber an den OpenVPN Server und der schickt sie dann via VPN Tunnel zum Notebook wie es sich gehört !
Gehe also ins Web Setup deines Routers unter statische Routen und trage dort ein:
Zielnetz: 172.16.2.0, Maske: 255.255.255.0, Gateway: 10.1.1.200 Fertig ist der Lack !
Damit kommt dieses OpenVPN Drama bei dir dann endlich zu einem erfolgreichen Abschluss !!
Das du nicht pingen kannst hat 2 wichtige Ursachen:
Deine Firewall im Notebook erlaubt keine ICMPs und auch keinen Zugang von fremden IPs was die Firewall in der Regel ja blockt !
Gehe also in die erweiterten Einstellungen, dann ICMP (Ping) und setze hier den Haken Auf eingehende Eches antworten !
Für alle anderen Dienste musst du ggf. den Port Bereich der Firewall entsprechend auf dein VPN Netz anpassen sonst blockt die Firewall Zugriffe darauf !
Das du keine anderen Geräte im Netz anpingen kannst ist doch ganz logisch !
Vermutlich haben die alle als Default Gateway den Router mit der 10.1.1.250 eingetragen ! Wenn du nun ein Gerät via VPN anpingst hast du einen 172.16.2.0er IP Adresse als Absender...logisch ! Damit senden lokale Geräte im 10er Netz nun alle alle Antwortpakete statt in den VPN Tunnel via VPN Server direkt zum Router. Klar, müssen sie auch, denn sie merken ja das das Zielnetz 172.16.2.0 nicht ihr lokales netzwerk ist also ab damit zum Router....
Der aber wiederum routet das ins Internet weil ihm (vermutlich) die statische Route auf den OpenVPN Server fehlt. Dort werden diese Pakete dann in den Filterlisten des Providers gleich in den Müll gedrückt werden. (Private nicht geroutete RFC 1918 IP Netze !)
Fazit: Was dir fehlt ist eine statische Route auf deinem Router die sagt: "Alle 172.16.2.0er Pakete bitte NICHT ins Internet sondern an die 10.1.1.200 !!". Dann gehen diese damit auch sauber an den OpenVPN Server und der schickt sie dann via VPN Tunnel zum Notebook wie es sich gehört !
Gehe also ins Web Setup deines Routers unter statische Routen und trage dort ein:
Zielnetz: 172.16.2.0, Maske: 255.255.255.0, Gateway: 10.1.1.200 Fertig ist der Lack !
Damit kommt dieses OpenVPN Drama bei dir dann endlich zu einem erfolgreichen Abschluss !!