kein "interner" Zugriff auf OpenVPN-Server

[mscd]

Hallo zusammen,

ich stehe gerade vor dem Problem, dass ich OpenVPN von extern (z.B. Handy-Netz) problemfrei nutzen kann. Der Server hört auf "any" (UDP-port 1194). Befinde ich mich im eigenen Netzwerk (mit entsprechender Firewall-Regel, dass z.B. UDP 1194 erlaubt ist, was mir auch im Protokoll bestätigt wird), erhalte ich folgende Fehlermeldung auf dem Log des OpenVPN-Servers (-> siehe Bild im Anhang).

"10.129.0.50:53306 write UDPv6: Can't assign requested address (code=49)"

Hat hier jemand einen "Tipp" auf Lager?

Schöne Grüße und Dank,
mscd

[JeGr]

Hi,

Ohne Konfiguration und Details wäre das nur Raten im Nebel. Ein wenig mehr Konfigation wäre da schon hilfreich. Aber OpenVPN intern zu nutzen um sich intern!? einzuwählen macht nur in den wenigsten Fällen Sinn. Und wenn der Zugriff dazu aus dem gleichen Netz kommt, das der Client dann zugewiesen bekommt noch weniger. Dass es dann zu Adressproblemen kommt wäre jetzt nicht außergewöhnlich.

Cheers

[mscd]

Hallo,

... dann gehöre ich wohl evtl. zu den "wenigen Fällen".

Wir nutzen OPNsense an einer Schule ... mehrere VLANS (Lehrer, Verwaltung, Schüler, Drucker, usw.) ... mehrere VPN-User für Heimarbeit (z.B. in der Verwaltung). Config des OpenVPN-Server ist im Prinzip "listen auf any" (UDP-Port 1194) ... da geht alles sauber (von extern kommend). Die Client-VPN-Config löst den Server per DnyDNS-Eintrag (auf eine unserer externen IP-Adressen, Kablemodem) auf.

Nun kommt der (naheliegende) Fall vor, dass ein Mitarbeiter/Lehrer, wenn er sich mit seinem Laptop im Haus befindet im BYOD-VLAN (mit der selben VPN-Client-Config auf seinem Laptop) eine VPN-Verbindung aufbauen will, um damit eine gesicherte Verbindung ins Verwaltung-Netz (wie von zu Hause aus) zu erhalten.

Grüße,
mscd

P.S.: Anbei noch ein Bilder der Server-Config ... wie gesagt ... die UDP-Pakete erhält der Server ... und schmeißt die obige Fehlermeldung.

[chemlud]

Du versuchst aus einem lokalen Netz, das über VPN erreichbar ist, dich in eben dieses VPN einzuklinken? Das kann nicht gehen.

[mscd]

Hallo,

NEIN ... bin z.B. im Subnetz 10.100.0.0/24 (WLAN-Personal) ... und möchte eine VPN-Verbindung aufbauen ... über welche ich dann das Subnetz 10.200.0.0/24 (Verwaltung) erreichen kann. Soooo ungewöhnlich ist das eigentlich (ehrlich gesprochen) nicht.

Exakt diese Konstellation ging früher mit unserer Sophos UTM problemfrei - nur so zur Info.

Grüße,
mscd

[chemlud]

Ja, so kann es funktionieren. Habe ich auch schon zum laufen gebracht.

Warum beschwert sich der Tunnel über UDPv6, wenn er für IPv4 konfiguriert ist? Das passt nicht zusammen...

Mal Haken bei "IPv6 deaktivieren" gesetzt?

[JeGr]

> Die Client-VPN-Config löst den Server per DnyDNS-Eintrag (auf eine unserer externen IP-Adressen, Kablemodem) auf.

Da wird doch schon das erste Problem drinstecken, die Config geht auf die DynDNS Adresse die dann - wahrscheinlich - auf die externe Adresse auflöst. Die ist aber intern nicht einfach erreichbar.

Mal die DynDNS Adresse intern im DNS (Forwarder oder Resolver je nachdem was genutzt wird) als DNS Override eingetragen und einfach eine interne Adresse die erreichbar sein sollen aus jedem Netz angegeben? Dann wird der DNS Name intern aufgelöst, der Zugriff geht nicht auf das vermeintliche WAN und muss nicht wieder Retour an den VPN Server.

