[Gelöst] OpenVPN in freetz stört Portforwarding in Firmware 6.20

han-solo · 20 Nov 2014

Hallo,

Ich musste leider feststellen, dass OpenVPN in freetz seit der Firmware 6.20 (freetz-devel-12746) das Portforwarding stört.
Sobald OpenVPN läuft, sind keine Portforwardings mehr ins Heimnetz möglich und bestehen Porforwardings werden von der Fritzbox automatisch deaktiviert.
Setzt man die Häkchen wieder und klickt auf "Übernehmen", erscheint:

Code:

Es ist ein Fehler aufgetreten.
Fehlerbeschreibung: Die Portfreigabe kann nicht erstellt oder aktiviert werden, da das Ziel nicht im Heimnetz liegt.
Bitte geben Sie Ihre Daten noch einmal ein. Sollte der Fehler erneut auftreten, wenden Sie sich bitte an den AVM-Support.

Konkret ist folgender Bereich betroffen (Beispieleinstellung):

Code:

VPN IP-Adressen und Routing im VPN
Hier werden die IP-Adressen und das Routing vom VPN konfiguriert. 

Lokale IP-Adresse: 192.168.179.1
Netzmaske: 255.255.255.0
DHCP-Range für Clients: 192.168.179.230 192.168.179.250

Sobald das o.g. OpenVPN Subnet im Bereich von IP-Adressen aus dem Heimnetz liegt, kann für diese IP-Adressen kein Portforwarding mehr aktiviert werden.
Das war bislang nicht so. Also enthält hier freetz entweder einen Bug oder AVM hat hier etwas neues eingebaut.
Ich denke letzteres ist der Fall.

Lässst sich das irgendwie beheben oder umgehen?
Ich brauche mein OpenVPN und auch das Portforwarding.

Gruß
HS

Edit:
Die neue Labor-Firmware hat das selbe Problem

Anbei meine Interfaces Ausgaben (Mein Heimnetz steht auf 192.168.179.x und mein OpenVPN läuft als Bridge mit TAP):
[HWaddr entfernt]

ifconfig bei aktivem OpenVPN

Code:

adsl      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:2000  Metric:1
          RX packets:39348 errors:0 dropped:0 overruns:0 frame:0
          TX packets:400831 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:7120251 (6.7 MiB)  TX bytes:49577479 (47.2 MiB)

ath0      Link encap:Ethernet  HWaddr 
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ath1      Link encap:Ethernet  HWaddr 
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

dsl       Link encap:Point-to-Point Protocol
          inet addr:192.168.179.1  P-t-P:192.168.179.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:35934 errors:0 dropped:0 overruns:0 frame:0
          TX packets:61106 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:5688682 (5.4 MiB)  TX bytes:10681110 (10.1 MiB)

eth0      Link encap:Ethernet  HWaddr 
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:256798 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13152 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:16950156 (16.1 MiB)  TX bytes:3045886 (2.9 MiB)

eth1      Link encap:Ethernet  HWaddr 
          UP BROADCAST ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth2      Link encap:Ethernet  HWaddr 
          UP BROADCAST ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth3      Link encap:Ethernet  HWaddr 
          UP BROADCAST ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

guest     Link encap:Ethernet  HWaddr 
          inet addr:192.168.181.1  Bcast:192.168.181.255  Mask:255.255.255.0
          inet6 addr: fe80::3681:c4ff:fe21:f2b2/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:368 (368.0 B)

lan       Link encap:Ethernet  HWaddr 
          inet addr:192.168.179.1  Bcast:192.168.179.255  Mask:255.255.255.0
          inet6 addr: fe80::3681:c4ff:fe21:f2b2/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:37703 errors:0 dropped:0 overruns:0 frame:0
          TX packets:63367 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4736771 (4.5 MiB)  TX bytes:29409660 (28.0 MiB)

lan:0     Link encap:Ethernet  HWaddr 
          inet addr:169.254.1.1  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1644 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1644 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:440029 (429.7 KiB)  TX bytes:440029 (429.7 KiB)

