[Problem] OpenVPN Routing-Problem bei LAN-LAN-Kopplung

LittleNoMuc

Neuer User
Mitglied seit
11 Nov 2013
Beiträge
27
Punkte für Reaktionen
0
Punkte
0
Ich kämpfe seit 2 Tagen an der Verknüpfung meiner zwei Netzwerke über OpenVPN und bin bei meinen Google-Suchen immer wieder hier im Forum gelandet, ihr habt anscheinend überdurchschnittliche OpenVPN-Kompetenzen :roll: Deshalb bin ich mal so frei und erläutere hier mein Problem(e).

Der Übersichtlichkeit halber als erstes mal eine Darstellung der Topologie:
Topologie.jpg

Kurzversion des Zustands:

Netz A ist über eine Fritzbox 7412 an einem VDSL mit (dynamischer) öffentlicher IP online und über einen DynDNS-Namen (mydomain.de in den anonymisierten conf-Dateien) erreichbar. Lokales Netz 192.168.3.0.

In Netz A gibt es einen Ubuntu-Server der (unter Anderem) als OpenVPN-Server fungiert, deshalb sind hier die UDP-Ports 1194 & 1195 in der Fritzbox zu diesem Server (192.168.3.130) weitergeleitet. Es sind zwei OpenVPN-Server-Konfigurationen aktiv, von denen eine zur Anbindung des entfernten Netzes (Netz B) dient (server1), die andere für ein einzelnes iPhone von außen (server2).

Netz B ist über eine Fritzbox 7390 die hinter einem LTE-Router sitzt, online. Lokales Netz 192.168.20.0.

In Netz B befindet sich ein Raspberry Pi (mit Ubuntu MATE, 192.168.20.24) als OpenVPN-Client.

Ziel: Es sollen alle Clients aus beiden lokalen Netzen einschließlich das iPhone untereinander kommunizieren können. Um das zu erreichen sind in der OpenVPN-Konfiguration entsprechende push-Routen angelegt und in den Fritzboxen der beiden Netze statische Routen, die für die jeweils entfernten Adressbereiche das VPN-Gerät als Gateway angeben.

Was alles funktioniert:
  • Die Tunnel sind beide aktiv
  • Ping, im einzelnen:
vom Ubuntu-Server nach 10.8.0.10, 192.168.20.24
von Client-PC aus Netz A nach 10.8.0.10, 192.168.20.24, als auch auf die entfernte Fritzbox 192.168.20.1
vom Raspi aus Netz B nach 10.8.0.1, 192.168.3.130, als auch auf die entfernte Fritzbox 192.168.3.1 sowie einen Client in Netz A (192.168.3.154)
vom Client-PC aus Netz B nach 192.168.3.130, als auch auf die entfernte Fritzbox 192.168.3.1 sowie einen Client in Netz A (192.168.3.154)​

  • Webseiten-Aufruf vom iPhone innerhalb Netz A (also auf Ubuntu-Server als auch einem anderen Gerät in Netz A, bspw. 192.168.3.154)
  • Webseiten-Aufruf vom Raspi in Netz B von allen Geräten in Netz A, also 192.168.3.130, 192.168.3.1, 192.168.3.154
  • SSH vom Ubuntu-Server durch den Tunnel an den Raspi über 10.8.0.10 als auch über 192.168.20.24
  • SSH vom Client-PC in Netz A durch den Tunnel an den Raspi über 10.8.0.10 als auch über 192.168.20.24
  • SSH vom Raspi in Netz B durch den Tunnel an den Ubuntu-Server über 10.8.0.1 als auch über 192.168.3.130

Was nicht geht:

  • SSH vom Client-PC in Netz B durch den Tunnel an den Ubuntu-Server über 192.168.3.130
  • Webseiten (http) oder Dateifreigaben (smb) durch die Tunnel, im einzelnen:
vom Client-PC in Netz B durch den Tunnel nach 192.168.3.130, 192.168.3.1, 192.168.3.154 >> timeout
vom Client-PC in Netz A durch den Tunnel nach 10.8.0.10, 192.168.20.24, 192.168.20.1 >> timeout
vom iPhone durch beide Tunnel nach 10.8.0.10, 192.168.20.24, 192.168.20.1 >> timeout​

  • Ping aus Netz A (von allen Punkten) an ein Gerät in Netz B welches eine feste IP (192.168.2.200) hat (alles andere hängt am DHCP)

Bereits unternommene Lösungsversuche:
  • mit den Optionen "tun-mtu", "fragment" und "mssfix" herumexperimentiert, ohne irgendeine Veränderung
  • Testweise die Firewalls auf Ubuntu-Server und Raspberry Pi komplett abgeschaltet, ohne irgendeine Veränderung

Und hier noch meine Konfigurationsdateien:

Auf Ubuntu-Server in Netz A, server1.conf:

Code:
port 1194proto udp
dev tun


ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key  # This file should be kept secret
dh ./easy-rsa2/keys/dh2048.pem


server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp_hhsl.txt


push "route 192.168.3.0 255.255.255.0"
push "route 10.8.1.0 255.255.255.0"


client-config-dir ccd
route 192.168.20.0 255.255.255.0


client-to-client


keepalive 10 120


tls-auth ./easy-rsa2/keys/ta.key 0 
cipher AES-256-CBC   # AES


comp-lzo


user openvpn
group openvpn


persist-key
persist-tun


status openvpn-status_hhsl.log


verb 3


tun-mtu 1200 
fragment 1200 
mssfix 1200

Im Unterverzeichnis ccd eine Datei mit Dateinamen identisch dem Common Name des Client-Zertifikats und dem Inhalt:
Code:
iroute 192.168.20.0 255.255.255.0

Auf Ubuntu-Server in Netz A, server2.conf:

Code:
port 1195

proto udp


dev tun1


ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key 
dh ./easy-rsa2/keys/dh2048.pem


server 10.8.1.0 255.255.255.0


ifconfig-pool-persist ipp_vic.txt


push "route 192.168.3.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"


push "redirect-gateway def1 bypass-dhcp"


push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"


client-to-client


keepalive 10 120


tls-auth ./easy-rsa2/keys/ta.key 0 


comp-lzo




user openvpn
group openvpn


persist-key
persist-tun


status openvpn-status_vic.log


verb 3

Desweiteren ist auf dem Ubuntu-Server IPv4-Routing aktiviert und in der ufw-Firewall diese Routen erlaubt.


Auf Raspberry Pi in Netz B, client.conf:

Code:
clientdev tun
proto udp
remote mydomain.de 1194
resolv-retry infinite
nobind
persist-key
persist-tun


ca ca.crt
cert hhsl.crt
key hhsl.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
comp-lzo
verb 3
tun-mtu 1200
fragment 1200
mssfix 1200

Außerdem auch auf dem Raspberry das IPv4-Routing aktiviert.


iphone.ovpn:

Code:
clientdev tun1
proto udp
remote kunterbuntcloud.de 1195
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert vic.crt
key vic.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
comp-lzo
verb 3

Die statischen Routen der Fritzbox in Netz A:
RoutenNetzA.png

Die statischen Routen der Fritzbox in Netz B:
RoutenNetzB.png


Da ich den Wald vor lauter Bäumen nicht mehr sehe oder vielleicht auch einfach irgendeinen logischen Fehler mache, würde ich mich über Input was ich noch tun könnte oder wo ich was falsch mache, sehr freuen :D
 
Zuletzt bearbeitet:
Denk mal in Ruhe über die push "route ..." Angaben nach.
 
mach ich jetzt seit 2 Tagen :confused: klär mich auf
 
Sinn und Zweck von push "route ...". Es gibt dazu im Netz viele Hinweise.
 
besagte Hinweise haben mich an den jetzigen Punkt gebracht :grin:
 
https://openvpn.net/index.php/open-source/documentation/howto.html#scope

Die Mütter und Väter von OpenVPN sagen:

"The last step, and one that is often forgotten, is to add a route to the server's LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box
(you won't need this if the OpenVPN server box is the gateway for the server LAN). Suppose you were missing this step and you tried to ping a machine
(not the OpenVPN server itself) on the server LAN from 192.168.4.8? The outgoing ping would probably reach the machine,
but then it wouldn't know how to route the ping reply, because it would have no idea how to reach 192.168.4.0/24.
The rule of thumb to use is that when routing entire LANs through the VPN (when the VPN server is not the same machine as the LAN gateway),
make sure that the gateway for the LAN routes all VPN subnets to the VPN server machine."
 
Zuletzt bearbeitet:
The rule of thumb to use is that when routing entire LANs through the VPN (when the VPN server is not the same machine as the LAN gateway),
make sure that the gateway for the LAN routes all VPN subnets to the VPN server machine."
Genau das aber ist doch der Fall bei mir? in beiden Fritzboxen sind diese statischen routen mit Verweis auf den VPN-Handler als Gateway angelegt
 
@LittleNoMuc:
Nicht kritische Stellen, die man aber bei Gelegenheit auch korrigieren sollte:

- .200 für den AP in Netz B ist unglücklich gewählt ... hier reicht schon ein einziger (ungewollter) Haken in einer Checkbox in der Benutzerverwaltung (bei "VPN"), damit die Box selbst per Proxy-ARP als .200 antwortet (Standard-Konfiguration für das Netzwerk mal unterstellt) und dann hängt das Funktionieren einer Verbindung zu dieser IP-Adresse davon ab, wer schneller entsprechende Requests beantwortet, die FRITZ!Box oder der AP.

- die Option "client-to-client" routet normalerweise innerhalb von OpenVPN direkt zwischen zwei Clients (das meint OpenVPN-Clients). Das geht natürlich nur dann, wenn das nicht zwei getrennte OpenVPN-Instanzen sind - insofern macht diese Option hier nicht so sehr viel Sinn, solange es keinen weiteren Client (pro Instanz) gibt. Vielleicht wäre es hier sogar besser, die beiden Konfigurationen zusammenzulegen, denn die erste arbeitet ja schon mit clientspezifischer Konfiguration (per ccd) und - solange nicht gute Gründe dagegen sprechen, die hier aber nicht zu lesen sind bisher - da ist das Erstellen einer weiteren Client-Konfiguration dann ja der naheliegendere Fall ... besonders hier, wo dem Augenschein nach beide Serverinstanzen auch dieselben Schlüssel und Zertifikate verwenden.

- die Routen zu den 10.x-Adressen in LAN A dürften/sollten nutzlos sein ... außer Du hast direkt auf dem VPN-Gateway in LAN B (auf 10.8.0.10) irgendwelche Dienste laufen, die nur auf dieser Adresse antworten und auf der 192.168.20.24 nicht - ansonsten ist das ein reines Transitnetz und dürfte in beiden LANs (mit Ausnahme der jeweiligen (VPN-)Gateways) keine Rolle in irgendwelchen Datenverbindungen spielen.


-Ansonsten hören sich die Probleme für mich danach an, daß da gar kein "transit" aus dem Netz 192.168.20.0/24 an eine Adresse aus 192.168.3.0/24 über die FRITZ!Box als Default-Gateway, die das ihrerseits an den Host 192.168.20.24 weiterleitet, im Tunnel ankommt. Zwar steht da irgendwo auch "das komplette Abschalten von Firewalls hat nicht geholfen", je nachdem, wie man das macht, wird aber auch das Routing dabei i.d.R. komplett deaktiviert (wenn das irgendwelche Skript-Abläufe sind) und außerdem ist das sicherlich ohnehin keine "Dauerlösung", so etwas ohne Firewall zu betreiben.

Bei aktivierter Firewall auf dem RasPi (und aktiviertem IPv4-Routing) muß dort auch "FORWARD" von 192.168.20.0/24 nach 192.168.3.0/24 erlaubt sein - sonst kommen Pakete aus dem LAN B nicht auf dem TUN-Interface an.

Alles in allem ist hier sicherlich "tcpdump" das Mittel der Wahl bei der Fehlersuche ... setzt man das auf die verschiedenen Interfaces an (physikalische und Tunnel-Interfaces, jeweils mit getrennten Instanzen von "tcpdump", damit man die Ausgabe besser lesen kann), dann sollte man leicht sehen können, wo ein Paket "versandet" - es also für ein eingehendes Paket auf dem jeweils richtigen "Ziel-Interface" kein passendes ausgehendes Paket gibt.

Weiterhin wäre die tatsächlich in der Firewall jeweils verwendete Konfiguration (gilt für Ubuntu und den RasPi) noch nützlich (am besten als "iptables-save"-Ausgabe, bitte nicht als Screenshot irgendwelcher X11-Tools) ... ich habe in #1 dann ein wenig den Überblick verloren, aber wenn ich das alles richtig lese, klappt auch auf dem Server 192.168.3.130 eher der "transit" zwischen den beiden TUN-Interfaces nicht (das iPhone erreicht keinen Dienst hinter dem zweiten TUN-Interface - bzw. hinter dem ersten, denn das wird sicherlich als "tun0" arbeiten bei der Verbindung zum LAN B). Auch da müssen natürlich entsprechende Regeln existieren, die den Traffic auf dem Server in beiden Richtungen als "FORWARD" erlauben und zwar von bzw. zu den jeweiligen 192.168-Adressen und nicht (nur) zu irgendwelchen Adressen aus den beiden 10er-Netzen.

Zuerst würde ich ohnehin das iPhone (und die zweite OpenVPN-Instanz) mal komplett aus den Betrachtungen ausklammern - erst wenn der Rest zwischen LAN A und LAN B dann komplett wie erwartet funktioniert, kann man das wieder hinzunehmen und dabei dann vielleicht wirklich gleich darüber nachdenken, das "ordentlich" mit einer einzigen Serverinstanz zu regeln. Da macht dann nämlich auch die "client-to-client"-Option wieder Sinn (vielleicht jedenfalls) - aber die (VPN-)Clients brauchen dabei dann eigentlich auch keine zwei (Transit-)Netze. Ich würde hier ohnehin das iPhone auf dem Ubuntu-Server per NAT behandeln, dann sieht es für die anderen Teilnehmer im Netz aus wie der Server und man braucht gar nicht erst mit den 10er-Adressen irgendwo hantieren - zumindest nicht außerhalb der VPN-Konfigurationen und -Gateways.
 
Danke für deine ausführliche Antwort.

Ja das iPhone habe ich eigentlich eh nur zu Testzwecken mit einbezogen und deshalb auch mit eigener Server-Instanz ausgestattet. Kann man jetzt auch mal vernachlässigen. Gleiches gilt für den Access-Point mit fester IP (192.168.20.200), der in meinem Versuchsaufbau auch nur enthalten ist weil ich sehen wollte wie sich das VPN in so einem Fall verhält.

Firewall testweise deaktiviert habe ich auf beiden Systemen (auf der Pi läuft ja auch Ubuntu) mit "ufw disable"

tcpdump: klingt vielversprechend. Ich habe mal mit den Beispielen aus dessen Anleitung rumgespielt und bekomme auch reichlich ausgaben, aber könntest du mir vielleicht Optionen sagen mit denen sich die Ausgabe aufs Wesentliche/Interessante beschränkt? auf der Pi ist das physikalische Interface wlan0 und das Tunnel-Interface tun0. Beim Ubuntu-Server ist es eno1 und tun0 (bzw. tun1 für die iPhone-Serverinstanz, interessiert uns hier aber vermutlich weniger)

Die Firewall-Konfiguration habe ich nach der offiziellen Ubuntu-Anleitung für OpenVPN gemacht, nämlich folgende Änderungen in /etc/ufw/before.rules (nur auf Ubuntu-Server)
Code:
#
# rules.before
#
# Rules that should be run before the ufw command line added rules. Custom
# rules should be added to one of these chains:
#   ufw-before-input
#   ufw-before-output
#   ufw-before-forward
#


[COLOR=#ff0000]# START OPENVPN RULES[/COLOR]
[COLOR=#ff0000]# NAT table rules[/COLOR]
[COLOR=#ff0000]*nat[/COLOR]
[COLOR=#ff0000]:POSTROUTING ACCEPT [0:0][/COLOR]
[COLOR=#ff0000]# Allow traffic from OpenVPN client to eno1[/COLOR]
[COLOR=#ff0000]-A POSTROUTING -s 10.8.0.0/24 -o eno1 -j MASQUERADE[/COLOR]
[COLOR=#ff0000]-A POSTROUTING -s 10.8.1.0/24 -o eno1 -j MASQUERADE[/COLOR]
[COLOR=#ff0000]-A POSTROUTING -s 192.168.20.0/24 -o eno1 -j MASQUERADE[/COLOR]
[COLOR=#ff0000]COMMIT[/COLOR]
[COLOR=#ff0000]# END OPENVPN RULES[/COLOR]


# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines




# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT


# quickly process packets for which we already have a connection
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT


# drop INVALID packets (logs these in loglevel medium and higher)
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP


# ok icmp codes for INPUT
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-input -p icmp --icmp-type source-quench -j ACCEPT
-A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT


# ok icmp code for FORWARD
-A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type source-quench -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT


# allow dhcp client to work
-A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT


#
# ufw-not-local
#
-A ufw-before-input -j ufw-not-local


# if LOCAL, RETURN
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN


# if MULTICAST, RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN


# if BROADCAST, RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN


# all other non-local packets are dropped
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP


# allow MULTICAST mDNS for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT


# allow MULTICAST UPnP for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 239.255.255.250 --dport 1900 -j ACCEPT


# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

Und dann wäre hier noch iptables-safe vom Ubuntu-Server:
Code:
# Generated by iptables-save v1.6.0 on Mon Apr 24 15:57:08 2017*mangle
:PREROUTING ACCEPT [15653262:9978723865]
:INPUT ACCEPT [15625046:9974954886]
:FORWARD ACCEPT [28180:3766097]
:OUTPUT ACCEPT [6730273:14153248420]
:POSTROUTING ACCEPT [6759999:14157293749]
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
# Completed on Mon Apr 24 15:57:08 2017
# Generated by iptables-save v1.6.0 on Mon Apr 24 15:57:08 2017
*nat
:PREROUTING ACCEPT [32714:4577864]
:INPUT ACCEPT [4043:681817]
:OUTPUT ACCEPT [7080:505080]
:POSTROUTING ACCEPT [6300:408013]
-A POSTROUTING -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/8 -o eno1 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/8 -o eno1 -j MASQUERADE
-A POSTROUTING -s 192.0.0.0/8 -o eno1 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -o eno1 -j MASQUERADE
-A POSTROUTING -s 10.8.1.0/24 -o eno1 -j MASQUERADE
-A POSTROUTING -s 192.168.20.0/24 -o eno1 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -o eno1 -j MASQUERADE
-A POSTROUTING -s 10.8.1.0/24 -o eno1 -j MASQUERADE
-A POSTROUTING -s 192.168.20.0/24 -o eno1 -j MASQUERADE
COMMIT
# Completed on Mon Apr 24 15:57:08 2017
# Generated by iptables-save v1.6.0 on Mon Apr 24 15:57:08 2017
*filter
:INPUT DROP [9907:318580]
:FORWARD ACCEPT [6:264]
:OUTPUT ACCEPT [48:3797]
:ufw-after-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-before-logging-input - [0:0]
:ufw-before-logging-output - [0:0]
:ufw-before-output - [0:0]
:ufw-logging-allow - [0:0]
:ufw-logging-deny - [0:0]
:ufw-not-local - [0:0]
:ufw-reject-forward - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-skip-to-policy-forward - [0:0]
:ufw-skip-to-policy-input - [0:0]
:ufw-skip-to-policy-output - [0:0]
:ufw-track-forward - [0:0]
:ufw-track-input - [0:0]
:ufw-track-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-user-input - [0:0]
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
:ufw-user-logging-forward - [0:0]
:ufw-user-logging-input - [0:0]
:ufw-user-logging-output - [0:0]
:ufw-user-output - [0:0]
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j ACCEPT
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-forward -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-forward -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 548 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 548 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 427 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 427 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 22 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 22 -j ACCEPT
-A ufw-user-input -p tcp -m multiport --dports 80,443 -j ACCEPT
-A ufw-user-input -p udp -m multiport --dports 137,138 -j ACCEPT
-A ufw-user-input -p tcp -m multiport --dports 139,445 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 631 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 631 -j ACCEPT
-A ufw-user-input -p tcp -m multiport --dports 427,548 -m comment --comment "\'dapp_netatalk\'" -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 5900 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 5900 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 5901 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 5901 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 5902 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 5902 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 5903 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 5903 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 5904 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 5904 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 20 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 20 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 21 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 21 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 1194 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 22 -m comment --comment "\'dapp_OpenSSH\'" -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 1195 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 1194 -j ACCEPT
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
COMMIT
# Completed on Mon Apr 24 15:57:08 2017

Und ebenfalls iptables vom Raspberry:
Code:
# Generated by iptables-save v1.6.0 on Mon Apr 24 15:45:05 2017*filter
:INPUT DROP [16:624]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [3:164]
:ufw-after-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-before-logging-input - [0:0]
:ufw-before-logging-output - [0:0]
:ufw-before-output - [0:0]
:ufw-logging-allow - [0:0]
:ufw-logging-deny - [0:0]
:ufw-not-local - [0:0]
:ufw-reject-forward - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-skip-to-policy-forward - [0:0]
:ufw-skip-to-policy-input - [0:0]
:ufw-skip-to-policy-output - [0:0]
:ufw-track-forward - [0:0]
:ufw-track-input - [0:0]
:ufw-track-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-user-input - [0:0]
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
:ufw-user-logging-forward - [0:0]
:ufw-user-logging-input - [0:0]
:ufw-user-logging-output - [0:0]
:ufw-user-output - [0:0]
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 7072 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 7072 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 22 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 22 -j ACCEPT
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
COMMIT
# Completed on Mon Apr 24 15:45:05 2017
 
Auf dem RasPi kann ich nicht eine Regel finden, die Transit-Verkehr von 192.168.20.0/24 nach 192.168.3.0/24 erlauben würde ... zumindest sehe ich da keine.

Das Masquerading (aka NAT) auf dem Ubuntu-Server (zumindest die drei sichtbaren POSTROUTING-Regeln für die nat-Table) führt ja dazu, daß der Traffic von jedem VPN-Client (auch von dahinter liegenden LAN-Clients) so aussieht, als käme er vom Server selbst ... kein Client in LAN A kriegt als irgendwie eine Adresse aus LAN B oder von der zweiten OpenVPN-Verbindung zu Gesicht, wenn die Pakete über eine VPN-Verbindung hereinkommen und auf "eno1" ausgegeben werden. Das ist für das Netz 192.168.20.0/24 in meinen Augen Quatsch ... der Hinweg nach LAN B wird ja auch nicht maskiert.

Die anderen beiden Masqueradings sind eigentlich auch nur dann notwendig, wenn wirklich direkt von einem der OpenVPN-Clients (also dem iPhone, was ja hier erst einmal herausgenommen werden soll und vom RasPi selbst) auf irgendwelche Dienste in LAN A zugegriffen werden soll. Das wäre aber auch nicht notwendig, zumindest der RasPi könnte für solche Verbindungen problemlos auch seine Adresse aus 192.168.20.0/24 benutzen und seinen Traffic (wie jeden anderen von den Clients in LAN B ebenfalls, auch wenn dafür - nach meiner Ansicht - im RasPi bisher jedwede Firewall-Regel fehlt) wie jeden anderen auch behandeln lassen (außer daß das eben "OUTPUT" ist und nicht "FORWARD" in diesem Falle, wenn der auf dem RasPi selbst erzeugt wurde).

Ansonsten hasse ich Ubuntu-"Geschmack" bei Firewalls ... man sucht sich einen Wolf (aber das nur nebenbei). Wo kommt denn jetzt am Ubuntu-Server das Netz 192.168.122.0/24 her? Auch die Regel "-A POSTROUTING -s 192.0.0.0/8 -o eno1 -j MASQUERADE" sollte auf irgendeine Fehlkonfiguration zurückzuführen sein ... oder warum soll dieser Server allen Verkehr von einer Adresse, die mit 192/8 beginnt (das ist noch lange keine "reservierte" Adresse für private Netze) und der auf "eno1" ausgegeben werden soll, ebenfalls auf seine eigene Adresse umschreiben? Der Sinn erschließt sich mir nicht ... vielleicht kann ich ja anhand der Erklärung dazu noch etwas lernen.

Ist dieser Ubuntu-Server nun noch für irgendjemand anderen tatsächlich ein Gateway (dann macht es - je nach Einsatzzweck - Sinn, wenn der Masquerading betreibt) oder ist der "nur" das VPN-Gateway? Dann würde ich hier 192.168.20.0/24 1:1 durchreichen (die Route für den Rückweg ist in der FRITZ!Box im LAN A ja vorhanden) und damit bliebe (wenn ich jetzt nicht irgendetwas anderes komplett übersehen/überlesen habe) erst einmal gar keine von den zusätzlichen POSTROUTING-Regeln übrig.

Den "Hinweg" aus LAN A in Richtung LAN B und zum RasPi (weiter geht das ja wohl im Moment ohnehin nicht) unter der Adresse 192.168.20.24 würden die "conntrack --ctstate NEW"-Regeln in ufw-track-forward erlauben und den Rückweg von dort die "conntrack --ctstate RELATED,ESTABLISHED"-Regel in "ufw-before-forward". Damit sollte zumindest der RasPi unter der Adresse aus LAN B erreichbar sein. Wobei sich diese Erreichbarkeit auch auf ICMP und die TCP-Ports 22 und 7072 beschränkt (wofür die UDP-Ports da gut sein sollen, weiß der Geier - wobei ich natürlich nicht weiß, ob 7072 nicht tatsächlich mit UDP anstelle von TCP (oder wirklich beiden, was sehr ungewöhnlich ist) arbeitet) - denn da greifen auf dem RasPi dann die "ACCEPT"-Regeln aus "ufw-user-input", die aber kein Pendant für Transit-Verkehr haben (genauso fehlt tatsächlich die Gegenrichtung).

Da weiß man praktisch nicht so genau, wo man mit dem "Aufräumen" beginnen soll ... ich würde erst einmal den Ubuntu-Server "ausmisten" (oder erklären, wozu das alles gut sein soll) und dann sollte (bei unveränderter Firewall auf dem RasPi) eigentlich der SSH-Zugriff auf den RasPi immer noch funktionieren - und zwar von jedem Client im LAN A aus.

Daß diese ganze "Pingerei" von A nach B und umgekehrt so halbwegs funktioniert, liegt m.E. eben daran, daß die Ubuntu-Firewall für diese ICMP-Pakete jeweils bereits passende Regeln einrichtet ... in allen Chains finden sich entsprechende "ACCEPT"-Regeln für ICMP mit dem dabei verwendeten Typ "echo request" (ICMP type 8) und damit gehen diese Pakete durch die Firewall (das bestätigen ja auch die Ping-Tests aus #1) und andere werden trotzdem blockiert. Ich habe keine Ahnung (und auch keine Lust, mir das anzusehen), ob nun "ufw disable" parallel auch noch das IPv4-Forwarding deaktiviert oder nicht und ob deshalb der Test mit deaktivierter Firewall zum Scheitern verurteilt war.

Mit den gezeigten Firewall-Konfigurationen (besonders der auf dem RasPi) dürfte das jedenfalls (wenn ich mich nicht vertan habe, das kann auch vorkommen) nicht funktionieren, irgendetwas anderes als "ping" von LAN A nach LAN B zu betreiben und das gilt m.E. auch für Clients aus LAN B, wenn es um Zugriffe nach LAN A geht. Lediglich der RasPi kann (aufgrund der "Sonderstellung", denn von ihm ausgehender Verkehr ist eben "OUTPUT" - bzw. an ihn gerichteter ist "INPUT" - und der Rest ist "FORWARD" (transit)) auf Dienste in LAN A zugreifen, weil (s.o.) bei ihm die Regeln in der OUTPUT-Table vorhanden sind.
 
Zuletzt bearbeitet:
Die ganzen MASQUERADING-Regeln waren aus einem How-to für, aber nicht von, Ubuntu >> hab sie mal lahm gelegt. Ansonsten ist da drinnen alles im Originalzustand.

So zu ufw: du wirst jetzt lachen, aber das steht für Uncomplicated FireWall ;) Ich hab davon leider kaum Ahnung und hab die Beschreibungen von Ubuntu dazu grade mal überflogen, kurz gesagt gibt es an mehreren Stellen Einträge die diese before.rules wieder überschreiben >> seeehr undurchsichtig für einen Außenstehenden.

Ich habe jetzt nochmal auf beiden Ubuntu-Geräten die Firewall komplett deaktiviert und alles neu gestartet: dann geht alles. (Warum es beim ersten Versuch vor 2 Tagen nicht ging weiss ich nicht, vielleicht war ich zu eilig in dem Moment). Damit sind also 2 Dinge klar: 1. IP-Forwarding auf Ubuntu ist auch aktiv wenn ufw aus ist und 2. Mein Problem ist ufw und nicht mein Routing in meiner VPN-Konfiguration.

Natürlich sind abgeschaltete Firewalls keine Lösung. Ich bräuchte jetzt also als erstes mal das Verständnis über die genauen Regeln die ich definieren muss um mein Szenario zu erlauben ohne dabei vollständig die Hosen herunter zu lassen. Ganz zu Beginn hatte ich schon nach genauen Anweisungen dazu in den OpenVPN HowTos und in deren Forum gesucht, aber alle Angaben/Anleitungen/Hinweise beziehen sich immer auf den Standard-Fall "ich brauche ein VPN für mein Handy im öffentlichen WLAN" und nicht auf diese LAN-LAN Variante. Nu ja, wenn ich lang genug lese finde ichs auch selber raus. Wenn du's mir erleichtern willst könntest du mir ja mal - ungeachtet der bisherigen iptables von Ubuntu - erklären welche Regeln ich hier bräuchte.
 
Ich denke mal, die Erkenntnis, daß es nicht die OpenVPN-Konfiguration an sich ist, ist hier erst einmal der erste (wichtige) Schritt.

Bei der Konfiguration der Firewall (ich kenne "ufw" gar nicht (abseits der entsprechenden Wiki-Seiten für Ubuntu, die nun mehr auf "wie mache ich was" zielen als auf den Aufbau), kann mir nur in etwa vorstellen, wie das aussehen mag) wirst Du Dir erst einmal grundlegende Kenntnisse anlesen müssen ... das Problem sind gar nicht in erster Linie irgendwelche "allow"-Regeln (aka "-j ACCEPT"-Einträge), sondern mehr das Verständnis, welche Datenpakete mit welchen Absender- und welchen Zieladressen da von welchem Interface zum nächsten gelangen müssen, damit das VPN funktioniert. Für solche Situationen gibt es auch nicht wirklich "Rezepte", die man nur nachkochen muß und dann funktioniert das schon. Es gibt viele (auch anfängertaugliche) Beschreibungen im Netz, wie so ein Regelwerk für "iptables" arbeitet ... ich fühle mich etwas unwohl bei dem Gedanken, bei der Konfiguration einer Firewall mit so vielen Unbekannten zu helfen. Ich weiß ja immer noch nicht, wo da nun die Konfiguration für das IP-Segment 192.168.122.0/24 herkommen soll und was die oben angesprochene 192/8-Regel bewirken soll.

Rein zur Theorie, was es für das Routing auf dem RasPi noch bräuchte, habe ich das ja bereits geschrieben: Es muß mind. eine Regel geben, die dort eingehenden Verkehr von 192.168.3.0/24 auf das "wlan"-Interface zuläßt (in der FORWARD-Table) und dabei dann einen passenden "conntrack"-Eintrag erzeugt, damit zumindest die Antwort-Pakete aus LAN B wieder mit einer (ebenfalls noch zu erstellenden) FORWARD-Regel (ctstate RELATED,ESTABLISHED) auf das "tun"-Interface ausgegeben werden können (notfalls läßt man die Beschränkung auf das Interface weg). Damit wäre erst einmal der Weg von LAN A (und zwar von einem Client dort) ins LAN B (auch zu einem Client) offen. Für den umgekehrten Weg (LAN B-Client nach LAN A - wobei es hier darum geht, wer die Verbindung initiiert) braucht es dann noch die gespiegelte Regel (ausgehend von LAN B nach LAN A mit "--ctstate NEW" und für die Gegenrichtung "RELATED,ESTABLISHED"). Andererseits kann man auch einfach ohne jedes "connection tracking" alles von/zu den passenden Adressen per "ACCEPT" einfach durchlassen, wenn man keine weiteren Beschränkungen auf irgendwelche Dienste will ... die Netze wären dann (ab Layer 3) "richtig" gekoppelt und nicht nur für bestimmte Dienste verwendbar.

Es gibt einfach zu viele Möglichkeiten, die auch noch davon abhängen, was man konkret erreichen will (und wie irgendwelche Konfigurationen jetzt aussehen nach weiteren Änderungen, müßte man auch erst wieder erfragen oder erraten) ... weiter oben habe ich ja schon mal betont, daß ich hier für das iPhone (weil das eben ein einzelner Client ist und kein ganzes Netz) eher auf Masquerading zurückgreifen würde - wobei das dann auch nur die Konfiguration auf dem Ubuntu-Server betrifft, weil das iPhone für den RasPi (und den Rest von LAN B) wie der Ubuntu-Server aussehen würde.
 
In jedem Fall bis hierher schonmal danke für deine Ausführungen, die das Problem ja letztlich identifiziert haben.

Und ja du hast recht, ich komme nicht drum rum das Regelwerk der iptables zu verstehen.

Andererseits kann man auch einfach ohne jedes "connection tracking" alles von/zu den passenden Adressen per "ACCEPT" einfach durchlassen, wenn man keine weiteren Beschränkungen auf irgendwelche Dienste will ... die Netze wären dann (ab Layer 3) "richtig" gekoppelt und nicht nur für bestimmte Dienste verwendbar.
Das wäre ja mein ursprünglicher Wunsch gewesen, meine Sorge gilt ja nicht meinen lokalen Geräten sondern evtl. unbefugten Außenstehenden die es an irgendeiner Stelle auf die lokale Seite meiner Netze geschafft haben. Aber dieses Abwägen von Bedürfnissen und Risiken ist ja die übliche Gratwanderung bei IT-Sicherheit.
 
Eine Frage hab ich noch: Du hast weiter oben am Rande erwähnt es wäre sinnvoller das iPhone mit der gleichen Server-Conf einzubinden. Beim iPhone will ich aber dass dann sämtlicher Traffic durch den Tunnel gezwungen wird und habe dazu in der Server-Conf 'push "redirect-gateway def1 bypass-dhcp"' stehen. Kann ich das auch in die Client-speziefische Datei in /ccd setzen? Weil beim angebundenen fremden Netz will ich Internet-Traffic nicht durch den Tunnel schicken. Gleiche Frage für das push-route: Das iPhone soll ja auch die Clients im Gast-LAN erreichen, braucht also eine Route zu 192.168.20.0, im Gast-LAN brauch ich aber natürlich keine Route in deren eigenes Netz. Kann das auch in die Datei in /ccd?
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.