OpenVPN cliënt verbonden maar kan niet bij apparaten

[MsG]

Ik draai al een tijdje een Raspberry Pi met Raspbian in de meterkast. Sindskort ook met PiVPN, wat een soort kant-en-klare OpenVPN-installer is.

Dit werkte al tijden prima, ik kan vanaf m'n Android-telefoon overal bij via de OpenVPN app en kan ook alle apparaten met webservices bereiken vanaf de Chrome-browser op de Android-telefoon.

Vanuit de VPN-server krijg ik een IP in de reeks: 10.8.0.X en de eigenlijke netwerk-range is 192.168.1.X

[b]Probleem:
Nu krijg ik het maar niet aan de praat op mijn Windows 10 (1803) laptop. Ik ben prima verbonden en als ik naar https://watismijnip.nl ga dan krijg ik ook keurig het IP van mijn VPN-server en niet van het lokale netwerk waar ik op zit, dus dat gaat allemaal prima.

Alleen elk lokale webdienst die ik draai, Domoticz, Octoprint, Node-Red, SSH ik kom er allemaal niet bij. Ik krijg "connection refused" meldingen van die IP's of die SSH-verbindingen die ik probeer op te zetten.

Dit terwijl mijn Android-telefoon dit dus prima kan.

Al geprobeerd:
- OpenVPN verwijderd en weer geïnstalleerd. Geen verschil.
- .openvpn-bestand voor mijn mobiele telefoon geladen op de laptop. Geen verschil.
- OpenVPN als admin en niet als admin gestart. Geen verschil
- De metric order van de virtuele TAP-netwerkkaart veranderd. Geen verschil


Gezien alles prima werkt op mijn Android-telefoon moet het in mijn laptop zitten, maar ik heb geen idee waarin ik het verder moet zoeken. En mijn kennis is net een beetje op het randje bij dit soort dingen.

Ik vind het bijzonder gek gezien een paar Windows 10-versies geleden de boel prima werkte. Als ik niet bij mijn apparatuur kan heb ik er bijzonder weinig aan.

Mensen een richting of tip waarin ik het kan zoeken?


Stukje logfile van de client:

Tue Sep 18 15:41:58 2018 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Tue Sep 18 15:41:58 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Tue Sep 18 15:41:58 2018 library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
Enter Management Password:
Tue Sep 18 15:41:58 2018 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Tue Sep 18 15:41:58 2018 Need hold release from management interface, waiting...
Tue Sep 18 15:41:58 2018 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Tue Sep 18 15:41:58 2018 MANAGEMENT: CMD 'state on'
Tue Sep 18 15:41:58 2018 MANAGEMENT: CMD 'log all on'
Tue Sep 18 15:41:59 2018 MANAGEMENT: CMD 'echo all on'
Tue Sep 18 15:41:59 2018 MANAGEMENT: CMD 'bytecount 5'
Tue Sep 18 15:41:59 2018 MANAGEMENT: CMD 'hold off'
Tue Sep 18 15:41:59 2018 MANAGEMENT: CMD 'hold release'
Tue Sep 18 15:41:59 2018 MANAGEMENT: CMD 'password [...]'
Tue Sep 18 15:41:59 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Tue Sep 18 15:41:59 2018 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Tue Sep 18 15:41:59 2018 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Tue Sep 18 15:41:59 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]VERWIJDERDWANTPUBLIEKIP
Tue Sep 18 15:41:59 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Tue Sep 18 15:41:59 2018 UDP link local: (not bound)
Tue Sep 18 15:41:59 2018 UDP link remote: [AF_INET]VERWIJDERDWANTPUBLIEKIP
Tue Sep 18 15:41:59 2018 MANAGEMENT: >STATE:1537278119,WAIT,,,,,,
Tue Sep 18 15:41:59 2018 MANAGEMENT: >STATE:1537278119,AUTH,,,,,,
Tue Sep 18 15:41:59 2018 TLS: Initial packet from [AF_INET]VERWIJDERDWANTPUBLIEKIP, sid=d559350b 3a95e45a
Tue Sep 18 15:41:59 2018 VERIFY OK: depth=1, CN=ChangeMe
Tue Sep 18 15:41:59 2018 VERIFY KU OK
Tue Sep 18 15:41:59 2018 Validating certificate extended key usage
Tue Sep 18 15:41:59 2018 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Tue Sep 18 15:41:59 2018 VERIFY EKU OK
Tue Sep 18 15:41:59 2018 VERIFY X509NAME OK: CN=server_AS7sO7azUsRyrCnS
Tue Sep 18 15:41:59 2018 VERIFY OK: depth=0, CN=server_AS7sO7azUsRyrCnS
Tue Sep 18 15:41:59 2018 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Tue Sep 18 15:41:59 2018 [server_AS7sO7azUsRyrCnS] Peer Connection Initiated with [AF_INET]VERWIJDERDWANTPUBLIEKIP:1194
Tue Sep 18 15:42:00 2018 MANAGEMENT: >STATE:1537278120,GET_CONFIG,,,,,,
Tue Sep 18 15:42:00 2018 SENT CONTROL [server_AS7sO7azUsRyrCnS]: 'PUSH_REQUEST' (status=1)
Tue Sep 18 15:42:00 2018 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,block-outside-dns,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 1800,ping-restart 3600,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'
Tue Sep 18 15:42:00 2018 OPTIONS IMPORT: timers and/or timeouts modified
Tue Sep 18 15:42:00 2018 OPTIONS IMPORT: --ifconfig/up options modified
Tue Sep 18 15:42:00 2018 OPTIONS IMPORT: route options modified
Tue Sep 18 15:42:00 2018 OPTIONS IMPORT: route-related options modified
Tue Sep 18 15:42:00 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Sep 18 15:42:00 2018 OPTIONS IMPORT: peer-id set
Tue Sep 18 15:42:00 2018 OPTIONS IMPORT: adjusting link_mtu to 1625
Tue Sep 18 15:42:00 2018 OPTIONS IMPORT: data channel crypto options modified
Tue Sep 18 15:42:00 2018 Data Channel: using negotiated cipher 'AES-256-GCM'
Tue Sep 18 15:42:00 2018 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Sep 18 15:42:00 2018 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Sep 18 15:42:00 2018 interactive service msg_channel=0
Tue Sep 18 15:42:00 2018 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 I=10 HWADDR=ac:fd:ce:27:8c:dd
Tue Sep 18 15:42:00 2018 open_tun
Tue Sep 18 15:42:00 2018 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{0CA97272-8E1A-40D4-8DB6-D5EA0860C516}.tap
Tue Sep 18 15:42:00 2018 TAP-Windows Driver Version 9.21 
Tue Sep 18 15:42:00 2018 Set TAP-Windows TUN subnet mode network/local/netmask = 10.8.0.0/10.8.0.2/255.255.255.0 [SUCCEEDED]
Tue Sep 18 15:42:00 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.2/255.255.255.0 on interface {0CA97272-8E1A-40D4-8DB6-D5EA0860C516} [DHCP-serv: 10.8.0.254, lease-time: 31536000]
Tue Sep 18 15:42:00 2018 Successful ARP Flush on interface [9] {0CA97272-8E1A-40D4-8DB6-D5EA0860C516}
Tue Sep 18 15:42:00 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Tue Sep 18 15:42:00 2018 MANAGEMENT: >STATE:1537278120,ASSIGN_IP,,10.8.0.2,,,,
Tue Sep 18 15:42:00 2018 Block_DNS: WFP engine opened
Tue Sep 18 15:42:00 2018 Block_DNS: Using existing sublayer
Tue Sep 18 15:42:00 2018 Block_DNS: Added permit filters for exe_path
Tue Sep 18 15:42:00 2018 Block_DNS: Added block filters for all interfaces
Tue Sep 18 15:42:00 2018 Block_DNS: Added permit filters for TAP interface
Tue Sep 18 15:42:05 2018 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Tue Sep 18 15:42:05 2018 C:\WINDOWS\system32\route.exe ADD VERWIJDERDWANTPUBLIEKIP MASK 255.255.255.255 192.168.1.1
Tue Sep 18 15:42:05 2018 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
Tue Sep 18 15:42:05 2018 Route addition via IPAPI succeeded [adaptive]
Tue Sep 18 15:42:05 2018 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.1
Tue Sep 18 15:42:05 2018 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=3 and dwForwardType=4
Tue Sep 18 15:42:05 2018 Route addition via IPAPI succeeded [adaptive]
Tue Sep 18 15:42:05 2018 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.8.0.1
Tue Sep 18 15:42:05 2018 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=3 and dwForwardType=4
Tue Sep 18 15:42:05 2018 Route addition via IPAPI succeeded [adaptive]
Tue Sep 18 15:42:05 2018 Initialization Sequence Completed
Tue Sep 18 15:42:05 2018 MANAGEMENT: >STATE:1537278125,CONNECTED,SUCCESS,10.8.0.2,VERWIJDERDWANTPUBLIEKIP,1194,,

