[OPENVPN] problemen met connection naar client

[ZatarraNL]

Hallo allemaal,

Ik ben al een tijdje aan het zoeken, maar ik kom er niet uit. Misschien dat jullie mij kunnen helpen?

Mijn vraag:
Hoe kan ik vanuit mijn eigen LAN verbinding maken met client NAS-2?

De situatie:
Ik heb een LAN met ip-range 192.168.2.0/24 en een ovpn subnet 10.8.0.0/24.
De gateway is 192.168.2.1 (ubiquiti USG router en ook LAN DHCP-server)
Mijn DSN-server is 192.168.2.100 in een proxmox container
Mijn Ovpn-server is 192.168.2.168 in een proxmox container
Ik heb vier vaste ovpn clients. Twee externe 'NASsen', een laptop en een android telefoon.

Mijn doel:
* de beide NAS-clients hebben 24/7 verbinding (werkt)
* alle clients hebben toegang tot het lokale LAN-netwerk (werkt)
* alle clients hebben onderling toegang (werkt)
* alle LAN-apparaten hebben toegang tot de vpn-clients (werkt deels)

Die laatst gaat het om. Beide NASsen hebben verbinding. Eén met ip-adress 10.8.0.3. De ander met ip-adress 10.8.0.6 (vaste ip-adressen). Maar alleen NAS-1 is bereikbaar vanuit de LAN. NAS-2 is alleen bereikbaar via de ovpn-server en via andere ovpn-clients, maar niet vanuit de LAN met 192.168.2.x.

Settings:

A. mijn Unify controller route alle data voor 10.8.0.0/24 naar mijn ovpn-server (192.168.2.168).

B. Mijn ovpn-server heeft de volgende settings:

code:

local 192.168.2.168
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 192.168.2.100"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify

De iptable laat zien:

code:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:openvpn

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  10.8.0.0/24          192.168.0.0/24       ctstate NEW
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all  --  10.8.0.0/24          anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

C. De clients hebben de volgende config:

code:

client
dev tun
proto udp
remote <<adress>> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3
ping 60
ping-restart 120
<ca>
</ca>
<cert>
</cert>
<key>
</key>
<tls-crypt>
</tls-crypt>

Mijn eigen onderzoek laat het volgende zien:

Kernel IP routing table is als volgt:

code:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG        0 0          0 eth0
10.8.0.0        0.0.0.0         255.255.255.0   U         0 0          0 tun0
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

De traceroute vanuit een LAN-apparaat naar ovpn-client NAS-1 krijgt de volgende resultaten:

code:

traceroute to 10.8.0.3 (10.8.0.3), 30 hops max, 60 byte packets
 1  routel (192.168.2.1)  0.308 ms  0.474 ms  0.644 ms
 2  192.168.2.168 (192.168.2.168)  1.144 ms  1.580 ms  2.028 ms
 3  10.8.0.3 (10.8.0.3)  13.664 ms  13.672 ms  13.674 ms

De traceroute vanuit een LAN-apparaat naar ovpn-client NAS-2 krijgt de volgende resultaten:

code:

traceroute to 10.8.0.6 (10.8.0.6), 30 hops max, 60 byte packets
 1  router (192.168.2.1)  0.317 ms  0.469 ms  0.637 ms
 2  192.168.2.168 (192.168.2.168)  1.122 ms  1.581 ms  2.035 ms
 3  * * *

Waar gaat dit mis? Waar kan ik vanuit de LAN wel NAS-1, maar niet NAS-2 bereiken? Jullie een idee?

[ Voor 5% gewijzigd door ZatarraNL op 08-05-2022 07:52 ]

[DiedX]

Zet een route naar 10.8.0.0/24 naar je terminator. Je nas weet niet waar de vpn is.

[stijnos1991]

Klinkt alsof er ergens een static route mist, dan kan het verkeer niet 'terug' naar je vpnbak

[ZatarraNL]

DiedX schreef op zaterdag 7 mei 2022 @ 21:50:
Zet een route naar 10.8.0.0/24 naar je terminator. Je nas weet niet waar de vpn is.

Waar moet ik dit instellen? Cliënt ovpn config?

stijnos1991 schreef op zondag 8 mei 2022 @ 07:47:
Klinkt alsof er ergens een static route mist, dan kan het verkeer niet 'terug' naar je vpnbak

