OpenVPN Server und Site2Site VPN

M

MasterM

New Member
Moin zusammen,
ich möchte zwei Standorte über einen OpenVPN Server verbinden.
Über die FritzBox und Wireguard (oder IPSec) habe ich das schon mehrmals erfolgreich gemacht, aber über OpenVPN nicht.
Eine VPN Verbindung über die FritzBox selbst scheidet in diesem Fall aber aus.

Folgenden Aufbau habe ich:
Standort A
Netz 192.168.188.0 / 24
Gateway 192.168.188.1
VPN Router: 192.168.188.19


Standort B
Netz 192.168.1.0 / 24
Gateway 192.168.1.1
VPN Router 192.168.1.7

Ich möchte von Netz A auf Netz B zugreifen (und umgekehrt).
Ich habe einen externen VPN Server aufgesetzt. Beide VPN Router können sich auf den Server verbinden.
Sie erhalten die IP 10.10.10.5 (A) und 10.10.10.6 (B) Auf den Gateways (Fritzboxen) habe ich zwei Routen gesetzt:
192.168.1.0 / 24 (bzw. 192.168.188.0 / 24) zeigt jeweils auf den VPN Router. Zum Test habe ich auch noch die 10.10.10.0/24 an beiden Standorten gesetzt.
Ich kann den entfernten Router auch unter der 10.10.10.n Adresse erreichen.

Nun scheitere ich aber daran, das entsprechende gesamte Netz zu erreichen.
1. Frage: Kann ich das Transportnetz auf dem Server überhaupt so klein lassen? Oder müsste ich ein 10.10.0.0 / 16 Netz nehmen und jedem Router ein eigenes 24er Netz geben? (Also A 10.10.10.0 / B 10.10.20.0)?

Aktuell komme ich mit meinem Routen bis zum VPN Server. Wo muss ich weitermachen, damit die verschiedenen Netze sich erreichen können?
Brauche ich auf den jeweiligen Routern ein NAT und/oder auf dem Server? Bin leider kein IT Profi, aber vielleicht kann mir jemand einen Tip geben, wonach ich suchen muss.



Hier noch meine Server - Config:
dev tun
port 1194
proto udp

topology subnet
keepalive 10 120
max-clients 100

persist-key
persist-tun
explicit-exit-notify 1

user nobody
group nogroup

client-config-dir /etc/openvpn/staticclients
ifconfig-pool-persist pki/ipp.txt

ca pki/ca.crt
cert pki/issued/server.crt
key pki/private/server.key
crl-verify pki/crl.pem
dh pki/dh.pem

tls-crypt pki/ta.key
tls-version-min 1.2
remote-cert-tls client

cipher AES-256-GCM
# ncp-ciphers AES-256-GCM:AES-192-GCM:AES-128-GCM # Deprecated since ver. 0.9.3. We have to use data-ciphers below instead
data-ciphers AES-256-GCM:AES-192-GCM:AES-128-GCM

auth SHA512

server 10.10.10.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 1.1.1.1"
#push "redirect-gateway def1 bypass-dhcp"

log /var/log/openvpn/openvpn.log
verb 3
status /var/log/openvpn/openvpn-status.log
status-version 2

push "route 192.168.188.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"
Click to expand...

Und Client:


client
dev tun
proto udp
remote meinserver.de 1194 udp
resolv-retry infinite
user nobody
group nobody
persist-tun
persist-key
remote-cert-tls server
cipher AES-256-GCM
auth SHA512
auth-nocache
tls-client
#redirect-gateway def1
verb 3
Click to expand...
 

Attachments

  • Route 2.png
    Route 2.png
    15.4 KB · Views: 101
  • Route 1.png
    Route 1.png
    16.9 KB · Views: 105
Auf den Gateways (Fritzboxen) habe ich zwei Routen gesetzt:
192.168.1.0 / 24 (bzw. 192.168.188.0 / 24) zeigt jeweils auf den VPN Router.
Click to expand...
Das wird so vermutlich nicht funktionieren. Die Fritzboxen dürften den Clients da einen ICMP-Route-Redirect zurückwerfen. ("Hey Alter! Für den Router musst Du nicht über mich gehen! Den kannst Du selbst besser erreichen! Der ist ja in Deinem Netz!").

Ich würde das vermutlich so aufbauen:

Code: 
Netz-A (192.168.10.0/24)
  |
  |
(192.168.10.1/24)
*** VPN-GW-A ***
(192.168.188.10/24)
  |
  |
FBF-A (192.168.188.1)
  .
  .
 {INTERNET}
  .
  .
FBF-B (192.168.188.1)
  |
  |
(192.168.188.10/24)
*** VPN-GW-B ***
(192.168.20.1/24)
  |
  |
Netz-B (192.168.20.0/24)

Der VPN-Router ist dann zwischen FBF und Standortnetz als Gateway gehängt.
 
Last edited by a moderator:
Hast du auf den vpn routern (clients) ip forwarding aktiviert? Habe das seit Jahren so am laufen mit 2 raspis als vpn routern. Die sind im gleichen 10.10.10.n
 
Das mit den Routen in den Fritzboxen dürfte so passen, habe habe hier ein ähnliches Setup laufen. Der OpenVPN-Server muss die beiden Netze hinter den OpenVPN-Clients kennen, d.h. die müssen in die Server-Konfiguration rein. Außerdem muss hier mit auf dem Server für die beiden Clients eine Konfiguration im ccd Verzeichnis erstellt werden, die die verbindungsspezifischen Routen der beiden Clients anpasst.
 
