Routing zw. 2 Tunneln auf EINEM openVPN-Server

Mitglied: Gerdchen07

Gerdchen07 (Level 1) - Jetzt verbinden

10.04.2021 um 01:21 Uhr, 1000 Aufrufe, 25 Kommentare

Ich betreibe einen Server, auf dem zwei openVPN-Tunnel laufen. Hinter jedem Tunnel hängt ein lokales Netz, welches jeweils komplett durch den Tunnel ins Internet geleitet wird. Einmal der IP-Bereich 192.168.178.x (tun1) und einmal 192.168.179.X (tun0). Nach außen haben also beide lokalen Netze die gleiche IP.

Die Netzwerke hinter den beiden Tunneln sollen strikt getrennt sein und es soll von dem einen Netz kein Zugriff auf das andere möglich sein, was auch soweit klappt. Nun gibt es aber einen PC (192.168.178.12) auf den auf dem Port 5800 auch aus dem Netz 192.168.179.X zugegriffen werden soll. Das bekomme ich nicht auf die Reihe. Ich habe eine iptables-Regel ausprobiert, mit der es meiner Meinung nach klappen sollte, aber das klappt leider nicht:
iptables -I FORWARD -s 10.8.0.0/24 -p tcp --dport 5800 -d 192.168.178.12 -j ACCEPT

Mache ich traceroute 192.168.178.12, kommt folgendes bei raus:

Es scheint also so, als würde die Anfrage aus dem openVPN-Server heraus ins Internet gehen.

Für Hilfestellungen wäre ich sehr dankbar. Sorry, wenn die Informationen nicht ausreichen sollten. Wenn ihr mir sagt, was ihr braucht, liefere ich den Rest natürlich nach.
Mitglied: 25471
25471 (Level 5)
10.04.2021, aktualisiert um 08:44 Uhr
Deine Regel kann ja nicht stimmen ! Sie besagt ja das alles was eine Absender IP 10.8.0.x mit Port TCP 5800 auf die Ziel IP 192..168.178.12 zugreifen kann.
Das steht ja im völligen Gegensatz zu dem was du oben schreibst, denn dort gibst du an das alle Rechner mit der Absender IP 192.168.179.x auf diesen Rechner zugreifen soll. Damit wäre dann die o.a. Regel unsinnig, denn sie definiert ja die völlig falsche Source IP. Was stimmt denn nun ??
Oder fummelst du in diesem Netz unnötigerweise mit NAT (IP Adress Translation) im Tunnel rum ?
Mache ich traceroute 192.168.178.12, kommt folgendes bei raus:
Uuuhhh wie gruselig... !!
Dort kann man sehen das die VPN Pakete gar nicht im Tunnel bleiben sondern ins öffentliche Internet gehen. Da stimmt also schon generell mal was mit deinem internen IP Routing nicht ! Interner Traffic sollte doch niemals ins Internet geroutet werden !! Aber ohne deine OVPN Konfig Files zu kennen ist das alles freie Raterei und "Shooting into the dark".... Weisst du auch selber.
Ansonsten einmal ins hiesige OpenVPN Tutorial sehen:
https://administrator.de/tutorial/merkzettel-vpn-installation-mit-openvp ...
bzw. bei Site to Site:
https://administrator.de/content/detail.php?id=530283&token=984#comm ...
Dort steht alles was du zu dem Thema wissen musst.
Bitte warten ..
Mitglied: lcer00
10.04.2021 um 08:46 Uhr
Hallo,

was mir nicht klar ist - hat der VPN-Server auch einen Client?

Grüße

lcer
Bitte warten ..
Mitglied: 25471
25471 (Level 5)
10.04.2021 um 09:44 Uhr
Anhand der (FritzBox) IP Adressierung und Schilderung mit dem Wort "Netze" würde ich mal auf ein Site-to-Site Design tippen...?!
Bitte warten ..
Mitglied: Gerdchen07
10.04.2021, aktualisiert um 14:29 Uhr
Hallo,