tap0      Link encap:Ethernet  HWaddr 
          inet addr:192.168.179.1  Bcast:192.168.179.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:79 errors:0 dropped:0 overruns:0 frame:0
          TX packets:195 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:6466 (6.3 KiB)  TX bytes:31832 (31.0 KiB)

wasp      Link encap:Ethernet  HWaddr 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:140363 errors:0 dropped:0 overruns:0 frame:0
          TX packets:61649 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:17895915 (17.0 MiB)  TX bytes:31496179 (30.0 MiB)

wlan      Link encap:Ethernet  HWaddr 
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:28540 errors:0 dropped:0 overruns:0 frame:0
          TX packets:51791 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4267918 (4.0 MiB)  TX bytes:27038254 (25.7 MiB)

ifconfig ohne aktives OpenVPN

Code:

adsl      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:2000  Metric:1
          RX packets:38598 errors:0 dropped:0 overruns:0 frame:0
          TX packets:361914 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:6949659 (6.6 MiB)  TX bytes:45971852 (43.8 MiB)

ath0      Link encap:Ethernet  HWaddr 
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ath1      Link encap:Ethernet  HWaddr 
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

dsl       Link encap:Point-to-Point Protocol
          inet addr:192.168.179.1  P-t-P:192.168.179.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:35280 errors:0 dropped:0 overruns:0 frame:0
          TX packets:59829 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:5546772 (5.2 MiB)  TX bytes:10409692 (9.9 MiB)

eth0      Link encap:Ethernet  HWaddr 
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:227753 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12731 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:15372395 (14.6 MiB)  TX bytes:2912325 (2.7 MiB)

eth1      Link encap:Ethernet  HWaddr 
          UP BROADCAST ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth2      Link encap:Ethernet  HWaddr 
          UP BROADCAST ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth3      Link encap:Ethernet  HWaddr 
          UP BROADCAST ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

guest     Link encap:Ethernet  HWaddr 
          inet addr:192.168.181.1  Bcast:192.168.181.255  Mask:255.255.255.0
          inet6 addr: fe80::3681:c4ff:fe21:f2b2/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:368 (368.0 B)

lan       Link encap:Ethernet  HWaddr 
          inet addr:192.168.179.1  Bcast:192.168.179.255  Mask:255.255.255.0
          inet6 addr: fe80::3681:c4ff:fe21:f2b2/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:37065 errors:0 dropped:0 overruns:0 frame:0
          TX packets:61955 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4644666 (4.4 MiB)  TX bytes:28612694 (27.2 MiB)

lan:0     Link encap:Ethernet  HWaddr 
          inet addr:169.254.1.1  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1479 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1479 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:415948 (406.1 KiB)  TX bytes:415948 (406.1 KiB)

wasp      Link encap:Ethernet  HWaddr 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:130845 errors:0 dropped:0 overruns:0 frame:0
          TX packets:60454 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:17058177 (16.2 MiB)  TX bytes:30778172 (29.3 MiB)

wlan      Link encap:Ethernet  HWaddr 
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:28041 errors:0 dropped:0 overruns:0 frame:0
          TX packets:50637 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4179015 (3.9 MiB)  TX bytes:26326846 (25.1 MiB)

MaxMuster · 21 Nov 2014

Ich vermute auch eher, dass AVM eine neue Abfrage installiert hat, ob die Ziel-IP auf einem anderen Interface genannt wird. Und das ist sie natürlich auf dem TAP-Interface...

Als "Work-Around" könnte ich mir folgendes vorstellen:
Nimm als IP des TAP-Interfaces
192.168.179.1 255.255.255.255 (wenn eine Host-IP zulässig ist, sonst 255.255.255.252).

Damit sollte das Forwarding-Ziel nicht auf diese Interface zeigen.
( oder nimm eine ganz andere IP, durch das Bridging mit dem LAN sollte die eigentliche Interface-IP egal sein...)

Geht es so?

PeterPawn · 21 Nov 2014

han-solo schrieb:

Code:

lan       Link encap:Ethernet  HWaddr 
          inet addr:192.168.179.1  Bcast:192.168.179.255  Mask:255.255.255.0
[...]
tap0      Link encap:Ethernet  HWaddr 
          inet addr:192.168.179.1  Bcast:192.168.179.255  Mask:255.255.255.0