Hmm... ich arbeite nicht mit der "topology subnet" Einstellung, daher ist "client-to-client" bei mir nicht notwendig. Was ich in der config auf dem Server oben vermissen, sind die "route" Definitionen. Es werden zwar welche mit "push" auf die VPN-Clients geschickt, aber der Server selbst muss die ja auch kennen:
Code: 
route 192.168.188.0 255.255.255.0
route 192.168.1.0 255.255.255.0
ohne push davor. Das
Code: 
push "route 192.168.1.0 255.255.255.0"
ist doppelt.
Im ccd Verzeichnis wird außerdem für jeden Client eine Config benötigt, die folgendes für Netz A enthält
Code: 
iroute 192.168.188.0 255.255.255.0
push-remove "route 192.168.188.0 255.255.255.0"
Für Netz B entsprechend mit dessen lokalem IP Bereich.
Der erste Eintrag sagt dem OpenVPN Server, dass er allen Traffic für die 192.168.188.0/24 über diese Verbindung raussenden solll, der zweite entfernt die Route für dieses Subnet wieder zurück in den Tunnel für diesen Client
 
danton said:
Im ccd Verzeichnis wird außerdem für jeden Client eine Config benötigt, die folgendes für Netz A enthält
Code: 
iroute 192.168.188.0 255.255.255.0
push-remove "route 192.168.188.0 255.255.255.0"
Click to expand...
Genau das fehlte!
Jetzt läuft es wie gewünscht, ich danke euch vielmals!
 
greystone wundert sich, dass das icmp-rr hier nicht in die Suppe spuckt. Aber gut. Muss ich dann bei Gelegenheit auch mal so ausprobieren...
 
Last edited by a moderator:
Warum sollte ein icpm route redirect hier in die Suppe spucken? Erstmal müssten wir wissen, ob die Fritzbox solche ICMP-RR Antworten überhaupt sendet. Das erste Paket kommt bei der Fritzbox an, die schickt es an den VPN-Router weiter und gut ist. Wird ein ICMP-RR verschickt, liegt es am PC, ob er diese Information in seine Routing-Tabelle aufnimmt oder nicht. Falls der PC das macht, gehen alle folgenden Pakete dann direkt an das VPN-Gateway und das Standard-Gateway (die Fritzbox) wird entlastet.
 
So wie Du das beschreibst, ist das der Fall, für den ICMP-RR vorgesehen wurde.

ICMP-RR wurde in der Vergangenheit als Sicherheitsrisiko eingestuft (Empfang von unaufgeforderten ICMP-RR Paketen und dadurch Umleitung der Pakete auf ein eigenes Gerät des Angreifers), weswegen es üblicherweise ignoriert wurde.
 
Mit den Sicherheitsbedenken stimme ich dir zu. Ohne ICMP-RR ist die Fritzbox auf dem Hinweg als zusätzlicher Hopp mit drin - sie leitet die erhaltenen Pakete ja weiter. Entsprechend nochmal meine Frage: Warum sollte ICMP-RR hier in die Suppe spucken?
 
Hier nochmal der Vollständigkeit-halber die Config.
(nicht wundern, ich habe die IPs nochmal geändert, 10.10.10.1 ist der externe VPN Server, 10.10.10.2 ist nun der Router von Standort B)
Vielleicht hat ja nochmal jemand das gleiche Problem.
Habe das ganze noch um einen dritten Standort erweitert, auch ohne Probleme.


Server-Settings:
dev tun
port 1194
proto udp

topology subnet
keepalive 10 120
max-clients 100

persist-key
persist-tun
explicit-exit-notify 1

user nobody
group nogroup

client-config-dir /etc/openvpn/staticclients
ifconfig-pool-persist pki/ipp.txt

ca pki/ca.crt
cert pki/issued/server.crt
key pki/private/server.key
crl-verify pki/crl.pem
dh pki/dh.pem

tls-crypt pki/ta.key
tls-version-min 1.2
remote-cert-tls client

cipher AES-256-GCM
data-ciphers AES-256-GCM:AES-192-GCM:AES-128-GCM

auth SHA512

server 10.10.10.0 255.255.255.0 # Trusted VPN subnet
route 192.168.188.0 255.255.255.0
route 192.168.1.0 255.255.255.0
push "route 192.168.188.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0" # Route to Home VPN subnet
push "dhcp-option DNS 8.8.8.8" # DNS1 server for VPN clients
push "dhcp-option DNS 1.1.1.1" # DNS2 server for VPN clients


log /var/log/openvpn/openvpn.log
verb 3
status /var/log/openvpn/openvpn-status.log
status-version 2
Click to expand...

Client-Settings:

client
dev tun
proto udp
remote vpn.meinserver.de 1194 udp
resolv-retry infinite
user nobody
group nobody
persist-tun
persist-key
remote-cert-tls server
cipher AES-256-GCM
auth SHA512
auth-nocache
tls-client
verb 3


<ca>

</ca>
<cert>

</cert>
<key>

</key>
<tls-crypt>

</tls-crypt>
Click to expand...

ccd-Datei (für den Rounter am Standort A)
ifconfig-push 10.10.10.3 255.255.255.0
iroute 192.168.188.0 255.255.255.0
push-remove "route 192.168.188.0 255.255.255.0"
Click to expand...
 

Attachments

  • Gui(kontrolle).png
    Gui(kontrolle).png
    169.4 KB · Views: 109
  • Routen Standort A (kontrolle).png
    Routen Standort A (kontrolle).png
    46.5 KB · Views: 98
  • Einstellung VPN Router Standort A.png
    Einstellung VPN Router Standort A.png
    33.5 KB · Views: 95
  • Route Gateway Standort A.png
    Route Gateway Standort A.png
    50.2 KB · Views: 100
  • Standort A zu B.png
    Standort A zu B.png
    16.9 KB · Views: 102
You must log in or register to reply here.
Back
Top