danke für eure Rückmeldung. Ich versuche euch mal mit allen noch fehlenden Informationen zu versorgen.
- in jedem der beiden lokalen Netze befindet sich ein openVPN-Client (Raspberry Pi).
- Wenn ich Side-to Side richtig verstanden habe, ist das genau das, was ich gerade versuche umzusetzen.
- Bzgl. der IP in iptables habe ich dann wohl was falsch verstanden. Ich dachte, dass ich mit der IP 10.8.0.0/24 alle Rechner die tun0 benutzen auf dem entsprechenden Port auf den einen Rechner zugreifen lasse. Egal, welche lokale IP in dem Netz eingestellt ist. Denn hier war der Gedanke, wenn in dem lokalen Netz der IP-Raum umgestellt wird, muss ich nichts neu konfigurieren. Ziel ist es aus dem Netz 192.168.179.X auf den Rechner 192.168.178.12 zuzugreifen. NAT verwende ich auf dem VPN-Server wie folgt:
Im VPN-Client nutze ich nat so:

Das der interne Netzverkehr im Tunnel bleiben soll, ist mir klar. Hier mal die opvpn.conf beider Tunnel:

Bei traceroute hatte ich zuletzt vom falschen Rechner geprüft. traceroute vom richtige Rechner sieht so aus:

Mehr kommt nicht mehr. Also ich denke, es liegt daran, dass der Einstieg von dem einen in den anderen Tunnel nicht klappt, oder?
Bitte warten ..
Mitglied: 25471
25471 (Level 5)
LÖSUNG 10.04.2021 um 18:33 Uhr
in jedem der beiden lokalen Netze befindet sich ein openVPN-Client (Raspberry Pi).
Also exakt das Setup hier, richtig ?!
https://administrator.de/content/detail.php?id=530283&token=984#comm ...