Genau da liegt für mich das Problem, die Anzeige mit "brctl show" funktioniert ja bei Dir leider nicht, aber da dürfte tap0 in der lan-Bridge sein.

Ich würde behaupten, das neue Vorgehen der AVM-Firmware (seit 06.20 + einige Labor-Versionen davor) bei der Einrichtung von Routen und Portforwardings ist imho inzwischen verbürgt bzw. leicht zu testen/zu belegen. Irgendwie testet die Firmware, ob Routen (über das GUI respektive den ctlmgr, per 'ip r' geht es auch anders) und Portforwardings an das lokale Netz gehen und nicht irgendwo anders landen würden. Dabei wird offenbar auch "richtig" getestet, denn das "Austricksen" der Prüfung (z.B. durch Vertauschen der Reihenfolge bei der Einrichtung) funktioniert anscheinend auch nicht ohne weiteres.

Jetzt wird mit dieser OpenVPN-Konfiguration ja das tap-Interface auch noch zur Bridge hinzugefügt, m.E. läßt sich der AVM-dsld bei solchen Ereignissen triggern und überprüft die Routen/Portforwardings erneut. Dabei stört ihn vermutlich das für ihn unbekannte Interface (die bekannten stehen in der ar7.cfg) und er stolpert darüber. Daß ich einen unmittelbaren Zusammenhang zwischen der Hotspot-/Homespot-Funktion der Firmware und der genaueren Prüfung, was da wie zusammengebunden werden darf, vermute, habe ich ja schon im anderen Thread geschrieben ... auch der korrekten Isolation des Gastnetzes ist das am Ende zuträglich.

Ich würde als erstes mal testen, ob das Problem verschwindet, wenn Du für das VPN ein eigenes Subnetz verwendest (also nicht mehr 192.168.179.0/24) und das tap-Interface nicht mehr ins LAN bindest. Dabei wird u.U. erst mal keine VPN-Verbindung möglich sein, aber so könnte man es exakt auf das Bridgen als Ursache zurückführen und von dem diffusen "es liegt am OpenVPN" weg kommen.

Ich sehe bei der VPN-Konfiguration aber ohnehin nicht durch. Wenn einerseits die Clients ihre eigene Adresse im LAN des VPN-Servers erhalten und andererseits sich dahinter jeweils ein eigenes Subnetz verbirgt, hast Du sicherlich gute Gründe für die Verwendung des Bridge-Modes anstelle von Routing. Aber aus dem Screenshot und ohne Kenntnis, was sich da für Clients hinter verbergen bzw. wer (Clients) da wie (Broadcasts ?) auf wen (client-to-client gesetzt ?) zugreifen soll, ist das nur Stochern im Nebel ... habe ich auch keinen Bock zu.

Ich würde am Anfang nur tippen, daß das Routing/Forwarding-Problem mit der Bridge (bzw. dem brctl add in rc.openvpn) zusammenhängt und als erstes versuchen, diese Vermutung zu bestätigen oder zu widerlegen.

Wenn es der Bridge-Modus ist (und da meine ich nicht das tap-Device des OpenVPN, sondern das zusätzliche Hinzufügen des tap-Interfaces zur lan-Bridge), muß man schauen, was da im VPN an Funktionalität erforderlich ist und wie man das ohne Bridge (z.B. mit einem Transitnetz, wenn das überhaupt erforderlich ist) ebenfalls hinbringen könnte.

Wichtig ist nur, daß man parallel zum Entfernen der Checkmark in der "mit LAN brücken"-Box zum Test auch die lokale Adresse für das tap-Interface ändert, sonst endet man u.U. bei zwei Interfaces mit 192.168.179.1 als Adresse oder einem Fehler.

Wenn meine Vermutung stimmt, muß man entweder einen Weg finden, das tap-Interface der AVM-Firmware doch noch schmackhaft zu machen oder - wenn man parallel Portforwarding und/oder zusätzliche lokale Routen benötigt - ab 06.20 auf das Hinzufügen des tap-Interfaces zur lan-Bridge verzichten und seine VPN-Konfigurationen entsprechend anpassen.