[Mijzelf]

MsG schreef op dinsdag 18 september 2018 @ 15:57:
Vanuit de VPN-server krijg ik een IP in de reeks: 10.8.0.X en de eigenlijke netwerk-range is 192.168.1.X
<snip>

Tue Sep 18 15:42:00 2018 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 I=10 

Zit je laptop niet in een lokaal netwerk met hetzelfde subnet als waarin je RPi zit? In dat geval kan je laptop geen route naar de omgeving van die RPi krijgen.

[MsG]

Mijzelf schreef op dinsdag 18 september 2018 @ 17:07:
[...]

Zit je laptop niet in een lokaal netwerk met hetzelfde subnet als waarin je RPi zit? In dat geval kan je laptop geen route naar de omgeving van die RPi krijgen.

Het subnet van OpenVPN is 10.8.0.X en van het netwerk zelf is 192.168.1.X. Maar dat is al vanaf dag 1 zo met OpenVPN en stuit op m'n Android-telefoon níet op een probleem. De OpenVPN-server maakt hierin de vertaalslag. Dit subnet was hetzelfde toen het nog wèl prima werkte op Windows 10.

[Voor 6% gewijzigd door MsG op 18-09-2018 17:22]

[king006]

@MsG,

Even een andere vraag, waarom wil je OpenVPN gebruiken en niet IPSEC? met IPSEC hoef je namelijk geen apart programma te installeren op Windows en Android, daar kun je de default voor gebruiken. Zelf heb ik ook IPSEC vpn draaien op een PI en dat werkt fantastisch en zonder problemen. Als je dat wil, laat het even weten, ik heb een script gedownload die je kan uitvoeren en welk alles regelt. Uiteraard met uitzondering van portforwarding in je modem/router.

Probeer je verbinding te maken aan de hand van het IP Adres van je PI? of via een domeinnaam?

[Voor 9% gewijzigd door king006 op 18-09-2018 17:25]

[MsG]

king006 schreef op dinsdag 18 september 2018 @ 17:23:
@MsG,

Even een andere vraag, waarom wil je OpenVPN gebruiken en niet IPSEC? met IPSEC hoef je namelijk geen apart programma te installeren op Windows en Android, daar kun je de default voor gebruiken. Zelf heb ik ook IPSEC vpn draaien op een PI en dat werkt fantastisch en zonder problemen. Als je dat wil, laat het even weten, ik heb een script gedownload die je kan uitvoeren en welk alles regelt. Uiteraard met uitzondering van portforwarding in je modem/router.

Probeer je verbinding te maken aan de hand van het IP Adres van je PI? of via een domeinnaam?

Het scheen dat die standaard Windows VPN-opties gecompromitteerd en dus onveilig waren. En gezien er met PiVPN een 1-regelig commando nodig is en het daarna werkend is leek me dat prima. Het werkte voorheen ook perfect dus het liefst heb ik het gewoon weer zoals het was, uitwijken naar optie B is m.i. een beetje symptoombestrijding.

De VPN-connectie an sich gaat dus ook prima, alleen ik krijg een refused bij de apparaten die ik wil bereiken (geen time out, maar echt refused).

[Kaalus]

Zeer waarschijnlijk heb je routing nodig van het OpenVPN subnet naar je 192.168.x subnet. Je moet daarvoor in elk geval packet forwarding aan hebben staan op je Pi. Daarnaast ook nog routes zodat verkeer vanuit het VPN subnet weet waar het verkeer voor 192.168.x heen moet en vice versa.

[MsG]

Worden die routes juist niet gemaakt op cliënt niveau? Dat soort dingen zag ik wel voorbijkomen in de logs en het gestuntel met die virtuele netwerkadapter en zou verklaren waarom mijn telefoon het zonder morren pakt.

Even voor de beeldvorming, het heeft prima gewerkt, en aan de Raspberry kant is nooit iets veranderd, danwel ooit iets ingesteld qua routing/packet forwarding. Enkel is m'n laptop wat sub-versies van Windows 10 verder waarna ik ineens dit euvel ontdekte.

[Kaalus]