Was etwas wirr ist deine OpenVPN Konfig. Normal lässt man die zentrale Site als Server laufen und die beiden Locations als Clients so wie es im obigen Beispiel zu sehen ist.
Was du da machst ist schon recht schräg, vermutlich 2 getrennte OpenVPN Instanzen laufen zu lassen ?!
Das ist recht unüblich und lässt so ein bischen vermuten das das eher ohne Plan und Kentniss der OVPN Gegebenheiten umgesetzt wurde.
Auch das beides mal mit einem Gateway Redirect gearbeitet wurde ist schon sehr fragwürdig.
So eine Konfig ist jedenfalls nicht der Weg wie man es richtig macht bzw. wie OpenVPN grundsätzlich designt ist... :-( face-sad
Stell dir mal vor jemand hätte 10 Außenstellen. Da würdest du dann wirklich 10 separate Instanzen auf dem Server laufen lassen ??
Besser ist du überdenkst da nochmal dein gesamtes VPN Konzept ?!
Bitte warten ..
Mitglied: Gerdchen07
10.04.2021, aktualisiert um 20:16 Uhr
Das ganze ist damals so entstanden, weil eine Instanz mit einem einzigen lokalen Netz lief, und ein zweites lokales Netz hinzu kommen musste. Von einem Netz sollte man nicht in das anderen gelangen.
Da erschien es am besten zwei Instanzen zu erstellen. Ich gebe dir Recht, damals waren wir komplett am Anfang mit solchen Sachen. Inzwischen ist der Background etwas gewachsen, aber noch nicht ausreichend groß, um zu verstehen, wie das mit einer Instanz getrennt aufgebaut werden kann.

Das von dir verlinkte Bild kommt in etwa hin. Der Unterschied besteht eigentlich nur darin, dass jedes lokale Netz einen im Grunde gleich konfigurierten VPN Client hat, und der VPN Server ein angemieteter Rechner irgendwo im Internet ist. Wir haben also links im lokalen Netz Client 1 und rechts Client 2. Dazwischen im Internet steht der Server.

Ich habe mir deine Anleitung durchgelesen. Das setzt voraus, dass alle lokalen Netze einen eigenen IP-Raum haben, oder? Bei uns hängt noch ein drittes Netzt in dem Tunnel mit drin, an dem das lokale Nutz mit dem IP-Raum 192.168.179.X angeschlossen ist. Dieses Netz spielte bei meinem ursprünglichen Problem keine Rolle, nutzt aber ebenfalls den IP-Raum 192.168.178.X. Dieses Netz müsste dann wahrscheinlich komplett umgebaut werden. Wie gesagt, das ganze ist über längere Zeit gewachsen und war in der Form so am Anfang natürlich nicht angedacht.
Bitte warten ..
Mitglied: Gerdchen07
11.04.2021, aktualisiert um 23:42 Uhr
Ich hab jetzt mal nach der Anleitung von aqui versucht eine config für den Server und zwei Clients umzusetzen. Ziel soll es sein, die Netze 192.168.178.X und 192.168.179.X auf eine Instanz zu bringen. Wenn das läuft, soll auch das andere Netz umgestellt werden. Hier mal ein Vorschlag für die config-files:

Ich hab die beiden configs mal getestet. Die config für Client1 (192.168.178.X) klappt, aber diese drei Zeilen machen auf dem Server Probleme:

In der syslog steht dann:

Bitte warten ..
Mitglied: 25471
25471 (Level 5)
LÖSUNG 12.04.2021, aktualisiert um 10:45 Uhr
Du willst doch eigentlich keine Client to Client Kommunikation. Warum aktivierst du das dann ?? Besser also weglassen.
Nochmal eine Frage vorab: Welchen Sinn hat es das du mit Gateway Redirect arbeitest und sämtlichen Traffic in den Tunnel routest ? Was ist da deine Intention ? Split Tunneling wäre doch viel sinnvoller, zumal ja sicher in den jeweiligen Locations eh bei allen Clients der Internet Router als Default Gateway eingetragen ist. Ein Gateway Redirect im OpenVPN wäre damit dann doch so oder so nutzlos ?!
Nur um Mal deine Intention dazu zu verstehen...

Der o.a. Fehler rührt vermutlich daher weil du vergessen hast für beide Client eine spezifische Konfig (Common Name) im Directory /etc/openvpn/ccd zu hinterlegen, kann das sein ? Jedenfalls erwähnst du es oben leider mit keinem Wort ?!
Im /ccd Verzeichnis müssen 2 Dateien stehen. Einmal "client1" und einmal "client2" wobei diese Namen immer identisch sein müssen zum konfigurierten Common Name des Clients.
"client 1" hat den Inhalt:
ifconfig-push 10.8.1.2 255.255.255.0
iroute 192.168.178.0 255.255.255.0

"client 2" hat den Inhalt:
ifconfig-push 10.8.1.3 255.255.255.0
iroute 192.168.179.0 255.255.255.0

Das bestimmt pro Client welche feste IP der im internen OVPN Netzwerk bekommt und welche Route zum lokalen IP Netz dahinter liegt. Bzw. das muss mit deinen Zuweiungen in der ipp2.txt übereinstimmen. Diese Pool Geschichte solltest du besser weglassen wenn du statisch routest.

Nur mal nebenbei: Hast du mal überlegt das mit WireGuard zu lösen ? Erheblich einfachere Konfig, bessere Filter Optionen und erheblich bessere VPN Performance:
https://administrator.de/tutorial/merkzettel-vpn-installation-mit-wiregu ...
Bitte warten ..
Mitglied: Gerdchen07
12.04.2021, aktualisiert um 18:47 Uhr
Zunächst mal herzlichen dank für deine Hilfe!!

Stimmt, client-to-client ist Blödsinn. Hab ich rausgenommen.

Gateway Redirect ist wahrscheinlich ein Relict aus den Anfängen. Ziel war es, wie du schon richtig erkannt hast, automatisch allen Traffic durch den Tunnel zu schicken. Daher war das wohl eingestellt. Aber wie du auch richtig vermutest, ist der Raspberry mein DHCP-Server und auch das Default Gateway. Somit geht alles automatisch durch den Tunnel. Also fliegt Gateway Redirect ebenfalls raus. Ich habe also im Server "push "redirect-gateway def1 bypass-dhcp"" und im Client "redirect-gateway" entfernt. Wenn ich allerdings im Server "push "redirect-gateway def1 bypass-dhcp"" entferne startet der VPN nicht mehr, also ist das scheinbar notwendig.

Die Dateien in /etc/openvpn/ccd hatte ich schon angelegt, aber offenbar falsch. Dort stand statt "ifconfig-push 10.8.1.5 255.255.255.0" "ifconfig-push 10.8.1.5 10.8.1.4". Auf meinem Handy läuft auch OpenVPN, damit ich von unterwegs in mein Netz komme. Das heißt für jedes Gerät, dass sich außerhalb des Netzes befindet, und das über die Software in das lokale Netz will, muss ebenfalls einen solche Datei angelegt werden. Richtig?

Die Fehler:
Werden wohl von dieser Zeile ausgelöst:

Ich würde gerne bei OpenVPN bleiben, weil ich mich damit nun schon ein wenig auseinandergesetzt habe. Außerdem möchte ich es auch gerne etwas genauer verstehen.
Bitte warten ..
Mitglied: Gerdchen07
12.04.2021 um 21:04 Uhr
So, jetzt kommen beide Clients über den gleichen Tunnel online. Wie kann ich jetzt definieren, dass alle Rechner aus dem Netz 192.168.179.X den Rechner 192.168.178.12 auf dem Port 5800 erreichen? Alle anderen Zugriffe sollen geblockt werden. Auch das Netz 192.168.178.X soll nicht nach 192.168.179.X gelangen können.
Derzeit erreiche ich keinen Rechner aus dem anderen Netz.
Bitte warten ..
Mitglied: 25471
25471 (Level 5)
13.04.2021 um 10:05 Uhr
Wenn ich allerdings im Server "push "redirect-gateway def1 bypass-dhcp"" entferne startet der VPN nicht mehr, also ist das scheinbar notwendig.
Nein, das ist NICHT notwendig aber ein Push Kommando fürs Routing entweder mit Gateway Redirect oder Split Tunneling musst du haben bei Site-to-Site sonst funktioniert das Routing nicht. Starten tut der Dienst aber auch ohne das Kommando.
muss ebenfalls einen solche Datei angelegt werden. Richtig?
Nein, das ist NICHT richtig. Diese Dateien gelten rein nur für die Clients die eine Site-to-Site Kopplung machen. Logisch, denn die brauchen eine statische IP und die damit verbundene statische Route in ihr lokales Netz.
Bei einem rein mobilen Client ist das natürlich nicht erforderlich und die werden dann normal, dynamisch aus dem /24 Pool des internen OVPN IP Netzes bedient. Ganz einfach und logisch... ;-) face-wink
Werden wohl von dieser Zeile ausgelöst:
Die ist auch nur kosmetisch und kannst du auskommentieren oder entfernen.
Derzeit erreiche ich keinen Rechner aus dem anderen Netz.
Die Frage ist wie nach der "Gateway Redirect" Änderung jetzt deine finale Server Konfig aussieht ?? Es ist gut möglich das du die "push route.." Kommandos vergessen hast, damit ist dann kein Routing möglich.
Ob das Routing sauber rennt kannst du in den beiden Clients immer selber sehen wenn du dort ip route show eingibst oder netstat -r -n.
In den Clients sollten die Routen für jeweils das Server Netz und das andere Client LAN in den Tunnel gehen.
Die Server Konfig sollte so aussehen (Auszug und Annahme das das OVPN Server Netz im IP Netz 192.168.1.0 /24 liegt !!):
server 10.8.1.0 255.255.255.0
client-config-dir ccd
route 192.168.178.0 255.255.255.0
route 192.168.179.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 77.109.148.136"
push "dhcp-option DNS 77.109.148.137"