Ein Patch, der der AVM-Firmware dieses neue Vorgehen abgewöhnt, scheitert an Closed Source (außerdem ist das Verhalten ziemlich logisch und man sollte AVM zu der Verbesserung der Sicherheit eher beglückwünschen). Ob es am Ende hilft, in der ar7.cfg das tap-Interface schon von Anfang an in der Bridge zu verankern, könnte man testen ... aber dann muß man imho entsprechende Vorkehrungen im Image treffen, daß es bereits beim Start des dsld existiert und nicht erst beim Start von OpenVPN erstellt wird. In der Firmware ist normalerweise nur ein tun-Device enthalten (/dev/net/tun bzw. /dev/tun).

han-solo · 21 Nov 2014

Hallo,

danke für eure Bemühungen. Ich möchte meine Umgebung nochmalm verdeutlichen.
Auf meiner Fritzbox läuft ein Application Server auf sagen wir mal Port 11111 der an das eth0 interface gebunden ist. Auf diesen Server müssen alle Clients über einen OpenVPN Tunnel mit Zertifiikaten zugreifen.
Einige Linux Clients sind im LAN der angebundenen Subnets angesiedelt werden durch eine gefreetzte Fritzbox über OpenVPN geroutet.
Andere Linux Clients bauen direkt eine OpenVPN Verbindung auf. Z.B. wenn keine Fritzbox am Standort existiert, sondern irgend ein anderer Router.

Somit ist die Vorgabe, dass das eth0 Interface im OpenVPN Netz liegen muss.
Es sei denn ich kann ein zweites Interface hochfaheren. Z.B. so:

Code:

ifconfig eth0:0 172.16.10.1 netmask 255.255.255.0 up

Wenn der Application Server auf diese IP ebenfalls hört, könnte es klappen. Oder habe ich dann das selbe Problem, da eth0:0 ja auch zum lan gehört?

Ich würde als erstes mal testen, ob das Problem verschwindet, wenn Du für das VPN ein eigenes Subnetz verwendest (also nicht mehr 192.168.179.0/24)

Jep, das habe ich gestern schon getestet und es funktioniert in diesem Fall. Aber leider bringt mir das momentan nicht viel weil die Clients auf 192.168.179.1 zugreifen müssen.
Das ist die Konfiguration eines OpenVPN Clients.

Code:

# OpenVPN 2.1 Config
proto tcp-client
dev tap0
dev-node /dev/net/tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/box.crt
key /etc/openvpn/box.key
tls-client
ns-cert-type server
tls-auth /etc/openvpn/static.key 1
remote xxxxxx.dyndns.org 1195
nobind
ifconfig 192.168.179.242 255.255.255.0
tun-mtu 1500
mssfix
verb 3
cipher AES-128-CBC
comp-lzo
float
keepalive 10 120
resolv-retry infinite
chroot /tmp/openvpn
persist-tun
persist-key

Gruß
Hs

PeterPawn · 21 Nov 2014

han-solo schrieb:
Ich möchte meine Umgebung nochmalm verdeutlichen.

Das ist in Worten etwas schwer zu verstehen ... für mich jedenfalls.

Auf meiner Fritzbox läuft ein Application Server auf sagen wir mal Port 11111 der an das eth0 interface gebunden ist.

Da fängt es (bei einer 7390, was ich der Signatur entnehme) auch schon an ... ist dieser Application Server wirklich an eth0 gebunden oder an die lan-Bridge ?

Der Unterschied liegt durchaus in der Adressierung (und nach meinen Tests auch in der Behandlung durch AVM, die sich imho wirklich an der lan-Bridge orientiert).

Code:

root@FB7390:/# brctl show <- mit WLAN
bridge name     bridge id               STP enabled     interfaces
lan             8000.bc0543a0615e       no              eth0
                                                        ath0
guest           8000.bc0543a0615e       no              ethgbr3
root@FB7390:/# brctl show <- ohne WLAN
bridge name     bridge id               STP enabled     interfaces
lan             8000.bc0543a0615e       no              eth0
guest           8000.bc0543a0615e       no              ethgbr3
root@FB7390:/# brctl show <- ohne Gastnetz (aber man sieht, die Bridge bleibt bestehen, nur ohne Member)
bridge name     bridge id               STP enabled     interfaces
lan             8000.bc0543a0615e       no              eth0
guest           8000.bc0543a0615e       no