Ah daar had ik even overheen gelezen..
Heb je Windows 10 al eens gereboot (vast wel), heb wel eens vaker gehad dat na een wat langere tijd aanstaan en wat vaker slaapstand te hebben gebruikt opeens de routes niet meer werkte.

[hcQd]

Als het via je telefoon wel werkt en op je computer niet dan lijkt het me dat je het op die laatste moet zoeken. Misschien iets met de firewall?

[NLMaca]

@MsG Het lijkt erop dat je hetzelfde probleem hebt wat in onderstaande link ook speelt.
https://serverfault.com/q...ss-anything/827379#827379

De route wordt niet aangemaakt
oplossing:

According to the client log, the OpenVPN client did not add a static route to the OpenVPN server through the original default gateway (the one used before the connection establishes). This prevents OpenVPN client packets from reaching the server, because of the absence of a route to it. I suggest you to change the server config, replacing the line:

push "redirect-gateway local def1"
With one of these:

push "redirect-gateway autolocal def1"

push "redirect-gateway def1"

Misschien iets voor jou om uit te testen op jouw setup?

edit: ik ga hier ook eens een zelfde setup maken (ben ook gewoon nieuwsgierig hoe pivpn functioneert)

[Voor 6% gewijzigd door NLMaca op 18-09-2018 19:30]

[Thralas]

MsG schreef op dinsdag 18 september 2018 @ 15:57:
[b]Alleen elk lokale webdienst die ik draai, Domoticz, Octoprint, Node-Red, SSH ik kom er allemaal niet bij. Ik krijg "connection refused" meldingen van die IP's of die SSH-verbindingen die ik probeer op te zetten.

Weet je heel zeker dat het connection refused is? Dat duidt op een antwoord (en dus overlappende ranges?). Je zou een connection timed out verwachten. Belangrijk detail.

Het OpenVPN-gedeelte heb je alleraardigst beschreven, maar ik mis informatie over het netwerk dat je probeert te bereiken (welke range?) en diagnostics op je Windows-client (ipconfig, routes, traceroute naar thuis-service).

king006 schreef op dinsdag 18 september 2018 @ 17:23:
Even een andere vraag, waarom wil je OpenVPN gebruiken en niet IPSEC? met IPSEC hoef je namelijk geen apart programma te installeren op Windows en Android, daar kun je de default voor gebruiken.

IPsec is nodeloos complex en een ramp met NAT. Zonder expliciete NAT traversal is het onbruikbaar in een road warrior setup.

Meer iets voor site-to-site links; voor client setups is OpenVPN echt de meest robuuste keuze.

NLMaca schreef op dinsdag 18 september 2018 @ 19:28:
@MsG Het lijkt erop dat je hetzelfde probleem hebt wat in onderstaande link ook speelt.
https://serverfault.com/q...ss-anything/827379#827379

Die wordt wel aangemaakt (zie log). Anders zou er ook helemaal geen verkeer meer over de VPN gaan.

[MsG]

Ja het gaat echt om connection refused. Hij zegt het ook vrij snel.

Het netwerk dat ik probeer te bereiken is 192.168.1.X en openvpn deelt adressen uit in de sferen 10.8.0.X. het netwerk waar ik op zit is ook in de 192.168.1.X sferen

De ipconfigs zal ik morgen even doen. Wat bedoel je met Traceroute naar thuisservice?

[Euwas]

Ah, dat geeft problemen. Hoe moet Windows / openvpn onderscheiden tussen je thuisnetwerk 192.168.1. en remote 192.168.1.? Beide zijn voor Windows hetzelfde en openvpn kan die niet routen (als die dat wel doet is je gateway in je netwerk weg, en kan openvpn helemaal geen server meer bereiken)

Oplossing: zorg dat je te bereiken nodes in een netwerk zitten die niet vaak gebruikt wordt, overlap is niet mogelijk

[FreakNL]

Waarom doet zijn phone het dan wel? Of is die alleen middels 4g getest?

Zet anders FF hotspot aan op je telefoon en verbind de laptop daarmee. En dan testen. Of ga met de laptop naar een ander netwerk (buren?)

[yayo]

Dit probleem heb ik ook. Ik heb thuis een netwerk op 192.168.1.x en op werk ook 192.168.1.x. Als ik op mijn werk nu een vpn opzet naar huis kan ik mijn webservices niet bereiken omdat als ik bijvoorbeeld naar mijn nas wil connecten op 192.168.1.2 dan kom ik uit bij onze nas op werk

Enige oplossing lijkt mij 1 van de netwerken op een andere ip reeks zetten??

[Reptile209]

yayo schreef op woensdag 19 september 2018 @ 07:26:
Dit probleem heb ik ook. Ik heb thuis een netwerk op 192.168.1.x en op werk ook 192.168.1.x. Als ik op mijn werk nu een vpn opzet naar huis kan ik mijn webservices niet bereiken omdat als ik bijvoorbeeld naar mijn nas wil connecten op 192.168.1.2 dan kom ik uit bij onze nas op werk

Enige oplossing lijkt mij 1 van de netwerken op een andere ip reeks zetten??

Volgens mij kan je in de meeste vpn-clients instellen of *al* het verkeer over de vpn moet, of dat lokaal verkeer de LAN op gaat. Als je dat eerste voor elkaar krijgt, zou je bij je thuis-nas moeten kunnen. Kan je alleen ook geen lokale printers e.d. gebruiken zolang de vpn actief is.

[MsG]

Euwas schreef op woensdag 19 september 2018 @ 06:17:
Ah, dat geeft problemen. Hoe moet Windows / openvpn onderscheiden tussen je thuisnetwerk 192.168.1. en remote 192.168.1.? Beide zijn voor Windows hetzelfde en openvpn kan die niet routen (als die dat wel doet is je gateway in je netwerk weg, en kan openvpn helemaal geen server meer bereiken)

Oplossing: zorg dat je te bereiken nodes in een netwerk zitten die niet vaak gebruikt wordt, overlap is niet mogelijk

Maar voorheen werkte dat prima en m'n android telefoon slikt het ook (op datzelfde netwerk). Dat vind ik dan gek. Op het netwerk waar ik dan op zit draait verder ook weinig qua servers, terwijl op mijn vpn-netwerk er diverse dingen draaien, er is dan ook niet meteen een conflict met dezelfde ip's.

yayo schreef op woensdag 19 september 2018 @ 07:26:
Dit probleem heb ik ook. Ik heb thuis een netwerk op 192.168.1.x en op werk ook 192.168.1.x. Als ik op mijn werk nu een vpn opzet naar huis kan ik mijn webservices niet bereiken omdat als ik bijvoorbeeld naar mijn nas wil connecten op 192.168.1.2 dan kom ik uit bij onze nas op werk