In den Client Konfig Dateien musst du jeweils das remote Netz "pushen" lassen
ifconfig-push 10.8.1.2 255.255.255.0
iroute 192.168.178.0 255.255.255.0
push "route 192.168.179.0 255.255.255.0"

Bzw. bei Client 2
ifconfig-push 10.8.1.3 255.255.255.0
iroute 192.168.179.0 255.255.255.0
push "route 192.168.178.0 255.255.255.0"

Wenn du nun an jedem Client mit ip route show oder netstat -r -n die Routen kontrollierst solltest du sehen das jeder Client sowohl das lokale Server LAN als auch jeweils das LAN des gegenüberliegenden Clients in der Routing Tabelle hat.
Damit ist dann erstmal eine Any zu Any Kommunikation möglich und du kanns den Zugriff sauber testen.

Gut, es ist nicht das was du willst, da du ja eine gesamte Kommunikation der Clientnetze verhindern willst. Das ist dann kein Problem wenn du die Netzwerk Routen in den Clients in Hostrouten veränderst so das nur einzig die beteiligten Rechner in den Client Netzen kommunizieren können niemand anders aber sonst.
Die Client Konfig Dateien sehen dann so aus:
ifconfig-push 10.8.1.2 255.255.255.0
iroute 192.168.178.0 255.255.255.0
push "route 192.168.179.0 255.255.255.0"