Der Witz an einem Interface, das man einer Bridge hinzufügt, ist ... es verliert umgehend seine eigenen Einstellungen zu IP-Adressen und "erbt" die der Bridge. Löst man es wieder aus der Bridge, bleibt es unkonfiguriert.
Da ein Programm (auch der Application Server) eine Art "unbestimmtes Lauschen" (bind mit INADDR_ANY) auf eingehende Verbindungen machen kann, ist es schon ein Unterschied, ob er an die lan-Bridge gebunden ist (dann bleibt er dort, auch wenn eth0 aus der Bridge gelöst wird) oder wirklich an eth0 (das sind bei der 7390 alle LAN-Ports (und nur diese), solange sie nicht gesondert konfiguriert werden, wie ethgbr3 oben). Löst man eth0 aus der Bridge, wäre damit auch der Application Server "tot", da er auch bei einem "socket-bind" mit INADDR_ANY keine Connection mehr erhält, weil das eth0-Interface keine Adresse mehr hat.

Einige Linux Clients sind im LAN der angebundenen Subnets angesiedelt und werden durch eine gefreetzte Fritzbox über OpenVPN geroutet.

Wenn das oben mit meiner Ergänzung in fett dann stimmt, begreife ich das halbwegs. Bleibt immer noch die Frage, was die Clients da konkret über das VPN senden sollen (Layer2 oder Layer3, am Ende Broadcast ja/nein oder meinetwegen auch NetBIOS ja/nein) ? Wenn ich das richtig verstehe, wären das dann gekoppelte LANs mit jeweils eigenem Subnet, wo ein Routing zwischen den LANs erfolgen soll.

Andere Linux Clients bauen direkt eine OpenVPN Verbindung auf. Z.B. wenn keine Fritzbox am Standort existiert, sondern irgend ein anderer Router.

Und diese OpenVPN-Verbindung nutzen dann auch nur diese Clients und die sind nicht etwa nur ein hinter den Router verlagertes Gateway für weitere Clients ? Dann hätten die ja kein eigenes lokales Subnet und in Deiner Konfiguration müßte unter "Netz bei Client" nichts stehen ... vielleicht ist ja der Screenshot oben nur zu kurz, so etwas sehe ich da jedenfalls nicht.

Somit ist die Vorgabe, dass das eth0 Interface im OpenVPN Netz liegen muss.

Das sehe ich nicht. Warum sollte das mit einer Routing-Konfiguration nicht auch gehen ?

Wenn der Application Server auf diese IP ebenfalls hört, könnte es klappen. Oder habe ich dann das selbe Problem, da eth0:0 ja auch zum lan gehört?

Das weiß ich schlicht nicht ... es gibt eben einen Unterschied zwischen eth0 und lan, s.o. -> Unterschied verstehen, Server untersuchen (wie arbeitet der), probieren

Solange man nicht weiß, wo der Application Server nun wirklich gebunden ist und ob der vorher die aktuelle Adresse auf diesem Interface ermittelt und dann nur diese verwendet oder doch 0.0.0.0 (INADDR_ANY), ist das alles Raterei.

Jep, das habe ich gestern schon getestet und es funktioniert in diesem Fall. Aber leider bringt mir das momentan nicht viel weil die Clients auf 192.168.179.1 zugreifen müssen.

Was hast Du denn nun genau getestet ? Der Vorschlag bestand ja aus zwei Schritten (nicht von tap auf lan bridgen und anderes Subnet) ... welchen Teil (oder sogar beide ?) hast Du da getestet ? Und wie waren die Ergebnisse für die (mind. 3) verschiedenen Szenarien (ohne Bridge und mit 192.168.179.1 geht sicherlich schief, daher ein Fall weniger) ? Theoretisch müßte sogar bei aktivierter Bridge (s.o. zur Adresse von Member-Interfaces einer Bridge) die Einstellung der lokalen IP-Adresse im OpenVPN komplett ignoriert werden ...