Enige oplossing lijkt mij 1 van de netwerken op een andere ip reeks zetten??

Volgens mij kan je dat eenvoudig oplossen met een andere metric order van de netwerkkaart?

@Bekers ik kwam jouw post hier tegen: downloads: OpenVPN 2.4.6

Ben jij er nog uitgekomen? Het lijkt een beetje op hetzelfde probleem.

[Voor 31% gewijzigd door MsG op 19-09-2018 09:28]

[Bekers]

@MsG Ja, het bleek bij mij toch in de firewall te zitten. Firewall eens uitgezet om te proberen en toen werkte het prima. Ik had het daar zelf niet gezocht, omdat het eerst wel gewoon werkte, maar op advies toch even gekeken.

Ik weet even niet meer wat ik daarna nog aangepast heb aan de 'oude' instellingen, maar het zat het voor mij daar wel in.

[valkenier]

yayo schreef op woensdag 19 september 2018 @ 07:26:
Dit probleem heb ik ook. Ik heb thuis een netwerk op 192.168.1.x en op werk ook 192.168.1.x. Als ik op mijn werk nu een vpn opzet naar huis kan ik mijn webservices niet bereiken omdat als ik bijvoorbeeld naar mijn nas wil connecten op 192.168.1.2 dan kom ik uit bij onze nas op werk

Enige oplossing lijkt mij 1 van de netwerken op een andere ip reeks zetten??

Dit is nu al 2x benoemd in dit topic en wel degelijk een issue. Mijn openvpn werkt ook prima, behalve als ik bij iemand op de wifi zit in dezelfde netwerkrange als mijn thuisnetwerk. Dan niet. Routerings probleempje. TS kan het niet willen geloven, maar ik zou je telefoon even als hotspot instellen, laptop verbinden, en dan nog eens je Openvpn proberen op te zetten (tethering via 4G). Of het op een ander wifi netwerk nog eens proberen. Werkt het dan wel, dan wijst dat heel sterk in deze richting.

[MsG]

valkenier schreef op woensdag 19 september 2018 @ 10:31:
[...]


Dit is nu al 2x benoemd in dit topic en wel degelijk een issue. Mijn openvpn werkt ook prima, behalve als ik bij iemand op de wifi zit in dezelfde netwerkrange als mijn thuisnetwerk. Dan niet. Routerings probleempje. TS kan het niet willen geloven, maar ik zou je telefoon even als hotspot instellen, laptop verbinden, en dan nog eens je Openvpn proberen op te zetten (tethering via 4G). Of het op een ander wifi netwerk nog eens proberen. Werkt het dan wel, dan wijst dat heel sterk in deze richting.

maar voorheen had ik dat issue op dezelfde netwerken nooit? Ik zal er eens verder induiken, maar het is iets wat eerst prima werkte (ook op 192.168.1.X ranges, want dat is namelijk de halve wereld) en nu blijkbaar niet.

Op een ander netwerk kom ik er nu wel op inderdaad, vreemd, want mijn mobiel krijgt ook een 192.168.X adres en verslikt zich hierin niet. Zal nog eens kijken naar die netwerk order, wellicht kan ik het daarmee oplossen.

EDIT: Ik had handmatig nog de gateway gezet op de interne VPN-ip-reeks van de TAP netwerk-adapter, wellicht dat het daardoor nu werkt. Zit nu niet op een 192.168.1.X netwerk dus kan nu even niet verder troubleshooten.

[Voor 9% gewijzigd door MsG op 19-09-2018 12:58]

[tomdabom]

MsG schreef op woensdag 19 september 2018 @ 12:44:
[...]


maar voorheen had ik dat issue op dezelfde netwerken nooit? Ik zal er eens verder induiken, maar het is iets wat eerst prima werkte (ook op 192.168.1.X ranges, want dat is namelijk de halve wereld) en nu blijkbaar niet.

Op een ander netwerk kom ik er nu wel op inderdaad, vreemd, want mijn mobiel krijgt ook een 192.168.X adres en verslikt zich hierin niet. Zal nog eens kijken naar die netwerk order, wellicht kan ik het daarmee oplossen.

EDIT: Ik had handmatig nog de gateway gezet op de interne VPN-ip-reeks van de TAP netwerk-adapter, wellicht dat het daardoor nu werkt. Zit nu niet op een 192.168.1.X netwerk dus kan nu even niet verder troubleshooten.

Waarschijnlijk doet je telefoon wel een full-tunnel (dus dat alle traffic over je VPN gaat) en je PC niet. Dit is sowieso een routing issue. Enige echte oplossing is om je thuis netwerk om te katten naar een andere range bv: 192.168.50.0/24.. alle roadwarrior tunnels hier bij ons zijn ook hele andere ranges dan standaard en worden tevens routes gepusht.

Kun je eens een route print uitvoeren op je PC ?
IPConfig ?
En een traceroute naar 1 van je servers ?

[Voor 8% gewijzigd door tomdabom op 19-09-2018 16:26]

[MsG]

tomdabom schreef op woensdag 19 september 2018 @ 16:22:
[...]


Waarschijnlijk doet je telefoon wel een full-tunnel (dus dat alle traffic over je VPN gaat) en je PC niet. Dit is sowieso een routing issue. Enige echte oplossing is om je thuis netwerk om te katten naar een andere range bv: 192.168.50.0/24.. alle roadwarrior tunnels hier bij ons zijn ook hele andere ranges dan standaard en worden tevens routes gepusht.

Kun je eens een route print uitvoeren op je PC ?
IPConfig ?
En een traceroute naar 1 van je servers ?

Zal ik vanavond even doen. Maar als ik verbonden ben met de PC en ik ga naar watismijnip.nl krijg ik wel degelijk het IP van mijn VPN-servers-internetaansluiting. Of zegt dat niks over of álle verdere data na zo'n IP-lookup ook via de VPN gaat? M.a.w. hoe kan ik eenvoudig zien of álle verkeer over de VPN gaat of niet?

En met een full tunnel zou ik het probleem dan niet meer hebben? Gooi liever niet m'n hele thuisnetwerk om.

[tomdabom]

MsG schreef op woensdag 19 september 2018 @ 16:29:
[...]


