1
Routing Probleme mit OpenVPN und Windows Server 2012R2
Hallo zusammen,
ich habe heute mal damit angefangen mich mit OpenVPN zu beschäftigen. Ich habe zwar schon ein gut funktionierendes WindowsVPN am laufen, aber das Reicht für meine Zwecke nun aber nicht mehr aus.
Ich hätte 2 Aufgaben von den ich mir erhoffe das sie OpenVPN erfüllen kann:
- UDP Broadcast (für ältere Spiele, bei denen der Internet Support eingestellt wurde in meinem Fall konkret FlatOut 2) Ist das möglich?
- Anderen Default Gateway ( Also ich möchte meinen ganzen Traffic von den Client über die VPN schicken, das funktioniert ja schon super bei Windows, aber ich habe noch von CyberGhost einen VPN-Tunnel über die meinen Lokalen Clients schon ins Internet gehen mittels LAN Routing. Jetzt fände ich es super, wenn sich die Clients die sich per VPN bei mir Local einwählen und weiter ins Internet wollen sprich Google, das dies nicht über die FritzBox passiert sondern auch über den CyberGhost Gateway.) Ist das möglich?
Netzwerk config:
Lokales Netz 10.10.20.0/24
FritzBox 10.10.20.1
CyberGhost 10.10.20.125
DHCP/DNS 10.10.20.3
OPENVPN 10.10.20.55
Als VPN-Netzwerk hätte ich gerne 10.10.10.0/24 aber das ist eigentlich auch egal.
Nun habe ich mit OpenVpn schon was herumprobiert und die Verbindung mit dem Client steht, aber ich kann nur den OVPN-Server und die Lokale IP-Ansprechen vom Client aus, sprich 10.10.10.10 und 10.10.20.55 weiter geht es nicht.
Ich habe das ganze versucht per Netzwerkbrücke in MS zu realisieren, wenn ich das richtig verstanden habe muss das per Bridge gemacht werden, wegen dem UDP-Broadcast?!
Nur hab ich mittlerweile so viele Sachen ausprobiert aus 100ten Foren, das ich aktuell nicht mehr weiter weiß.
Das ist meine Aktuelle Config.
Server config:
Client config:
Ich hoffe ihr könnt mir weiterhelfen.
Danke für die Mühe und Gruß
ich habe heute mal damit angefangen mich mit OpenVPN zu beschäftigen. Ich habe zwar schon ein gut funktionierendes WindowsVPN am laufen, aber das Reicht für meine Zwecke nun aber nicht mehr aus.
Ich hätte 2 Aufgaben von den ich mir erhoffe das sie OpenVPN erfüllen kann:
- UDP Broadcast (für ältere Spiele, bei denen der Internet Support eingestellt wurde in meinem Fall konkret FlatOut 2) Ist das möglich?
- Anderen Default Gateway ( Also ich möchte meinen ganzen Traffic von den Client über die VPN schicken, das funktioniert ja schon super bei Windows, aber ich habe noch von CyberGhost einen VPN-Tunnel über die meinen Lokalen Clients schon ins Internet gehen mittels LAN Routing. Jetzt fände ich es super, wenn sich die Clients die sich per VPN bei mir Local einwählen und weiter ins Internet wollen sprich Google, das dies nicht über die FritzBox passiert sondern auch über den CyberGhost Gateway.) Ist das möglich?
Netzwerk config:
Lokales Netz 10.10.20.0/24
FritzBox 10.10.20.1
CyberGhost 10.10.20.125
DHCP/DNS 10.10.20.3
OPENVPN 10.10.20.55
Als VPN-Netzwerk hätte ich gerne 10.10.10.0/24 aber das ist eigentlich auch egal.
Nun habe ich mit OpenVpn schon was herumprobiert und die Verbindung mit dem Client steht, aber ich kann nur den OVPN-Server und die Lokale IP-Ansprechen vom Client aus, sprich 10.10.10.10 und 10.10.20.55 weiter geht es nicht.
Ich habe das ganze versucht per Netzwerkbrücke in MS zu realisieren, wenn ich das richtig verstanden habe muss das per Bridge gemacht werden, wegen dem UDP-Broadcast?!
Nur hab ich mittlerweile so viele Sachen ausprobiert aus 100ten Foren, das ich aktuell nicht mehr weiter weiß.
Das ist meine Aktuelle Config.
Server config:
port 1194
proto udp
dev tap
server-bridge 10.10.10.10 255.255.255.0 10.10.10.220 10.10.10.230
push "route 10.10.20.0 255.255.255.0"
push "redirect-gateway def1"
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
cipher AES-256-CBC
client-to-client
duplicate-cn
keepalive 15 60
persist-key
persist-tun
status openvpn-status.txt
log-append openvpn.log
verb 4
mute 15Client config:
client
port 1194
proto udp
dev tap
ca ca.crt
cert client.crt
key client.key
cipher AES-256-CBC
remote ddns.de
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
verb 3
mute 20
pullIch hoffe ihr könnt mir weiterhelfen.
Danke für die Mühe und Gruß
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 242499
Url: https://administrator.de/contentid/242499
Printed on: April 19, 2024 at 10:04 o'clock
1 Comment
Das passende Forumstutorial dazu hast du gelesen ? Es beantwortet das Gros deiner Fragen.
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die HW ist egal, da die Installationsschritte bei OVPN immer gleich und HW unabhängig sind !
Vorab: deine beiden Definitionen:
push "route 10.10.20.0 255.255.255.0"
push "redirect-gateway def1"
Zusammen sind natürlich Blödsinn aber evtl. hast du das selber schon erkannt ?!
Mit push "redirect-gateway def1" biehst du ja bei aktiviertem OVPN Client dein Default Gateway um auf den VPN Tunnel: Mit anderen Worten dann geht sämtlicher Traffic durch den Tunnel.
Dann noch ein spezifisches IP Netz zu routen (10.10.20.0 /24) ist dann natürlich überflüssiger Unsinn aber das leuchtet dir vermutlich selber ein ?!
Natürlich geht das auch über den Cyber Ghost Anschluss wenn die dortige Server Config Datei das gleiche Statement enthält und so den Client Traffic vollständig redirected. Das ist eine simple Frage der richtigen Konfig !
Was deine Broadcast Frage anbetrifft zeugt das eher von generellen Wissens Defiziten im Netzwerk Bereich. VPN sind in der Regel imemr geroutet und bei gerouteten IP Netzen wird generell kein UDP Broadcast wie generell kein Broadcast über Routing Grenzen geforwardet. Das ist Basiswissen IP Netzwerke erste Klasse.
Broadcasts kannst du also nur im bridged Modus übertragen. Das ist aber sehr kontraprotuktiv, denn in einem Bridged Szenario bei VPN wird dann der gesamte Broad- und Multicast Traffic aus beiden IP netzen im VPN Tunnel geforwardet. Das das Tunnelinterface in der Regel eine niedrigere Bandbreite hat kumuliert hier dieser gesmate Traffic und belastet den Tunnel mit einem quais "Grundrauschen", was massiv zulasten der VPN Performance geht.
Aus diesem Grund wird niemals ein Bridging im VPN gemacht sondern immer Routing da das erheblich effizienter ist.
UDP Broadcasts kann man nur mit Workarounds übertragen im Routing Mode. (IP Helper, UDP Relay Agents) Ist aber immer ne Krücke wie das Bridging selber.
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die HW ist egal, da die Installationsschritte bei OVPN immer gleich und HW unabhängig sind !
Vorab: deine beiden Definitionen:
push "route 10.10.20.0 255.255.255.0"
push "redirect-gateway def1"
Zusammen sind natürlich Blödsinn aber evtl. hast du das selber schon erkannt ?!
Mit push "redirect-gateway def1" biehst du ja bei aktiviertem OVPN Client dein Default Gateway um auf den VPN Tunnel: Mit anderen Worten dann geht sämtlicher Traffic durch den Tunnel.
Dann noch ein spezifisches IP Netz zu routen (10.10.20.0 /24) ist dann natürlich überflüssiger Unsinn aber das leuchtet dir vermutlich selber ein ?!
Natürlich geht das auch über den Cyber Ghost Anschluss wenn die dortige Server Config Datei das gleiche Statement enthält und so den Client Traffic vollständig redirected. Das ist eine simple Frage der richtigen Konfig !
Was deine Broadcast Frage anbetrifft zeugt das eher von generellen Wissens Defiziten im Netzwerk Bereich. VPN sind in der Regel imemr geroutet und bei gerouteten IP Netzen wird generell kein UDP Broadcast wie generell kein Broadcast über Routing Grenzen geforwardet. Das ist Basiswissen IP Netzwerke erste Klasse.
Broadcasts kannst du also nur im bridged Modus übertragen. Das ist aber sehr kontraprotuktiv, denn in einem Bridged Szenario bei VPN wird dann der gesamte Broad- und Multicast Traffic aus beiden IP netzen im VPN Tunnel geforwardet. Das das Tunnelinterface in der Regel eine niedrigere Bandbreite hat kumuliert hier dieser gesmate Traffic und belastet den Tunnel mit einem quais "Grundrauschen", was massiv zulasten der VPN Performance geht.
Aus diesem Grund wird niemals ein Bridging im VPN gemacht sondern immer Routing da das erheblich effizienter ist.
UDP Broadcasts kann man nur mit Workarounds übertragen im Routing Mode. (IP Helper, UDP Relay Agents) Ist aber immer ne Krücke wie das Bridging selber.