Und auch wenn ich es jetzt nicht selbst testen werde, ich sehe (aus Netzwerksicht) keinen Grund, warum das tap-Interface unbedingt die 192.168.179.1 haben muß, damit die Clients auf den Application Server zugreifen können. Ich würde zunächst mal behaupten, daß ein solcher Zugriff mit passender Routing-Table eigentlich auch funktionieren sollte, wenn da ein komplett anderes Transfernetz zum Einsatz kommt.
Wenn es dasselbe Netz ist beim tap-Adapter, muß der OpenVPN-Prozess für entfernte Adressen als ARP-Proxy fungieren, damit die Pakete an das entfernte Netz bei ihm aufschlagen und übertragen werden können. Wenn das ein anderes Netz ist, wird eine Route über das OpenVPN-Interface auf das entfernte Netzwerk eingerichtet, die dann ihrerseits dafür sorgt, daß die Daten für die andere Seite beim OpenVPN ankommen. Wo sehe ich da jetzt ein Problem nicht ?

Mit der Client-Konfiguration kann ich persönlich gar nichts anfangen, mit der Server-Konfiguration im GUI als Screenshot aber auch nicht. Das einzige, was mich da event. interessieren würde, ist die "fertige" Konfiguration zum Start des Servers, inkl. des ccd-Verzeichnisses mit jeweils einer Konfiguration (einmal LAN-LAN, einmal Host-LAN).

Ich kenne mich zwar mit der Konfiguration von OpenVPN leidlich aus, aber überhaupt nicht mit dem GUI im Freetz dazu und ich habe keine Lust, den Zusammenhang zwischen GUI-Elementen und config-Statements immer erst mühsam in den Freetz-Quellen zu suchen, sorry. Das ist gerade bei dem OpenVPN-GUI-V1 nicht leicht wegen der heftigen Benutzung von Javascript, um da viele Details vor dem Benutzer zu verbergen bzw. die angezeigen Optionen dynamisch anzupassen an die vorher getroffenen Einstellungen.

han-solo · 21 Nov 2014

Hallo PeterPawn,

ich glaube den Unterschied von lan und eth0 habe ich immer noch nicht verstanden. Und auch die bridge Abhängigkeiten nicht so ganz.
Vermutlich hatte ich unrecht mit eth0 und der ApplicationServer hört auf lan. Dieses interface hat ja auch die 192.168.179.1 und eth0 zeigt garkeine Information über die IP in ifconfig.

Auf jedenfall pingen die clients die 192.168.179.2 und starten den OpenVPN Tunnel bei nicht Erreichbarkeit.
Danach schicken sie Pakete an 192.168.179.1 und erhalten Rückmeldungen.

Edit: Das habe ich mir so ausgedacht, weil einige Fritzboxen per default das gastnetzt auf 192.168.179.1 haben.

Ich glaube Layer2 würde ausreichen aber Layer3 ist nice2have, denn darüber kann ich per routing auch auf alle anderen Geräte im Client-Netz zugreifen (Ausgeschlossen der Geräte, die selbst den Tunnel aufbauen. Da endet ja der Tunnel).

Das mit dem eth0:0 werde ich ausprobieren. Bin selbst gespannt ob das geht.

Was hast Du denn nun genau getestet ? Der Vorschlag bestand ja aus zwei Schritten

Ich habe folgende Einstellungen in der GUI getestet:

Code:

Lokale IP-Adresse: 192.168.179.224
Netzmaske: 255.255.255.224
DHCP-Range für Clients: 192.168.179.230 192.168.179.250

So konnte ich wieder Portforwardings erstellen. Aber die Clients konnten sich nicht mehr connecten.
Jede andere Konstellation bei der die IP im Heimnetz lag (mit oder ohne bridge) hat nicht funktioniert. Die Freigaben wurden nicht angenommen.
Und wenn ich in der GUI die bridge deaktiviere, verbinden sich die Clients auch nicht mehr.
Ich bin kein OpenVPN Spezialist aber weiß, dass bei TAP eigentlich kein Routing erforderlich ist, aber bridge ist wohl wichtig dafür.
Die eingetragenen Netze in der GUI sind deshalb wohl nicht wirklich erforderlich aber ich glaube ich hatte in der Vergangenheit mit einigen Clients Probleme wenn es nicht eingetragen war.
Kann ich aber jetzt nicht drauf schwören.