Zudem ist meiner Erfahrung nach das Setting UDP/any als Interface (OpenVPNs MultiHome Modus) noch an einigen Stellen recht eckig. Ich würde es im zweiten Schritt ggf. versuchen, da OpenVPN lieber intern auf localhost zu binden  und auf allen Interfaces wo die Verbindung möglich sein soll einfach Forwardings anzulegen auf localhost/1194. Funktioniert aus der Praxis gesprochen wesentlich simpler/einfacher als der MultiInterface Modus den OVPN aktuell implementiert hat, auch weil der u.a. dann auch auf IPv6 hört und damit schon gerne mal rumbocken kann.

[rainerle]

Hallo,

ich sitze hier gerade vor dem gleichen Problem, allerdings brauche ich noch zusätzlich IPv6.

Aktuelles Setup:
- OpenVPN Service mit "UDP" und "Localhost" konfiguriert.
- Firewall Alias Localhost mit Host(s) "localhost" angelegt - das wird aufgelöst auf 127.0.0.1 und ::1
- NAT Forwarding Rule für IPv4+IPv6 und UDP von Client LAN und Uplink auf Localhost gebaut - die daraus generierte Firewall Regel wurde als Floating Regel angelegt.

Problem:
- Mit IPv4 funktioniert das OpenVPN aus Client LAN und Uplink
- Mit IPv6 kommt ein CLOSED:SYN_SENT/Connection timed out

Mit einem sockstat -l sieht man:

Code: [Select]

root@opnsense01:~ # sockstat -l | grep openvpn
root     openvpn    20936 4  stream /tmp/php-fastcgi.socket-1
root     openvpn    20936 7  stream /var/etc/openvpn/server1.sock
root     openvpn    20936 9  udp4   127.0.0.1:1194        *:*
root@opnsense01:~ #
Und dann kuckt man in die /var/etc/openvpn/server1.conf

Code: [Select]

...
local 127.0.0.1
...

Wie bekommt man denn OpenVPN mit IPv6 und IPv4 gestartet für Client LAN und Uplink?

Schönen Gruß
rainerle

[rainerle]

Also eigentllich muss ich "multihome" (Interface "Any") benutzen, um UDP4 und UDP6 zu verwenden:

Code: [Select]

root@opnsense01:~ # sockstat -l | grep openvpn
root     openvpn    64043 4  stream /tmp/php-fastcgi.socket-1
root     openvpn    64043 7  stream /var/etc/openvpn/server1.sock
root     openvpn    64043 9  udp46  *:1194                *:*
root@opnsense01:~ #
Aber mit multihome bekomme ich wieder den Fehler hier am Client:

Code: [Select]

Can't assign requested address (code=49)
Und wenn man dann NAT Forwarding drüberstülpt geht es auch kaputt, weil der multihome server natürlich dem Client direkt antworten will...

"It doesn't work!"

[Reiner030]

An sich ganz einfach: Die Default Einstellung des OpenVPN Interfaces "Any" nutzen.

Für IPv4 habe ich sonst einfach "localhost" verwendet und bei dem/allen zu nutzenden Interfaces eine Rewrite Regel für <remote-Server><OpenVPN Port> => localhost:<OpenVPN Port> eingerichtet, was jedoch mit IPv6 nicht gehen dürfte.


Für das ursprüngliche Routing Problem war die Lösung auch simpel, man muss nur die metric (die "Kosten" des Routing Pfades) erhöhen.
Irgendwann vor 2014 hatte ich das mal im pfSense Forum selber gepostet, ist nur leider durch die Forums Migration verloren gegangen...

Meine damalige Referenz konnte ich mit 5 Minuten Suche aber wiederfinden:
https://forums.openvpn.net/viewtopic.php?t=8759#p15359

Code: [Select]

push "route 192.168.0.0 255.255.254.0 vpn_gateway 100"

[rainerle]

Die "Advanced Config" -> "Advanced" fällt ja bald weg, wo man das einstellen kann.

Wäre es da zielführend einen Patch einzureichen, der das für alle Netze in "IPv4 Local Network" und "IPv6 Local Network" macht?

Anders gesagt: Die Liste der Netze in "IPv4 Local Network" und "IPv6 Local Network" ist bei mir schon recht lang und ich bin recht faul  .

[Reiner030]

mhhh

Die "Advanced Config" -> "Advanced" fällt ja bald weg, wo man das einstellen kann.

stimmt, da hab ich irgendwo schon was gelesen... wäre ein wichtiger Grund für uns, doch bei der pfSense zu bleiben... was schade wäre

Wäre es da zielführend einen Patch einzureichen, der das für alle Netze in "IPv4 Local Network" und "IPv6 Local Network" macht?

Anders gesagt: Die Liste der Netze in "IPv4 Local Network" und "IPv6 Local Network" ist bei mir schon recht lang und ich bin recht faul  .

Zumindest dieser Punkt geht sogar in pfSense wie OPNsense doch recht einfach?

IPv4 Local Network   
These are the IPv4 networks that will be accessible from the remote endpoint. Expressed as a comma-separated list of one or more CIDR ranges. You may leave this blank if you don't want to add a route to the local network through this tunnel on the remote machine. This is generally set to your LAN network.

IPv6 Local Network   
These are the IPv6 networks that will be accessible from the remote endpoint. Expressed as a comma-separated list of one or more IP/PREFIX. You may leave this blank if you don't want to add a route to the local network through this tunnel on the remote machine. This is generally set to your LAN network.

[JeGr]

In den meisten Fällen braucht es keine Einträge in den Advanced Config Options. Mehrere Netze gehen wie Reiner schon sagt einfach kommasepariert hintereinander ohne Probleme in beiden Systemen, egal welche Sense.

Der Multihome Server sollte auch kein Problem machen, anscheinend wird dann aber eine falsche Client config ausgeworfen? Oder wann/wo passiert der Fehler "Can't assign requested address (code=49)" auf dem Client? Wenn die Verbindung schon aufgebaut ist? Ansonsten in der Client Config mal ein "verb 3 " mit aufnehmen, damit das logging etwas ausführlicher ist und posten, denn die Umstellung des Servers von einem Interface auf Multihome sollte am Client eigentlich nichts ändern außer es werden falsche Server- oder Client Configs dann erzeugt. Dann muss man sich das aber als Bug mal ansehen.

> - Firewall Alias Localhost mit Host(s) "localhost" angelegt - das wird aufgelöst auf 127.0.0.1 und ::1

Das macht für mich keinen Sinn, warum legst du denn einen Alias an in dem du dann nochmal nen Namen (localhost) packst anstatt direkt einfach 127.0.0.1 und ::1 reinzuschreiben? Das ist doch unnötig doppelt gemoppelt?

>  NAT Forwarding Rule für IPv4+IPv6 und UDP von Client LAN und Uplink auf Localhost gebaut - die daraus generierte Firewall Regel wurde als Floating Regel angelegt.

Argh, nein. Bitte keine Floating Regel. Ich mutmaße mal die Floating Regel ist dann auch noch auf mehrere Interfaces statt nur WAN/Uplink konfiguriert? Dann wird der Regel auch das Reply-To Statement entfernt. Das ist dann nicht wirklich zielführend.

> NAT Forwarding Rule für IPv4+IPv6 und UDP von Client LAN und Uplink auf Localhost gebaut - die daraus generierte Firewall Regel wurde als Floating Regel angelegt.

Ohne das gerade zwischen Tür und Angel ausprobiert zu haben klingt das für mich nach etwas, was keine korrekte Regel/Weiterleitung erzeugen kann, da IPv4 und v6 verschieden behandelt werden und man die nicht einfach zusammen weiterleiten kann - zumindest hatte ich das damals noch nie erfolgreich geschafft, weil da pf rule logic nicht gepasst hat. Wenn das mit IPv4+IPv6 laufen soll, dann führt IMHO an Multihome kein Weg vorbei, da sich bei Binding an Localhost und Auswahl UDP der Prozess trotzdem nur an die v4 bindet, nicht an die v6 und daher nicht funktioniert.

Soweit ich gesehen habe bindet sich lediglich "any" (also multihoming) an udp46, alles andere bindet sich NUR an udp4 oder udp6. Daher wird das mit Forwarding wohl nicht funktionieren, wenn dual-stack gebraucht wird.


Cheers