Zal ik vanavond even doen. Maar als ik verbonden ben met de PC en ik ga naar watismijnip.nl krijg ik wel degelijk het IP van mijn VPN-servers-internetaansluiting. Of zegt dat niks over of álle verdere data na zo'n IP-lookup ook via de VPN gaat? M.a.w. hoe kan ik eenvoudig zien of álle verkeer over de VPN gaat of niet?

En met een full tunnel zou ik het probleem dan niet meer hebben? Gooi liever niet m'n hele thuisnetwerk om.

Betekend dan inderdaad dat je full tunnel hebt. Vaak is de metric van een fysieke adapter wel hoger waardoor die voor bepaalde routes toch een ander pad pakt. Vandaar mijn vraag voor een screenshot van je routing table...

[MsG]

tomdabom schreef op woensdag 19 september 2018 @ 16:32:
[...]


Betekend dan inderdaad dat je full tunnel hebt. Vaak is de metric van een fysieke adapter wel hoger waardoor die voor bepaalde routes toch een ander pad pakt. Vandaar mijn vraag voor een screenshot van je routing table...

De metric van de TAP-adapter had ik al een aantal keer mee gestoeid, maar die sprong aldoor terug naar 3.

Hier een output:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0         10.8.0.1         10.8.0.2      4
          0.0.0.0          0.0.0.0      145.37.40.1    145.37.41.215     40
          0.0.0.0        128.0.0.0         10.8.0.1         10.8.0.2    259
         10.8.0.0    255.255.255.0         On-link          10.8.0.2    259
         10.8.0.2  255.255.255.255         On-link          10.8.0.2    259
       10.8.0.255  255.255.255.255         On-link          10.8.0.2    259
     PUBLIEKE IP 255.255.255.255      145.37.40.1    145.37.41.215    296
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
        128.0.0.0        128.0.0.0         10.8.0.1         10.8.0.2    259
      145.37.40.0    255.255.252.0         On-link     145.37.41.215    296
    145.37.41.215  255.255.255.255         On-link     145.37.41.215    296
    145.37.43.255  255.255.255.255         On-link     145.37.41.215    296
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link     145.37.41.215    296
        224.0.0.0        240.0.0.0         On-link          10.8.0.2    259
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link     145.37.41.215    296
  255.255.255.255  255.255.255.255         On-link          10.8.0.2    259

Instellingen virtuele netwerkadapter



Instellingen fysieke adapter

ifIndex InterfaceAlias                  AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp     ConnectionState PolicySto
                                                                                                            re       
------- --------------                  ------------- ------------ --------------- ----     --------------- ---------
9       Ethernet 2                      IPv4                  1500               3 Enabled  Connected       Active...
7       LAN-verbinding* 11              IPv4                  1500              25 Enabled  Disconnected    Active...
6       Ethernet                        IPv4                  1500               5 Enabled  Disconnected    Active...
14      LAN-verbinding* 10              IPv4                  1500              25 Enabled  Disconnected    Active...
1       Loopback Pseudo-Interface 1     IPv4            4294967295              75 Disabled Connected       Active...
10      Wi-Fi                           IPv4                  1500              40 Enabled  Connected       Active...

[Voor 44% gewijzigd door MsG op 19-09-2018 16:46]

[tomdabom]

MsG schreef op woensdag 19 september 2018 @ 16:40:
[...]


De metric van de TAP-adapter had ik al een aantal keer mee gestoeid, maar die sprong aldoor terug naar 3.

Hier een output:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0         10.8.0.1         10.8.0.2      4
          0.0.0.0          0.0.0.0      145.37.40.1    145.37.41.215     40
          0.0.0.0        128.0.0.0         10.8.0.1         10.8.0.2    259
         10.8.0.0    255.255.255.0         On-link          10.8.0.2    259
         10.8.0.2  255.255.255.255         On-link          10.8.0.2    259
       10.8.0.255  255.255.255.255         On-link          10.8.0.2    259
     PUBLIEKE IP 255.255.255.255      145.37.40.1    145.37.41.215    296
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
        128.0.0.0        128.0.0.0         10.8.0.1         10.8.0.2    259
      145.37.40.0    255.255.252.0         On-link     145.37.41.215    296
    145.37.41.215  255.255.255.255         On-link     145.37.41.215    296
    145.37.43.255  255.255.255.255         On-link     145.37.41.215    296
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link     145.37.41.215    296
        224.0.0.0        240.0.0.0         On-link          10.8.0.2    259
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link     145.37.41.215    296
  255.255.255.255  255.255.255.255         On-link          10.8.0.2    259

Er staat hier geen enkele route naar je netwerk in. Dit gaat nooit werken tenzij je de default gateway op die van je VPN zet.

[MsG]

tomdabom schreef op woensdag 19 september 2018 @ 16:43:
[...]


Er staat hier geen enkele route naar je netwerk in. Dit gaat nooit werken tenzij je de default gateway op die van je VPN zet.

Dat heb ik ingesteld, zie screenshot van de virtuele adapter. Op dit moment zit ik ook op een locatie waarbij alles prima werkt zoals beoogd. Het is nu even de vraag of het thuis nog steeds niet werkt, of dat op de een of andere manier die netwerk order nu wel goed staat en dat het weer volledig werkt.


Waar 'PUBLIEKE IP' staat, staat mijn publieke IP-adres van de VPN-server. Wellicht zorgt dat voor enige verwarring? ;-) weinig behoefte aan Tweakers die dingen gaan proberen, vandaar dat ik dat soort gegevens verberg.

[Voor 16% gewijzigd door MsG op 19-09-2018 16:48]

[tomdabom]

MsG schreef op woensdag 19 september 2018 @ 16:47:
[...]


Dat heb ik ingesteld, zie screenshot van de virtuele adapter. Op dit moment zit ik ook op een locatie waarbij alles prima werkt zoals beoogd. Het is nu even de vraag of het thuis nog steeds niet werkt, of dat op de een of andere manier die netwerk order nu wel goed staat en dat het weer volledig werkt.

Precies, maar ik snap dat je niet je volledige netwerk wilt omgooien. Maar dat is wel de enige echte oplossing...

[MsG]

tomdabom schreef op woensdag 19 september 2018 @ 16:50:
[...]


Precies, maar ik snap dat je niet je volledige netwerk wilt omgooien. Maar dat is wel de enige echte oplossing...

Waarom heeft het dan prima gewerkt en doet m'n mobiele telefoon het prima op m'n 192.168.X netwerk? Welk IP-conflict is er überhaupt? Die is er toch pas als ik zowel een apparaat heb op het netwerk waar ik rechtstreeks op zit op bijvoorbeeld 192.168.1.2 EN als ik op dat exact zelfde IP binnen de VPN iets heb draaien. Maar stel ik wil 192.168.1.8 in m'n VPN bereiken en op het netwerk waar ik rechtstreeks op zit draait helemaal niks op 192.168.1.8 dan is er toch geen routingsprobleem?

Ik kreeg actieve "Connection refused" meldingen terug, en geen time-outs, dat lijkt me ook wezenlijk anders. Dat gecombineerd met het feit dat mijn Android-toestel zonder morren en zonder instellingswijzigingen gewoon accepteert ben ik er niet van overtuigd dat het inherent niet zou kunnen werken.

Mijn VPN-server deelt IP-adressen uit op 10.8.0.X he. De vertaalslag naar de apparatuur in 192.168.X BINNEN het VPN doet de VPN-server zelf. En dat doet ie op mijn Android-telefoon blijkbaar prima, maar op m'n laptop (tenzij het nu dus opeens thuis werkt) niet goed.

[-36-]

Maar waarom probeer je het niet gewoon? ff je ip omzetten is waarschijnlijk minder werk dan hier al die reacties typen. De vraag waarom het ooit wel met dezelfde ip-range heeft gewerkt is verder minder relevant dan de vraag waarom het nu niet werkt

[MsG]

-36- schreef op woensdag 19 september 2018 @ 17:03:
Maar waarom probeer je het niet gewoon? ff je ip omzetten is waarschijnlijk minder werk dan hier al die reacties typen. De vraag waarom het ooit wel met dezelfde ip-range heeft gewerkt is verder minder relevant dan de vraag waarom het nu niet werkt

Omdat ik nu niet thuis ben en het dus niet kan testen via die WiFi ;-) het verbaast me eerder dat het hier nu ineens wel weer werkt. Nou ja voor de uitsluiting van het probleem lijkt het me eveneens relevant dat het prima heeft gewerkt zonder m'n subnet thuis in de exotische sferen te moeten gooien. Maar point taken; ik zal hierna pas weer posten als ik het thuis weer heb geprobeerd.

Is het hele verkeer over de VPN (wat voor zover ik weer default OpenVPN is) bad practice? Of is dat maar net wat je wil? In principe wil ik alleen m'n apparatuur kunnen bereiken, en niet per se willen surfen álsof ik thuis ben met dat IP. M'n raspberry zit helaas enkel op de Wifi, dus ik merkte altijd wel een beetje vertraging tijdens browsen met de VPN aan.

[Thralas]

MsG schreef op woensdag 19 september 2018 @ 09:21:
Maar voorheen werkte dat prima en m'n android telefoon slikt het ook (op datzelfde netwerk). Dat vind ik dan gek.

Dat het eerst wel werkte is niet relevant. Dat het op Android wel werkt is óók niet echt relevant. Android heeft wat makkelijk bereikbare tunables om het verkeer door een VPN te forceren, onafhankelijk van eventuele routes die hij van de server krijgt.

Die is er toch pas als ik zowel een apparaat heb op het netwerk waar ik rechtstreeks op zit op bijvoorbeeld 192.168.1.2 EN als ik op dat exact zelfde IP binnen de VPN iets heb draaien. Maar stel ik wil 192.168.1.8 in m'n VPN bereiken en op het netwerk waar ik rechtstreeks op zit draait helemaal niks op 192.168.1.8 dan is er toch geen routingsprobleem?

That's not how any of this works. Of er dingen draaien of niet boeit niet, dat is hoe routering werkt. En de betekenis van een subnet is hier ook erg relevant.

Specifieker, voor iedere interface wordt het eigen IP-subnet op layer 2 addresseerbaar geacht. Je OS laat dat ook gewoon zien in de routetabel.

Als je goed kijkt in je (onhandige, want je had daar het probleem niet) route print zie je de on link route voor het lokale subnet ook staan:

145.37.40.0    255.255.252.0         On-link     145.37.41.215    296

Behalve dat dat elders 192.168.1.0 255.255.255.0 zal zijn, al dan niet met andere metric.

De VPN route is daarmee niet meer relevant (die OpenVPN zet als 0.0.0.0/1 en 128.0.0.0/1), want specifiekere routes gaan vòòr. En dat is precies wat hier je probleem is, want jouw 192.168.1.0/24 zit niet on-link maar achter 10.8.0.1.

Ik kreeg actieve "Connection refused" meldingen terug, en geen time-outs, dat lijkt me ook wezenlijk anders.

Je praat tegen de lokale 192.168.1.8 ipv. de 192.168.1.8 op je eigen netwerk, bij wijze van spreken.

Mijn VPN-server deelt IP-adressen uit op 10.8.0.X he. De vertaalslag naar de apparatuur in 192.168.X BINNEN het VPN doet de VPN-server zelf.

Maar daar komt het nooit aan.

De oplossing? In je OpenVPN config (zie: 'route') instellen dat hij een route voor 192.168.1.0/24 via 10.8.0.1 zet. Omdat je al een route hebt met die prefix moet de metric lager zijn.

'Maar het werkte eerst wel' - dat is als je het mij vraagt onmogelijk met de details die je tot dusver hebt gegeven, dus er mist waarschijnlijk een belangrijk detail. En anders zou de routetabel wel vertellen waarom het wel werkte.

[laurens0619]

Dit is volstrekt logisch gedrag. 2 netwerken in dezelfde ranges via vpn koppelen geeft routeringsconflicten op met onvoorspelbaar gedrag. Onvoorspelbaar gedrag is in de praktijk dat het meestal niet werkt, dat het bij jou eerst wel werkte is puur geluk. Ook al krijg je dat weer werkend, je weet nooit voor hoelang.

Grote bedrijven kopen hier public subnets voor op die ze als interne range gebruiken om dit probleem te voorkomen of gebruiken (dirty) nat. Als ik jou was zou ik gewoon in een exotische range thuis gaan zitten bv 192.168.63.x

Zie ook de openvpn documentatie
https://openvpn.net/index...tion/howto.html#numbering

[tomdabom]

MsG schreef op woensdag 19 september 2018 @ 16:55:
[...]


Waarom heeft het dan prima gewerkt en doet m'n mobiele telefoon het prima op m'n 192.168.X netwerk? Welk IP-conflict is er überhaupt? Die is er toch pas als ik zowel een apparaat heb op het netwerk waar ik rechtstreeks op zit op bijvoorbeeld 192.168.1.2 EN als ik op dat exact zelfde IP binnen de VPN iets heb draaien. Maar stel ik wil 192.168.1.8 in m'n VPN bereiken en op het netwerk waar ik rechtstreeks op zit draait helemaal niks op 192.168.1.8 dan is er toch geen routingsprobleem?

Ik kreeg actieve "Connection refused" meldingen terug, en geen time-outs, dat lijkt me ook wezenlijk anders. Dat gecombineerd met het feit dat mijn Android-toestel zonder morren en zonder instellingswijzigingen gewoon accepteert ben ik er niet van overtuigd dat het inherent niet zou kunnen werken.

Mijn VPN-server deelt IP-adressen uit op 10.8.0.X he. De vertaalslag naar de apparatuur in 192.168.X BINNEN het VPN doet de VPN-server zelf. En dat doet ie op mijn Android-telefoon blijkbaar prima, maar op m'n laptop (tenzij het nu dus opeens thuis werkt) niet goed.

Ik begrijp dat je gefrustreerd raakt, maar dit is nou eenmaal hoe routering werkt. Ik zou maar eens wat gaan google, dan begrijp je het probleem wat beter waarschijnlijk.

Voorbeeld: Hoe weet jouw computer welke netwerken er achter jouw VPN server zitten ? Dat weet ie niet aangezien er geen route gepusht wordt. Dit zie je ook in je routingtabel... en als het netwerk waar je op zit, dezelfde range als je eigen netwerk is, dan zal die in dat geval altijd de fysieke interface pakken...

En nog een kleine sidenote, wij hebben in onze productie omgeving 100+ point to point links en 400+ roadwarriors. Vertel me alsjeblieft niet hoe OpenVPN werkt.

[Voor 10% gewijzigd door tomdabom op 19-09-2018 20:37]

[JPS]

Met interesse lees ik dit topic, omdat ik ook niet altijd via VPN de webservices in mijn LAN kon bereiken en maar niet kon doorgronden waarom niet.

Als ik het goed begrijp is de vaak gebruikte IP range 192.168.1.x hier dus de oorzaak van, omdat die dan leeft aan twee kanten. Oplossing is dus om thuis een weinig gebruikte reeks te hanteren, zoals 192.168.yz.x

Komt mooi uit dat ik dit weet want ik heb net een nieuwe router besteld

[MsG]

Thralas schreef op woensdag 19 september 2018 @ 19:41:
De oplossing? In je OpenVPN config (zie: 'route') instellen dat hij een route voor 192.168.1.0/24 via 10.8.0.1 zet. Omdat je al een route hebt met die prefix moet de metric lager zijn.

Thanks voor je uitgebreide post. Wordt al ietsje duidelijker. Heb deze regel in de server-config gegooid:

push route "192.168.1.0 255.255.255.0 10.8.0.1 1"

maar dat lijkt nog niet te werken.


EDIT: die config stond er blijkbaar al in.

Dit is mn vrijwel stock config van OpenVPN:

push route "192.168.1.0 255.255.255.0 10.8.0.1 1"
dev tun
proto udp
port 1194
topology subnet
server 10.8.0.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
# Prevent DNS leaks on Windows
push "block-outside-dns"
#push route "192.168.1.0 255.255.255.0 10.8.0.1 1"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
client-to-client
keepalive 1800 3600
remote-cert-tls client
tls-version-min 1.2
tls-auth /etc/openvpn/easy-rsa/pki/ta.key 0
cipher AES-256-CBC
auth SHA256
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3
#DuplicateCNs allow access control on a less-granular, per user basis.
#Remove # if you will manage access by user instead of device.
#duplicate-cn
# Generated for use by PiVPN.io

[Voor 56% gewijzigd door MsG op 19-09-2018 23:38]

[tomdabom]

Kun je de log van je client nogmaals delen na de aanpassing op de server ? Hier kun je zien of de route correct wordt gepusht..

[Thralas]

En de routing table op de client.

[MsG]

tomdabom schreef op donderdag 20 september 2018 @ 07:29:
Kun je de log van je client nogmaals delen na de aanpassing op de server ? Hier kun je zien of de route correct wordt gepusht..

ct 01 15:23:51 2018 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Mon Oct 01 15:23:51 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Mon Oct 01 15:23:51 2018 library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
Enter Management Password:
Mon Oct 01 15:23:51 2018 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Mon Oct 01 15:23:51 2018 Need hold release from management interface, waiting...
Mon Oct 01 15:23:51 2018 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Mon Oct 01 15:23:51 2018 MANAGEMENT: CMD 'state on'
Mon Oct 01 15:23:51 2018 MANAGEMENT: CMD 'log all on'
Mon Oct 01 15:23:51 2018 MANAGEMENT: CMD 'echo all on'
Mon Oct 01 15:23:51 2018 MANAGEMENT: CMD 'bytecount 5'
Mon Oct 01 15:23:51 2018 MANAGEMENT: CMD 'hold off'
Mon Oct 01 15:23:51 2018 MANAGEMENT: CMD 'hold release'
Mon Oct 01 15:23:51 2018 MANAGEMENT: CMD 'password [...]'
Mon Oct 01 15:23:51 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Oct 01 15:23:51 2018 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Oct 01 15:23:51 2018 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Oct 01 15:23:51 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]HIERSTONDMNPUBLIEKIP:1194
Mon Oct 01 15:23:51 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Mon Oct 01 15:23:51 2018 UDP link local: (not bound)
Mon Oct 01 15:23:51 2018 UDP link remote: [AF_INET]HIERSTONDMNPUBLIEKIP:1194
Mon Oct 01 15:23:51 2018 MANAGEMENT: >STATE:1538400231,WAIT,,,,,,
Mon Oct 01 15:23:51 2018 MANAGEMENT: >STATE:1538400231,AUTH,,,,,,
Mon Oct 01 15:23:51 2018 TLS: Initial packet from [AF_INET]HIERSTONDMNPUBLIEKIP:1194, sid=94a7cc1a 6f933764
Mon Oct 01 15:23:51 2018 VERIFY OK: depth=1, CN=ChangeMe
Mon Oct 01 15:23:51 2018 VERIFY KU OK
Mon Oct 01 15:23:51 2018 Validating certificate extended key usage
Mon Oct 01 15:23:51 2018 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mon Oct 01 15:23:51 2018 VERIFY EKU OK
Mon Oct 01 15:23:51 2018 VERIFY X509NAME OK: CN=server_tNz5BnP8Q4ArDrEw
Mon Oct 01 15:23:51 2018 VERIFY OK: depth=0, CN=server_tNz5BnP8Q4ArDrEw
Mon Oct 01 15:23:52 2018 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Mon Oct 01 15:23:52 2018 [server_tNz5BnP8Q4ArDrEw] Peer Connection Initiated with [AF_INET]HIERSTONDMNPUBLIEKIP:1194
Mon Oct 01 15:23:53 2018 MANAGEMENT: >STATE:1538400233,GET_CONFIG,,,,,,
Mon Oct 01 15:23:53 2018 SENT CONTROL [server_tNz5BnP8Q4ArDrEw]: 'PUSH_REQUEST' (status=1)
Mon Oct 01 15:23:53 2018 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,block-outside-dns,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 1800,ping-restart 3600,ifconfig 10.8.0.3 255.255.255.0,peer-id 0,cipher AES-256-GCM'
Mon Oct 01 15:23:53 2018 OPTIONS IMPORT: timers and/or timeouts modified
Mon Oct 01 15:23:53 2018 OPTIONS IMPORT: --ifconfig/up options modified
Mon Oct 01 15:23:53 2018 OPTIONS IMPORT: route options modified
Mon Oct 01 15:23:53 2018 OPTIONS IMPORT: route-related options modified
Mon Oct 01 15:23:53 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Oct 01 15:23:53 2018 OPTIONS IMPORT: peer-id set
Mon Oct 01 15:23:53 2018 OPTIONS IMPORT: adjusting link_mtu to 1625
Mon Oct 01 15:23:53 2018 OPTIONS IMPORT: data channel crypto options modified
Mon Oct 01 15:23:53 2018 Data Channel: using negotiated cipher 'AES-256-GCM'
Mon Oct 01 15:23:53 2018 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Oct 01 15:23:53 2018 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Oct 01 15:23:53 2018 interactive service msg_channel=816
Mon Oct 01 15:23:53 2018 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 I=10 HWADDR=ac:fd:ce:27:8c:dd
Mon Oct 01 15:23:53 2018 open_tun
Mon Oct 01 15:23:53 2018 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{10742F46-6FE9-4899-9000-3D1939050760}.tap
Mon Oct 01 15:23:53 2018 TAP-Windows Driver Version 9.21 
Mon Oct 01 15:23:53 2018 Set TAP-Windows TUN subnet mode network/local/netmask = 10.8.0.0/10.8.0.3/255.255.255.0 [SUCCEEDED]
Mon Oct 01 15:23:53 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.3/255.255.255.0 on interface {10742F46-6FE9-4899-9000-3D1939050760} [DHCP-serv: 10.8.0.254, lease-time: 31536000]
Mon Oct 01 15:23:53 2018 Successful ARP Flush on interface [3] {10742F46-6FE9-4899-9000-3D1939050760}
Mon Oct 01 15:23:53 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Mon Oct 01 15:23:53 2018 MANAGEMENT: >STATE:1538400233,ASSIGN_IP,,10.8.0.3,,,,
Mon Oct 01 15:23:53 2018 Blocking outside dns using service succeeded.
Mon Oct 01 15:23:58 2018 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Mon Oct 01 15:23:58 2018 C:\WINDOWS\system32\route.exe ADD HIERSTONDMNPUBLIEKIP MASK 255.255.255.255 192.168.1.1
Mon Oct 01 15:23:58 2018 Route addition via service succeeded
Mon Oct 01 15:23:58 2018 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.1
Mon Oct 01 15:23:58 2018 Route addition via service succeeded
Mon Oct 01 15:23:58 2018 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.8.0.1
Mon Oct 01 15:23:58 2018 Route addition via service succeeded
Mon Oct 01 15:23:58 2018 Initialization Sequence Completed
Mon Oct 01 15:23:58 2018 MANAGEMENT: >STATE:1538400238,CONNECTED,SUCCESS,10.8.0.3,HIERSTONDMNPUBLIEKIP,1194,,

Ik had laatst de boel volledig overhoop en weer geïnstalleerd, serverside en cliëntside. Maar krijg het niet meer werkend op de manier zoals ik DACHT dat ik het eerder werkend had. Stel het was nooit werkend, hoe werkt dan jouw optie? Want die route lijkt wel degelijk te worden geset.

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1      192.168.1.8     50
          0.0.0.0        128.0.0.0         10.8.0.1         10.8.0.3    259
         10.8.0.0    255.255.255.0         On-link          10.8.0.3    259
         10.8.0.3  255.255.255.255         On-link          10.8.0.3    259
       10.8.0.255  255.255.255.255         On-link          10.8.0.3    259
     PUBLIEKIP  255.255.255.255      192.168.1.1      192.168.1.8    306
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
        128.0.0.0        128.0.0.0         10.8.0.1         10.8.0.3    259
      192.168.1.0    255.255.255.0         On-link       192.168.1.8    306
      192.168.1.8  255.255.255.255         On-link       192.168.1.8    306
    192.168.1.255  255.255.255.255         On-link       192.168.1.8    306
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link       192.168.1.8    306
        224.0.0.0        240.0.0.0         On-link          10.8.0.3    259
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link       192.168.1.8    306
  255.255.255.255  255.255.255.255         On-link          10.8.0.3    259
===========================================================================

EDIT: Verdomd, het lijkt nu wel deels te werken; lokale web-servers kan ik niet bereiken "connection refused" maar via SSH naar m'n thuisserver 192.168.1.4 werkt ineens wel. Die gaf voorheen ook altijd direct een "connection refused", sterker nog , zostraks werkte dat niet. Weird, deze halfwerkende staat :-P.

EDIT: De IP's die niet, op het netwerk waar ik direct op zit, bezet zijn lijken wel te werken. Daarmee zou het voor dit netwerk wellicht al opgelost zijn als ik de DHCP-lease range een stuk hoger zet.

EDIT: Verrek, nu ik de adres-uitdeling op het netwerk hier heb gezet vanaf 192.168.1.100+ en mijn VPN-adressen allemaal op 192.168.1.1-10 is er geen conflict meer. Dan klopt m'n gestelde verhaal hier: MsG in "OpenVPN cliënt verbonden maar kan niet bij apparaten" gewoon prima. Zolang er geen direct dezelfde IP's voorkomen weet de cliënt prima waar het moet wezen.

De methode is niet per se universeel toepasbaar, maar een volledig andere range voor mijn eigen netwerk is dan voor een eventuele lange termijn. Maar loop je dan niet altijd aan tegen het feit dat je dan toevallig op een gek netwerk terechtkomt waar je eigen VPN tóch weer overlapt met het netwerk waarop je zit? M.a.w. is er een universeel unieke range die 'veilig' is?

[Voor 6% gewijzigd door MsG op 01-10-2018 15:45]