PeterPawn · 21 Nov 2014

han-solo schrieb:
Ich glaube Layer2 würde ausreichen aber Layer3 ist nice2have, denn darüber kann ich per routing auch auf alle anderen Geräte im Client-Netz zugreifen (Ausgeschlossen der Geräte, die selbst den Tunnel aufbauen. Da endet ja der Tunnel).

Da hast Du etwas falsch verstanden. Bei Layer2 werden sogar mehr Daten zwischen den Netzen übertragen, als bei Layer3. Layer3 bezieht sich auf gerouteten Verkehr wie IP-Pakete (TCP/UDP/ICMP) - allgemeiner auf Pakete, Layer2 auf Ethernet-"Pakete" (also auch ARP und andere Broadcasts, die nicht geroutet werden) - eigentlich meist eher als "Frames" bezeichnet - etwa vereinfacht, aber das Prinzip stimmt.
Am Ende ist es also nur der Unterschied, auf welcher Ebene die Entscheidung "für remote bestimmt oder nicht" getroffen wird. Da bestimmte Ethernet-Frames gar nicht auf Layer3 ankommen, kann für diese auf Layer3 auch keine Entscheidung getroffen werden, daß sie zur Gegenseite geschickt werden müssen. Damit wird dann dieser "nur Layer2"-Verkehr nicht auf der Gegenseite ankommen. Das ist zwar alles graue Theorie, aber für eine sinnvolle OpenVPN-Konfiguration - gerade in einem Multi-Client-Szenario - sollte man den Unterschied wenigstens grob verstehen.

Wenn Du willst, daß das Gateway das erste Device im Netz ist, müßte die IP-Adresse natürlich 192.168.179.225/27 sein.

So konnte ich wieder Portforwardings erstellen. Aber die Clients konnten sich nicht mehr connecten.

Das verstehe ich nicht. Die Verbindung der Clients (das verstehe ich unter "connected") sollte erst einmal unabhängig davon sein, welche IP-Adressen da zum Einsatz kommen. Oder meintest Du in Wirklichkeit, sie hatten keinen Zugriff mehr auf die 192.168.179.1 ?

Und wenn ich in der GUI die bridge deaktiviere, verbinden sich die Clients auch nicht mehr.

Ich bleibe bis zum Beweis des Gegenteils dabei ... wenn Du in der GUI die Bridge aktiviert hast, wird in rc.openvpn unmittelbar nach dem Start folgendes gemacht:

Code:

    trap 'echo -e "You may get some more hints by starting ${DAEMON} w/o \"--daemon\":\n\t$DAEMON --config ${DAEMON_CONFIG}"' EXIT
    modlib_startdaemon ${DAEMON} --config ${DAEMON_CONFIG} --writepid /var/run/${DAEMON}.pid --daemon
    trap - EXIT

    # if we have brctl, then try to add tap to "lan" if requestet (ignore errors)
    if [ $(which brctl) ] && TAP=$(grep "#Helperline" ${DAEMON_CONFIG} | grep -o tap[0-9] ); then
        brctl addif lan $TAP 2> /dev/null
    fi

Wenn also der OpenVPN-Prozess gestartet ist und erst einmal (egal wie) sein tap-Device konfiguriert hat, wird das ohne Rücksicht auf eine bestehende Konfiguration zur lan-Bridge hinzugefügt und hat dann automatisch auch wieder die Adresse der Bridge. Ansonsten wüßte ich gerne, wie das anders funktionieren soll ...
Das heißt dann aber im Umkehrschluß wieder, wenn Du wirklich die o.a. Netzwerkmaske konfiguriert hast und die irgendwas mit den an einen Client ge"push"ten Einstellungen zu tun hat (ich lehne es nach wie vor ab, mich mit der Zuordnung von GUI-Einstellungen zu config-Einstellungen zu befassen), dann kriegen die Clients ggf. die Adresse 192.168.179.230/27 und wenn sie damit die 192.168.179.1/24 nicht erreichen, ist das nicht wirklich verwunderlich.