Dat vermoed ik ook. Maar dat is dan een instelling van de client, neem ik aan. Is dat iets dat in de config van de ovpn-client moet worden gefixt?
Het vreemde is dat de cliënt config van beide nassen identiek is, maar het gedrag is niet identiek. Kan het nog te maken hebben met een van onderstaande verschillen?
- NAS1 is een Proxmox server
- NAS2 is een openmediavault server

Beide zijn in de basis Debian.

[ Voor 16% gewijzigd door ZatarraNL op 08-05-2022 12:35 ]

[ZatarraNL]

Andere mogelijke oorzaak:

De lokale LAN van de ovpn-server is 192.168.2.0/24
De lokale LAN van de NAS2-client is ook 192.168.2.0/24

Deze twee komen overeen. Is dit misschien de oorzaak dat de NAS2-client de weg terug niet kan vinden? En zo ja, is er een simpele oplossing zonder de beide LANS helemaal aan te passen?

[DiedX]

ZatarraNL schreef op zondag 8 mei 2022 @ 12:31:
[...]


Waar moet ik dit instellen? Cliënt ovpn config?

Nee, op je nas. Zoek eens naar “set static route”.

[Thralas]

ZatarraNL schreef op zondag 8 mei 2022 @ 13:41:
Deze twee komen overeen. Is dit misschien de oorzaak dat de NAS2-client de weg terug niet kan vinden? En zo ja, is er een simpele oplossing zonder de beide LANS helemaal aan te passen?

Ja, dat is gegarandeerd de oorzaak.

Voor wat betreft de oplossing kun je kiezen uit: één subnet aanpassen ('helemaal' aanpassen is niet zo erg als het klinkt als je gewoon DHCP gebruikt), een beperkte route voor de 'andere' 192.168.2.0/24 zetten of misschien wel de meest pragmatische: op je VPN-server al het verkeer dat richting NAS2 gaat masqueraden (dwz. NAT zodat het lijkt alsof het verkeer van 10.8.0.X komt en NAS2 niet meer in de knoop raakt qua routes).

[ZatarraNL]

Thralas schreef op maandag 9 mei 2022 @ 19:57:
[...]


Ja, dat is gegarandeerd de oorzaak.

Voor wat betreft de oplossing kun je kiezen uit: één subnet aanpassen ('helemaal' aanpassen is niet zo erg als het klinkt als je gewoon DHCP gebruikt), een beperkte route voor de 'andere' 192.168.2.0/24 zetten of misschien wel de meest pragmatische: op je VPN-server al het verkeer dat richting NAS2 gaat masqueraden (dwz. NAT zodat het lijkt alsof het verkeer van 10.8.0.X komt en NAS2 niet meer in de knoop raakt qua routes).

Helaas, ik heb enkel invloed op het subnet van mijzelf. En ik maak veel gebruik van vaste ip-adressen. Omzetten is dus voor mij wel veel werk. Maar misschien dat ik het toch ga doen....

Die masquerade klinkt interessant. Geen idee hoe ik dat moet doen, maar ik zal eens googlen. Ik geloof dat ik begrijp wat je hier bedoeld.

Dank iedereen voor de reacties. Ik ga binnenkort eens tweaken. Als het gelukt is zal ik het laten weten. Voor alles een eerste keer. En zo'n eerste keer is veel werk, maar ook de meeste voldoening.

Edit - eerste poging:
Klopt het dat ik deze masquerade regel in de iptable van de vpn-server? Klopt het dat het volgende moet toevoegen?

code:

iptables -t nat -I POSTROUTING -s 192.168.2.0/24 -o tun0 -j MASQUERADE

Ik voorzie een mogelijk probleem:
- de vpn-clients kunnen geen contact maken met lokale LAN-apparaten. Dat is voor deze specifieke NAS2 geen probleem, maar voor de andere clients wel.

Misschien werkt zoiets ook met een individuele client?

code:

iptables -t nat -I POSTROUTING -s 192.168.2.0/24 --d 10.8.0.6 -o tun0 -j MASQUERADE

Edit2:
Eerste poging is succesvol. Dit werkt uitstekend.

[ Voor 21% gewijzigd door ZatarraNL op 11-05-2022 20:20 ]