Bzw. bei Client 2
ifconfig-push 10.8.1.3 255.255.255.0
iroute 192.168.179.0 255.255.255.0
push "route 192.168.178.12 255.255.255.255"

Du siehst dann mit ip route show oder netstat -r -n jetzt das die Clients im .179er Netz nur noch den .12er Host im .178er Netz kennen...
Das wars...
Bitte warten ..
Mitglied: Gerdchen07
13.04.2021, aktualisiert um 14:39 Uhr
Danke für die weiteren Hinweise. Ich habe das soweit angepasst. Es bleiben nur noch zwei Fragen:
In der server.conf hast du das eingetragen, weil du angenommen hast, dass der Server im Netz 192.168.1.0 steht:

Mein Server ist aber ein im Internet angemieteter. Welchen IP-Raum statt 192.168.1.0 muss ich dann eintragen? Er gehört ja zu keinem lokalen Netz.

Kann ich den Clients eigene Subnetze zuweisen?
Client1: 10.8.1.0
Client2: 10.8.2.0
Client3: 10.8.3.0

Der Server ist ja eingestellt auf 10.8.1.0
Bitte warten ..
Mitglied: lcer00
13.04.2021 um 15:07 Uhr
Hallo,
Zitat von @Gerdchen07:

Mein Server ist aber ein im Internet angemieteter. Welchen IP-Raum statt 192.168.1.0 muss ich dann eintragen? Er gehört ja zu keinem lokalen Netz.
Also vielleicht nimmst Du mal den besten Freund des Netzwerkadmins - den Bleistift - und zeichnest Deine Netzwerktopologie mal auf.
  • alle Router
  • alle Netzwerksegmente
  • alle vergebenen IP-Adressen

sonst wird das hier glaube ich nix.

Grüße

lcer
Bitte warten ..
Mitglied: Gerdchen07
13.04.2021, aktualisiert um 17:05 Uhr
Bzgl. der getrennten IP-Räume. Das geht doch wahrscheinlich wie folgt:

In den Clientdateien das das folgende:

Bzw. bei Client 2
server - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: lcer00
13.04.2021 um 19:52 Uhr
Hallo,