Es bleibt die Bitte um die "fertige" Serverkonfiguration, sowie eine Client-Konfiguration für eine entfernte FRITZ!Box (um es langsam anzugehen) und dann kann man versuchen, auf der lokalen FRITZ!Box ein ordentliches Transfernetz zu konfigurieren (warum Du da mit einem weiteren Subnetting für 192.168.179.0/24 noch weitere Verwirrung stiften willst, verstehe ich nicht ... wenn es dafür einen Grund gibt, sag es halt) und erst einmal einen Client passend dazu einzurichten. Mit Client-Konfiguration meine ich dabei ausdrücklich die OpenVPN-Einstellungen der entfernten FRITZ!Box, die lokalen Client-Einstellungen (vermutlich bei Zertifikaten unter dem CN aus dem Zertifikat im ccd gespeichert) gehören zur Serverkonfiguration (und die hatte ich schon erwähnt).

Ich bin kein OpenVPN Spezialist aber weiß, dass bei TAP eigentlich kein Routing erforderlich ist, aber bridge ist wohl wichtig dafür.

Wenn Du keine Broadcasts oder ähnliches zwischen den Standorten brauchst (schau Dir halt bei openvpn.net die FAQ an, was der Unterschied ist und was womit nicht oder nur schwerer geht), gibt es keinen "TAP-Zwang". Auch das mit dem Bridgen hast Du event. falsch verstanden. Es braucht ein tap-Device zum Bridgen, aber keine Bridge (im GUI) für's tap-Device. Du hast in Deiner Konfiguration so viele Routing-Points, da sehe ich nicht, was da noch ein Layer2-Forwarding zwischen entfernten Standorten bringen soll. Das macht dann Sinn, wenn z.B. ein Windows-Server unter 192.168.179.10 von einem der OpenVPN-Clients ohne weitere Maßnahmen gefunden werden soll. Spätestens in das Netscreen-LAN ist das ohnehin Makulatur.

Gut, Du magst ja jetzt jahrelang eine funktionierende Konfiguration gehabt haben ... aber die funktioniert nun ganz klar nicht mehr mit 06.20 und Du mußt Dich entscheiden, ob Du entweder etwas Systematik in das Netzwerk und die OpenVPN-Einstellungen bringen willst (das Netzwerk spreche ich deshalb an, weil mir das FTP-Forwarding immer noch äußerst spanisch vorkommt) oder lieber auf die 06.20 verzichten willst. Und mit Systematik meine ich Einstellungen, bei denen man versteht, was sie bewirken und was nicht und wo dann auch nur genau die notwendigen Einstellungen vorhanden sind ... wenn es nur um ein "Hinfrickeln" geht, bin ich der falsche Helfer.

han-solo · 21 Nov 2014

Ok, danke für die Erläuterungen. Ich mach für heute erstmal Schluß, die Frau guckt schon böse.
Mit dem Subnet hast du Recht. Die 192.168.179.225 wäre richtig gewesen. Und JA, ich will es korrekt neu aufbauen und nicht frickeln.
Ich glaube ich schicke dir morgen mal eine PN und erwähne noch ein paar Deatails, die ich hier nicht veröffentlichen möchte.
Auch die Konfiguration von Server und Client werde ich beifügen.

Und bei dem FTP-Forwarding hab ich mich wohl misssverständlich ausgedrückt. Dieses geht an die 10.4.70.106 und das liegt hinter der Netscreen.
Aber merkwürdigerweise verschwindet der Haken gelegentlich aus dem er Portforwarding Tabelle.

Guten N8
HS

han-solo · 23 Nov 2014

Lösung gefunden! Siehe: http://www.ip-phone-forum.de/showthread.php?t=272055&page=5&p=2052234&viewfull=1#post2052234

Languages

Suche

Languages

Suche

[Gelöst] OpenVPN in freetz stört Portforwarding in Firmware 6.20

han-solo

Mitglied

Anhänge

MaxMuster

IPPF-Promi

PeterPawn

IPPF-Urgestein

han-solo

Mitglied

PeterPawn

IPPF-Urgestein

han-solo

Mitglied

PeterPawn

IPPF-Urgestein

han-solo

Mitglied

han-solo

Mitglied

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums