OpenVPN Routing - Forwarding

Hallo zusammen, und noch schöne Weihnachten.

Ich habe ein Problem mit dem OpenVPN routing und hoffe ihr könnt mir hier weiterhelfen.
Habe bei einem Provider mehrere Server gemietet und eine vereinfachte DMZ / LAN Struktur aufgebaut.
Server1 auf diesen auch OpenVPN läuft hat zwei Netzwerkkarten, eine für die WAN (public IP) und eine für das interne Netzwerk.

Über das interne Netzwerkinterface "enp1s0" vom Server1 sind die anderen Server aus erreichbar. Die anderen Server im LAN Bereich haben keinen Zugriff zum Internet.

Siehe Screenshot

Den VPN Clients weiße ich Feste IP Adressen aus dem VPN Pool zu. Client1: 10.80.0.60
Mein Probleme ist nun das Routing /Forwarding mit dem VPN Netz.

Wenn auf dem Server1 folgende iptables Rule eingetragen wird:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE

Funktioniert der Zugriff auf die Server im LAN 172.16.221.0/24 Das Problem ist nur, das Masquerading. Da nun jeder Client mit der IP 172.16.221.15 unterwegs ist.
Da ich dringend IP basierende FW Rules anlegen muss, ist das leider keine Option.
Die VPN Clients müssten sich mit der im VPN Pool zugewiesenen IP im „LAN Bereich bewegen“ bzw. an die LAN Server authentifizieren.
Wie bewerkstellige ich das am besten. Habe schon auf dem Server1 mit verschiedenen iptables FORWARD Rules experimentiert.
z.B.

iptables -A FORWARD -i tun0 -s 10.8.0.0/24 -d 172.16.221.0/24 -o enp1s0 -j ACCEPT
iptables -A FORWARD -i tun0 -s 10.8.0.80 -o enp1s0 -j ACCEPT

Wenn ich die FORWARD Rules hinterlege, komme ich vom VPN Client aus nicht auf die im LAN befindlichen Server

traceroute 172.16.221.5
traceroute to 172.16.221.5 (172.16.221.5), 64 hops max, 52 byte packets
1 10.8.0.1 (10.8.0.1) 32.160 ms 31.419 ms 31.502 ms
2 * * *
3 * * *

Via MASQUERADE schon

traceroute to 172.16.221.5 (172.16.221.5), 64 hops max, 52 byte packets
1 10.8.0.1 (10.8.0.1) 31.518 ms 31.539 ms 31.171 ms
2 172.16.221.5 (172.16.221.5) 32.231 ms 31.799 ms 31.819 ms

Wo liegt hier das Problem?
Danke für die Hilfe.

Please also mark the comments that contributed to the solution of the article

Content-Key: 529847

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

Printed on: April 26, 2024 at 05:04 o'clock

5 Comments

Latest comment

Den VPN Clients weiße ich Feste IP Adressen

Weiß anmalen hilft aber recht wenig...

https://www.duden.de/rechtschreibung/zuweisen
Der Trick und best practice ist im internen OVPN IP Netz kein NAT (Masquerading) zu machen. In der Regel willst du hier ja immer transparent routen zw. Client und Server und das geht mit Masquerading im Tunnel dann nicht, da du dann inbound immer an der Server NAT Firewall hängen bleibst und hier nur sehr umständlich und limitiert dann mit Port Forwarding arbeiten müsstest.
Schalte also das überflüssige Masquerading im Tunnelnetz selber immer aus, dann erübrigen sich auch die anderen Probleme von selbst.
Leider fehlt hier deine Server Konfig so das eine zielgerichtete Hilfe nicht einfach ist, denn man kann nur raten das du hier ggf. keine weiteren, OVPN Konfig bedingten Fehler, beim Routing gemacht hast wie ein falsches oder fehlendes push route Kommando etc.
Weitere Infos wie immer im hiesigen OVPN Tutorial:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router

danke für den Link, werde ich mir durchlesen.

Ganz genau, nur leider funktoniert der Zugiff hier nur mit NAT, wieso weiß ich selber gerade nicht bzw. steh auf dem Schlauch...
Die Route zum LAN Netz ist in der Server Konfig gepushed

push "route 172.16.221.0 255.255.255.0"

Sonst noch eine Idee wo der Fehler liegen könnte?

Grüße

nur leider funktoniert der Zugiff hier nur mit NAT, wieso weiß

Vermutlich weil dir ganz sicher dann irgendwo eine Route in das OVPN interne IP Netz irgendwo fehlt ?!!
Guckst du auch hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Das ist aber einzig nur bei einer OpenVPN Site2Site Kopplung relevant, niemals aber bei einem Client Dialin VPN. Ist ja auch logisch, da der Client ja dann über den direkt an ihm anliegenden VPN Tunnel eine direkte IP Verbindung auf den Server bekommt, sofern dieser Server dann auch sein Zielder VPN Clients ist und nichts anderes.
Wenn der VPN Client allerdings andere Server im lokalen Netz dieses OVPN Dialin Servers erreichen muss dann benötigen diese weiteren Server logischerweise alle eine statische Route des internen OVPN Netzes auf den OVPN Server als next Hop, das ist ja auch logisch.
Andernfalls würden Antwort IP Pakete dieser Server im Nirwana ihres Default Gateways enden statt wieder zum OVPN Server zu gehen wie es richtig wäre.

diese weiteren Server logischerweise alle eine statische Route des internen OVPN Netzes auf den OVPN Server als next Hop

genau das war das Problem. Hätte ich auch selbst drauf kommen können. Statische Route auf den internen Server gesetzt und es funktoniert.
Typisches "wenn man den Wald vor lauter bäumen nicht mehr sieht" Thema.

Danke für die Hilfe.

Grüße

Hätte ich auch selbst drauf kommen können.

In der Tat ! Sowas sollte ein Netzwerk Administrator immer gleich als Erstes auf dem Radar haben !

Gut wenn nun alles rennt wie es soll.

German solved Question Linux Network Linux

Hotly discussed

Check of ZFW Firewallgleixnerd - 5 Comments