da fehlt jetzt nur noch das OS des Servers. Aber egal, bei Deinem Setup fehlen womöglich die iroute Anweisungen: https://docs.netgate.com/pfsense/en/latest/troubleshooting/openvpn-irout ...

Wenn Du verschiedene Subnetze für mehrere OpenVPN Server verwendest, musst Du auch die Routen für die Tunnel-Subnetze auf die Clients bringen.

Grüße

lcer
Bitte warten ..
Mitglied: Gerdchen07
13.04.2021, aktualisiert um 21:02 Uhr
Betriebsystem ist Ubuntu 16.04.7 LTS.

Du meinst mit fehlender iroute die in der Client Config?


Wenn Du verschiedene Subnetze für mehrere OpenVPN Server verwendest, musst Du auch die Routen für die Tunnel-Subnetze auf die Clients bringen.
Ich hab doch nur einen Server und aktuell zwei Clients. Du meinst, dass dann auch ein push in die Client Config muss? So?

Hier mal noch mal meine aktuelle server.conf:

Eine Client.conf:

Und die dazugehörige Client Config:

Bitte warten ..
Mitglied: 25471
25471 (Level 5)
14.04.2021, aktualisiert um 13:49 Uhr
Mein Server ist aber ein im Internet angemieteter.
OK hattest du leider nicht erwähnt. :-( face-sad Dann lässt du das Kommando natürlich komplett weg. Dann gibts nur die push Route Kommandos in den Client spezifischen Konfigs.
push "route 10.8.1.0 255.255.255.0"
Das ist Blödsinn, denn das internen OVPN Netz wird immer automatisch gepusht. Den Unsinn kannst du löschen.
dass dann auch ein push in die Client Config muss? So?
Wenn du damit die Client spezifische Konfig auf dem Server meinst ist das richtig. Diese beiden Konfig Dateien stehen auf dem Server im Verzeichnis /ccd und NICHT auf dem Client ! Nur das es da keine Missverständnisse gibt...!
Die 10.8.2.1 an die Clients zu pushen ist Blödsinn, denn das ist immer die IP die der Server selber hast. Damit schaffst du also heilloses Adress Chaos im internen OVPN Netz. Richtig ist
Client 1 Konfig mit lokalem LAN 192.168.178.0 /24 im Server Verz. /ccd :
ifconfig-push 10.8.1.2 255.255.255.0
iroute 192.168.178.0 255.255.255.0
push "route 192.168.179.0 255.255.255.0"

Client 2 Konfig mit lokalem LAN 192.168.179.0 /24 im Server Verz. /ccd :
ifconfig-push 10.8.1.3 255.255.255.0
iroute 192.168.179.0 255.255.255.0
push "route 192.168.178.0 255.255.255.0"


Denk dran das der Name der Konfig Datei dem des Common Names des Clients entsprechen muss das du im Zertifikat angegeben hast.
Die Datei sorgt dann dafür das der Client 1 mit Common Name xyz die feste interne OVPN IP 10.8.1.2 erhält, die OVPN Route ins lokale .178er Netz im Server aktiviert wird auf die .2er IP und gleichzeitig das .179.0er netz an den Client gepusht wird. Analog dann das gleiche bei Client 2. Fertisch...
Eigentlich doch ein ganz einfaches Prinzip ?!
Bitte warten ..
Mitglied: Gerdchen07
14.04.2021, aktualisiert um 22:08 Uhr
Noch mal vielen Dank für die Hilfe!! Sorry, ich war sicher erwähnt zu haben, dass der Server im Internet steht. Aber du hast recht, hatte ich nicht. Wenn ich die Regel "push "redirect-gateway def1"" ganz rausnehme, kommen die Rechner hinter dem Client 10.8.2.1 nicht auf meinen Rechner 192.168.178.12 hinter dem Client 10.8.1.1. Also irgendein push muss wohl drin bleiben.

Die Client Configs im ccd-Verzeichnis habe ich genauso angelegt, wie du es beschrieben hast.

Eine Frage hast du wahrscheinlich überlesen. Ich würde die Clients gerne aufteilen in verschiedene IP-Räume.
Server 10.8.1.1
Client1 10.8.1.2
Client2 10.8.2.1
Client3 10.8.3.1

Geht das? Wenn ja, wie?
Bitte warten ..
Mitglied: lcer00
14.04.2021 um 22:29 Uhr
Hallo,
Zitat von @Gerdchen07:

Eine Frage hast du wahrscheinlich überlesen. Ich würde die Clients gerne aufteilen in verschiedene IP-Räume.
Server 10.8.1.1
Client1 10.8.1.2
Client2 10.8.2.1
Client3 10.8.3.1

Geht das? Wenn ja, wie?

So nicht. Aber mit je einem Server(Instanz) pro Client (Server und Client müssen im gleichen/gemeinsamen Tunnel-Subnetz liegen). Dann musst Du aber die Route 10.8.0.0/16 -> 10.8.X.1 auf die Clients pushen. Aber wie @25471 oben schon ausführte - eigentlich so nicht gedacht und wozu auch?

Grüße

lcer
Bitte warten ..
Mitglied: Gerdchen07
14.04.2021, aktualisiert um 23:30 Uhr
OK, danke. Ich dachte, es wird so übersichtlicher. Vor allem zum definieren der iptables.

Kann man alternativ sagen, alle Rechner hinter Client1 haben einen IP-Bereich von 10.8.1.1 bis 10.8.1.10, hinter Client2 von 10.8.1.11 bis 10.8.1.20?
Bitte warten ..
Mitglied: lcer00
15.04.2021, aktualisiert um 07:16 Uhr
Zitat von @Gerdchen07:

OK, danke. Ich dachte, es wird so übersichtlicher. Vor allem zum definieren der iptables.
Das ist Quatsch. Für die Firewall ist nur die Quell-IP (Deine beiden LANs) oder die Ziel-IP relevant. Nicht die IP des Tunnelnetzwerks.

Oder aber das eingehende Interface. Das ist aber abhängig vom OS des Servers nicht immer komplett für routing und Firewall verfügbar.

https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4 ...

tun devices encapsulate IPv4 or IPv6 (OSI Layer 3) while tap devices encapsulate Ethernet 802.3 (OSI Layer 2).

Mit TAP sollte das Interface routbar und für die Firewall verfügbar sein, mit TUN nicht unbedingt.


Grüße

lcer

PS: wo hast Du eigentlich überall das NAT aktiviert?
Bitte warten ..
Mitglied: Gerdchen07
15.04.2021 um 20:57 Uhr
NAT nutze ich im Server:

und im Client:

iptables habe ich so formuliert:

Bitte warten ..
Mitglied: lcer00
15.04.2021, aktualisiert um 22:29 Uhr
Hallo,

Das NAT gehört an die Schnittstelle, an der Dein privates Netz in das Öffentliche Netz übergeht. Das wäre das Internet-Interface des Servers. Wozu soll das NAT am Client sein? Du Routest ohne NAT bis zum Server und nur dort brauchst Du NAT.

Deine iptable-Rules in Zeile 8 und 9 passen nicht zu Zeile 4 (First match wins).

Grüße

lcer
Bitte warten ..
Mitglied: Gerdchen07
15.04.2021, aktualisiert 16.04.2021
Danke für die weiteren Hinweise!

Die iptables sind doch hierarchisch aufgebaut. Das heißt die Regel in Zeile 4 verbietet erst mal alles. Dann wird in Zeile 8 und 9 explizit definiert, was erlaubt ist. Zumindest funktioniert es auch so, dass nur diese beiden Geräte in das 178er Netz kommen.

Das NAT gehört an die Schnittstelle, an der Dein privates Netz in das Öffentliche Netz übergeht. Das wäre das Internet-Interface des Servers. Wozu soll das NAT am Client sein? Du Routest ohne NAT bis zum Server und nur dort brauchst Du NAT.
venet0 ist ja das Internet-Interface des Servers. Und da gehts doch ins öffentliche Netz. Was ist falsch? Sorry, steh evtl auf dem Schlauch. Die Regel im Client hatte ich von jemandem so übernommen. Ohne die kommen meine Rechner hinter dem Client nicht online
Bitte warten ..
Mitglied: 25471
25471 (Level 5)
16.04.2021, aktualisiert um 16:10 Uhr
Ohne die kommen meine Rechner hinter dem Client nicht online
Zeigt das da grundlegend was falsch läuft mit dem Routing ! NAT sollte man nicht im internen Netz machen, denn damit schaffst du dir immer eine Einbahnstrasse, da Endgeräte die NAT Firewall ja nicht überwinden können. NAT ist überflüssig und meist auch kontraproduktiv im internen Netz besonders bei einer Site-to-Site Kopplung.
Bitte warten ..
Heiß diskutierte Inhalte
Off Topic
Aqui - Wir möchten den Hasen zurück
NixVerstehenVor 23 StundenAllgemeinOff Topic36 Kommentare

Lieber aqui, ich finde es sehr sehr schade, das du dich hier so überraschend abgemeldet hast. Ich habe auch von dir sehr viel gelernt ...

Netzwerke
Erfahrungen mit HPE Aruba Switches (Aruba OS)
sixofeightVor 1 TagAllgemeinNetzwerke13 Kommentare

Holla zusammen, Wer von euch setzt Aruba Switches (Aruba OS, ehemals HP ProCurve) ein und wie sind eure Erfahrungen bzw. wie zufrieden seid ihr ...

Webentwicklung
Webdesigner ist verschwunden
Janno100Vor 1 TagFrageWebentwicklung4 Kommentare

Hallo zusammen Kunde hat einen Webdesigner der die Domain des Kunden vor einigen Jahren einfach unter seinen eigenen Name weiter geführt hat. Diese haben ...

Windows 10
Was ist zu wenig
ukulele-7Vor 9 StundenFrageWindows 1013 Kommentare

Hallo, ich suche nach einer Quelle um Windows 10 Pro OEM Lizenzen zu beziehen, gerne auch erstmal ein paar als Testkauf. Nun ist das ...

Exchange Server
Exchange weist Mails ohne Log Eintrag ab
Mr.RobotVor 13 StundenFrageExchange Server16 Kommentare

Guten Morgen, wir haben seit letzter Woche ein ganz spannendes "Problem" oder sollte ich eher Phänomen sagen? Wir haben eine Tochtergesellschaft die allerdings IT-Technisch ...

Windows Server
Server clonen
oGutITVor 1 TagFrageWindows Server5 Kommentare

Hallo ich habe einen alten HP Server Gen8 und möchte diese auf einen HP Microserver Gen8 klonen. Auf dem HP Server ist 2W12KR2 am ...

Netzwerke
2 fritzen mit unterschiedlichen subnetzen einrichten
gelöst alpi972Vor 1 TagFrageNetzwerke7 Kommentare

Hallo, hoffe ich habs unters richtige thema gesetzt, ich habe 2 fritzboxen (eine 7490 als DSL Modem und eine 7430 als Brige), und will ...

Router & Routing
Windows Netzwerklaufwerke durch kaskadiertes Netzwerk nicht ansprechbar
TomAustriaVor 1 TagFrageRouter & Routing5 Kommentare

Hallo, wir hatten bisher nur ein "einfaches" Netzwerk und möchten dieses nun in getrennte Netzwerksegmente aufteilen: Das Netz 192.168.2.x haben wir beim AX1500 an ...