[gelöst] OpenVPN Client einrichten und Netz dahinter verfügbar machen

[theq86]

Hallo,

ich möchte, dass die opnSense eine OpenVPN Verbindung aufnimmt und das virtuelle Netz dahinter über Routing bereitstellt.

Folgende Config hat der Server:

Code: [Select]

dev tun
port 1194
proto udp
mode server
topology subnet
server 10.8.1.0 255.255.255.0
keepalive 10 60
ifconfig-pool-persist ipp.txt
float
push "route 10.8.0.0 255.255.255.0"
push "route 10.8.2.0 255.255.255.0"
push "route 10.8.3.0 255.255.255.0"
push "route 10.8.4.0 255.255.255.0"
push "route 10.8.5.0 255.255.255.0"
push "route 10.8.6.0 255.255.255.0"
push "route 10.8.7.0 255.255.255.0"
push "route 10.8.8.0 255.255.255.0"
push "route 10.8.9.0 255.255.255.0"
push "route 10.8.10.0 255.255.255.0"
push "route 10.8.11.0 255.255.255.0"
push "route 10.8.12.0 255.255.255.0"
push "dhcp-option DNS 10.8.0.10"
client-to-client
ca /etc/openvpn/easy-rsa2/keys/ca.crt
cert /etc/openvpn/easy-rsa2/keys/server.crt
key /etc/openvpn/easy-rsa2/keys/server.key
dh /etc/openvpn/easy-rsa2/keys/dh2048.pem
comp-lzo yes

Der VPN Server selbst ist aus dem Internet erreichbar (über WAN) und hat die private IP 10.8.0.10. Das von OVPN "gespannte" netz ist 10.8.1.0/24. Die Netze 10.8.x.0/24 sind Netze in denen Container laufen.

Ich möchte erreichen, dass ich aus dem LAN meiner opnSense diese Netze erreichen kann, ohne dass ich auf jedem Client OpenVPN installiert haben muss.

Eine Client-Config habe ich der OPNSense schon gegeben und die Verbindung ist stabil und auf up. Meine virtuelle IP ist 10.8.1.12.

------------------------------------------
Lösungsideen:

- Ich erstelle ein Interface auf ovpnc2 woraufhin der Router dieses Netz eigentlich kennen sollte
- Ich erstelle ein paar Firewallregeln, die den Traffic durchlassen.

Leider funktioniert das nicht bei mir. Ich weiß auch ehrlich gesagt nicht, wie ich das Interface konfigurieren soll.
Ich verstehe die Logik dahinter noch nicht.

Ich habe eine aktive OpenVPN Verbindung. Meine (Client)-IP ist 10.8.1.12. Wenn ich jetzt von der Verbindung ein Interface erstelle, wie/welche IP soll ich dem denn geben? Die Verbindung hat doch schon eine IP.

Bin gerade am Baum und seh nur Wald.

Übrigens:Auf der Shell der opnSense kann ich alle Netze problemlos erreichen. Nur wenn ich versuche, von einem LAN Client eine solche Adresse zu erreichen funktioniert es leider nicht. Die virtuelle IP der OpenVPN Verbindung 10.8.1.12 kann ich jedoch aus dem LAN erreichen.

Link zur Lösung:
https://forum.opnsense.org/index.php?topic=6809.msg29601#msg29601

[chemlud]

..Firewallregel auf dem openVPN Tab in der GUI erstellt? Outbound NAT rule mit Interface = WAN für die externen Netze ist vorhanden?

[theq86]

Ja, ist alles vorhanden.

Es scheint zu funktionieren, wenn ich eine Outbound-NAT Regel auf mein OpenVPN Interface lege.
Wobei es ja eigentlich auch ohne NAT gehen müsste. Ich meine es ist eigentlich nur Routing. Wäre jedenfalls von Vorteil, wenn die Source-IP bestehen bleibt...

[JeGr]

OK ich muss nochmal nachfragen, denn das ist irgendwie ein wenig konfus in deinem Post:

Das OVPN Transfernetz ist 10.8.1.0/24 korrekt?

Warum nutzt du die anderen 10.8.x.0/24er Netze? Ist das Zwang oder gewollt? Denn ich habe den Eindruck, dass da eine Überschneidung stattfinden könnte.

Wenn bei Docker (ich kann mich dumpf entsinnen) die 10.xer Netze eh schon voreingestellt sind, würde ich das Transfernetz von OVPN erstmal komplett da rauslösen und in ein ganz anderes Netz schubsen, nimm meinetwegen bspw. 10.99.99.0/24 damit es eindeutig getrennt ist von den Netzen dahinter!

Wichtig bei der Diagnose sind dann auch erstmal bspw. die Routingtabellen auf dem Server und dem Client. Sind dort die Docker Netze 10.8.x überhaupt bekannt? Werden sie korrekt gepusht etc.
Dann als nächstes auf den OVPN Interfaces auf beiden Seiten mal einen TCPDump lauschen lassen, ob bspw. ein Ping an 10.8.x.y korrekt in den Tunnel rein geht und auf der anderen Seite raus kommt und ob umgekehrt ACKS vielleicht verschluckt werden bzw. wegen falschem Routing gar nicht mehr hier ankommen.

> - Ich erstelle ein Interface auf ovpnc2 woraufhin der Router dieses Netz eigentlich kennen sollte

Kannst du, musst du aber nicht zwingend, außer du brauchst das Interface bzw. Gateway für PolicyBasedRouting zwangsweise irgendwo. Ansonsten ist das Netz der Routingtabelle auch ohne Zuweisung bekannt, weil der OVPN Server das in die Routing Tabelle haut. Ob es für dich sichtbar das Interface gibt oder nur auf der Konsole spielt dabei keine Rolle.

Gruß

[theq86]

Okay, ich konkretisiere den Netzaufbau noch mal.

Es ist ein Entwicklungssystem das aus einem Verwaltungsserver, mehreren Virtual Hosts und darin mehreren LXC Containern besteht.

Der Verwaltungsserver (10.8.0.10) beherbergt den VPN Server sowie einen DNS Server.
Die Virtuellen Hosts (10.8.0.11 - 10.8.0.21) stellen jeweils einem Entwickler die Möglichkeit zur Verfügung eigene LXC Container als virtuelle Maschinen zu verwalten.
Die Interfaces der Virtuellen Hosts sind gebridged mit den virtuellen Interfaces der LXC Container.
10.8.0.0/24 ist das "reale" Netz
10.8.1.0/24 ist das OpenVPN Transfernetz
10.8.x.0/24 sind auf den jeweiligen VHosts die von der Containersoftware verwendeten virtuellen Netze.

Jeder Entwickler kann also über seinen VHost beliebige OS-Container verwalten und deshalb haben wir auch so viele Netze, da jeder VHost für seine Container ein eigenes Subnetz hat.

Diese Kostellation läuft auch schon ne ganze Weile und soweit auch gut ohne Überschneidungen.

Bisher hat jeder Entwickler einen VPN Zugang zum Verwaltungsserver erhalten und sich mit seiner Workstation verbunden. Er konnte dann so auf die VHosts und die dahinterliegenden VMs zugreifen.

Jetzt kommt die opnSense ins Spiel. Mit dieser haben wir jetzt eine solide Firewall-Lösung die es uns erlaubt nur noch eine VPN Verbindung zum Verwaltungsserver zu haben und das Firmennetz direkt mit dem Entwicklungssystem zu verbinden. Die Sense soll das ganze Routing machen und die Clients müssen dann folglich nicht mehr ihre eigene VPN Verbindung herstellen.

TLDR;

Selbst wenn ich dieses Setup vereinfache und lediglich das 10.8.0.0/24 erreichen möchte, komme ich ohne NAT leider nicht weiter. Auf der Sense läuft alles super. Eventuell ist diese aber auch nicht das Problem...

[chemlud]

...du hast es jetzt geschafft, dreimal über deine Konfiguration zu schreiben, aber weder die Client config noch NAT noch Firewallregeln auf der opnsense zu zeigen (und NAT und Firewallregeln auf dem Server auch nicht, oder?). Reife Leistung! ;-)

Ohne Details wird das hier keiner für dich debuggen können. Schon mal Server und Client vertauscht?

[theq86]

...du hast es jetzt geschafft, dreimal über deine Konfiguration zu schreiben, aber weder die Client config noch NAT noch Firewallregeln auf der opnsense zu zeigen (und NAT und Firewallregeln auf dem Server auch nicht, oder?). Reife Leistung! ;-)

  hast ja Recht.

VPN Server Config siehe Originalpost.

VPN Client config von der Sense:

Code: [Select]

dev ovpnc2
verb 3
dev-type tun
tun-ipv6
dev-node /dev/tun2
writepid /var/run/openvpn_client2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher BF-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 84.153.213.63
tls-client
client
lport 0
management /var/etc/openvpn/client2.sock unix
remote lxc.plt-dev.de 1194
ca /var/etc/openvpn/client2.ca
cert /var/etc/openvpn/client2.cert
key /var/etc/openvpn/client2.key
comp-lzo adaptive

ovpnc2 hat bei mir ein Interface DEV bekommen. In den FW Regeln steht testweise, dass an DEV sämtlicher Verkehr erlaubt ist.

Routingtabelle OPNSense:

Code: [Select]

ipv4 default 62.155.243.138 UGS 192448 1492 pppoe0 wan
ipv4 10.0.0.0/24 link#1 U 9705463 1500 re0 LAN
ipv4 10.0.0.1 link#1 UHS 0 16384 lo0
ipv4 10.1.0.0/24 link#6 U 0 1500 ue0 MODEM
ipv4 10.1.0.1 link#6 UHS 0 16384 lo0
ipv4 10.2.0.0/24 link#8 U 281437 1500 re0_vlan2 MEDIA
ipv4 10.2.0.1 link#8 UHS 0 16384 lo0
ipv4 10.3.0.0/24 10.3.0.2 UGS 0 1500 ovpns1
ipv4 10.3.0.1 link#7 UHS 0 16384 lo0
ipv4 10.3.0.2 link#7 UH 21718 1500 ovpns1
ipv4 10.8.0.0/24 10.8.1.1 UGS 4 1500 ovpnc2 DEV
ipv4 10.8.1.0/24 10.8.1.1 UGS 0 1500 ovpnc2 DEV
ipv4 10.8.1.1 link#10 UH 0 1500 ovpnc2 DEV
ipv4 10.8.1.12 link#10 UHS 0 16384 lo0
ipv4 10.8.2.0/24 10.8.1.1 UGS 0 1500 ovpnc2 DEV
ipv4 10.8.3.0/24 10.8.1.1 UGS 0 1500 ovpnc2 DEV
ipv4 10.8.4.0/24 10.8.1.1 UGS 0 1500 ovpnc2 DEV
ipv4 10.8.5.0/24 10.8.1.1 UGS 2 1500 ovpnc2 DEV
ipv4 10.8.6.0/24 10.8.1.1 UGS 0 1500 ovpnc2 DEV
ipv4 10.8.7.0/24 10.8.1.1 UGS 0 1500 ovpnc2 DEV
ipv4 10.8.8.0/24 10.8.1.1 UGS 0 1500 ovpnc2 DEV
ipv4 10.8.9.0/24 10.8.1.1 UGS 0 1500 ovpnc2 DEV
ipv4 10.8.10.0/24 10.8.1.1 UGS 0 1500 ovpnc2 DEV
ipv4 10.8.11.0/24 10.8.1.1 UGS 0 1500 ovpnc2 DEV
ipv4 10.8.12.0/24 10.8.1.1 UGS 0 1500 ovpnc2 DEV
ipv4 62.155.243.138 link#9 UH 0 1492 pppoe0 wan
ipv4 84.153.213.63 link#9 UHS 0 16384 lo0
ipv4 127.0.0.1 link#3 UH 14637 16384 lo0
VPN Server (Linux) Routing Tabelle

Code: [Select]

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         10.8.0.1        0.0.0.0         UG        0 0          0 eth0
10.8.0.0        *               255.255.255.0   U         0 0          0 eth0
10.8.1.0        *               255.255.255.0   U         0 0          0 tun0
Auf dem VPN Server sind keine FW Regeln definiert und auch kein masquerading
IP Forwarding ist allerdings eingeschaltet.


Auf der OPNsense kann ich folgende Outbound NAT-Regel verwenden, damit es wenigstens mit NAT funktioniert:
Interface DEV
Source Any
Destination 10.8.0.0/16 (/16 wegen der ganzen anderen Netze)
Adress: Interface Address

[chemlud]

"Auf der OPNsense kann ich folgende Outbound NAT-Regel verwenden, damit es wenigstens mit NAT funktioniert:
Interface DEV
Source Any
Destination 10.8.0.0/16 (/16 wegen der ganzen anderen Netze)
Adress: Interface Address"

...und da wäre dann auch das virtuelle Netz des Tunnels drin. Ist das gut? Einzeln aufführen?

Die Sense muss dem Server auch doch noch ihr(e) lokales/en Netz(e) bekanntgeben, oder? Da sehe ich nix in der Config...

[theq86]

Nabend!

Ich habe endlich die Lösung. Es haben hier und da noch Kleinigkeiten gefehlt.

@chemlud: Vollkommen korrekt. Der Server pushte zwar seine remote networks, aber ich habe meine nicht in der Server-Config hinterlegt. Somit konnte OpenVPN auch keine Routen in mein Netz bereitstellen.

Hier die funktionierende Server-Config - Änderungen fett markiert:

dev tun
port 1194
proto udp
mode server
topology subnet
server 10.8.1.0 255.255.255.0
keepalive 10 60
ifconfig-pool-persist ipp.txt
float
# Wird benötigt, damit OpenVPN eine Route zu diesem Netz bereitstellt
route 10.0.0.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"
push "route 10.8.2.0 255.255.255.0"
push "route 10.8.3.0 255.255.255.0"
push "route 10.8.4.0 255.255.255.0"
push "route 10.8.5.0 255.255.255.0"
push "route 10.8.6.0 255.255.255.0"
push "route 10.8.7.0 255.255.255.0"
push "route 10.8.8.0 255.255.255.0"
push "route 10.8.9.0 255.255.255.0"
push "route 10.8.10.0 255.255.255.0"
push "route 10.8.11.0 255.255.255.0"
push "route 10.8.12.0 255.255.255.0"
push "dhcp-option DNS 10.8.0.10"
client-to-client
ca /etc/openvpn/easy-rsa2/keys/ca.crt
cert /etc/openvpn/easy-rsa2/keys/server.crt
key /etc/openvpn/easy-rsa2/keys/server.key
dh /etc/openvpn/easy-rsa2/keys/dh2048.pem
comp-lzo yes
# Wird benötigt um je nach connectetem Client Netzwerke zu pushen
client-config-dir ccd

Im Verzeichnis ccd das in der Config eingetragen wurde müssen die Netze, die ein Client pushen soll ebenfalls eingetragen werden. Der Dateiname ist gleich des X.509 CommonName des connectenden Clients.
ccd/opnsense-dev

Code: [Select]

iroute 10.0.0.0 255.255.255.0

Die Client-Config auf der opnSense bedurfte keiner zusätzlichen Änderungen.

Die NAT-Regel aus meinem Vorpost habe ich gelöscht, die wird nicht mehr benötigt.

Vielen Dank für die Anregungen und den kleinen Gesäßtritt