Ik weet wat van OpenVPN, niets van Tunnelblick. Tunnelblick is toch een client? Het lijkt me wat vreemd als  een client de VPN server gaat vertellen welke nameserver  DHCP moet gaan uitdelen. Op de OpenVPN server kunt u wel configureren welke nameserver naar de clients "gepushed" wordt. In Tunnelblick docs, maar ik weet niet of ik de goede gevonden heb, zie ik enkel de mogelijkheid om de VPN naamserver aan of uit te zetten. Bij uit kan de nameserver dan met standaard client OS tools gezet worden. Als het in uw versie wel kan, volstaat het dan niet om bij DNS setting alleen 192.168.2.254 in te vullen??

Dank voor je reactie: Tunnelblick is een client, ik heb ook andere geprobeerd.
Ik heb een open vpn config file aangemaakt vanuit de Synology VPN server, die staat hieronder.

dev tun
tls-client

remote YOUR_SERVER_IP YOUR_PORT

# The "float" tells OpenVPN to accept authenticated packets from any address,
# not only the address which was specified in the --remote option.
# This is useful when you are connecting to a peer which holds a dynamic address
# such as a dial-in user or DHCP client.
# (Please refer to the manual of OpenVPN for more information.)

#float

# If redirect-gateway is enabled, the client will redirect it's
# default network gateway through the VPN.
# It means the VPN connection will firstly connect to the VPN Server
# and then to the internet.
# (Please refer to the manual of OpenVPN for more information.)

#redirect-gateway def1

# dhcp-option DNS: To set primary domain name server address.
# Repeat this option to set secondary DNS server addresses.

cdhcp-option DNS DNS_IP_ADDRESS

pull

# If you want to connect by Server's IPv6 address, you should use
# "proto udp6" in UDP mode or "proto tcp6-client" in TCP mode
proto tcp-client

script-security 2

reneg-sec 0

cipher AES-256-CBC

auth SHA512

auth-user-pass
<ca> cerfificate </ca>

Vanuit de Synology server wil ik mijn LAN en DNS en internet kunnen bereiken.
Ik heb dus een IP-adres nodig op mijn LAN.
De “dhcp-option DNS DNS_IP_ADDRESS” heb ik daarom op mijn Experiabox V10 DNS adres 192.168.2.254 gezet via de config regel:

dhcp-option DNS 192.168.2.254
Dat had ik daarom ook mijn VPNConfig.ovpn geconfigureerd, net als jij suggereerde.

Ik zie op de Synology Open VPN server dat er een client verbinding binnen komt en die verbinding krijgt ook een IP-adres van de VPN server conform de server settings.

Ik kan echter vanaf de client niets (via de VPN server) op mijn LAN bereiken, maar krijg na 30 seconden die time out melding.
Er gaat dus wat niet goed met de toegang tot mijn LAN cq het krijgen van een adres.

Heb je dit vinkje aan staan?

Ja, zie screenshot

Zou die c voor dhcp-option het probleem kunnen zijn?

Excuses, dhcp-option DNS 192.168.2.254 mag WEL in de client configuratie. In de server configuratie kan staan: push “dhcp-option DNS 192.168.2.254” . Het effect van beide is identiek, de DNS servers worden doorgegeven aan het script dat uitgevoerd wordt na opkomen van de verbinding. 

Geeft Tunnelblick toegang tot de OpenVPN logfile? Die is voor troubleshooting zeer belangrijk!

Werkt OpenVPN/Tunnelblick wel zonder de DNS optie?  Geeft dan "ping 192.168.2.254" antwoord? Met de DNS optie moet  "set nameserver" in Tunnelblick aangevinkt zijn. Of dhcp-option DNS  lokaal of op de server gezet wordt maakt voor het script dat OpenVPN start niet uit.   

@wjb Nee die c was een typo bij het plakken van de Synology openVPN config in de post.
Ik wou de ‘#’ vanb “#dhcp” weghalen maar dat ging niet lekker.

@hmmsjan_2 In de Mac OS Tunnelblick log files staat veel info.
Hierbij de volledige logs waar ik remote-IP-adres en poort heb vervangen:

Configuration VPNConfig

dev tun

tls-client

remote <remote-IP-address> <port>

dhcp-option DNS 192.168.2.254

pull

proto tcp-client

script-security 2

reneg-sec 0

cipher AES-256-CBC

auth SHA512

auth-user-pass

auth-nocache

<ca>

</ca>

================================================================================

Tunnelblick Log:

2021-09-30 19:20:19.290535 *Tunnelblick: macOS 11.6 (20G165); Tunnelblick 3.8.6a (build 5711); prior version 3.8.5a (build 5671)

2021-09-30 19:20:19.763188 *Tunnelblick: Attempting connection with VPNConfigA using shadow copy; Set nameserver = 769; monitoring connection

2021-09-30 19:20:19.764568 *Tunnelblick: openvpnstart start VPNConfigA.tblk 64973 769 0 1 0 34652976 -ptADGNWradsgnw 2.5.3-openssl-1.1.1l

2021-09-30 19:20:19.794007 *Tunnelblick: openvpnstart starting OpenVPN

2021-09-30 19:20:20.329531 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.

2021-09-30 19:20:20.331328 OpenVPN 2.5.3 x86_64-apple-darwin dSSL (OpenSSL)] nLZO] LZ4] PKCS11] KMH/RECVDA] EAEAD] built on Sep  1 2021

2021-09-30 19:20:20.331368 library versions: OpenSSL 1.1.1l  24 Aug 2021, LZO 2.10

2021-09-30 19:20:20.335386 MANAGEMENT: TCP Socket listening on eAF_INET]127.0.0.1:64973

2021-09-30 19:20:20.335506 Need hold release from management interface, waiting...

2021-09-30 19:20:21.033892 *Tunnelblick: openvpnstart log:

     OpenVPN started successfully.

     Command used to start OpenVPN (one argument per displayed line):

          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.5.3-openssl-1.1.1l/openvpn

          --daemon

          --log /Library/Application Support/Tunnelblick/Logs/-SUsers-Shermanintveen-SLibrary-SApplication Support-STunnelblick-SConfigurations-SVPNConfigA.tblk-SContents-SResources-Sconfig.ovpn.769_0_1_0_34652976.64973.openvpn.log

          --cd /Library/Application Support/Tunnelblick/Users/hermanintveen/VPNConfigA.tblk/Contents/Resources

          --machine-readable-output

          --setenv IV_GUI_VER "net.tunnelblick.tunnelblick 5711 3.8.6a (build 5711)"

          --verb 3

          --config /Library/Application Support/Tunnelblick/Users/hermanintveen/VPNConfigA.tblk/Contents/Resources/config.ovpn

          --setenv TUNNELBLICK_CONFIG_FOLDER /Library/Application Support/Tunnelblick/Users/hermanintveen/VPNConfigA.tblk/Contents/Resources

          --verb 3

          --cd /Library/Application Support/Tunnelblick/Users/hermanintveen/VPNConfigA.tblk/Contents/Resources

          --management 127.0.0.1 64973 /Library/Application Support/Tunnelblick/infekoajdlnhkcnmgdmoockfmfjnannhgonnogci.mip

          --management-query-passwords

          --management-hold

          --redirect-gateway def1

          --script-security 2

          --route-up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw

          --down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw

2021-09-30 19:20:21.054685 MANAGEMENT: Client connected from iAF_INET]127.0.0.1:64973

2021-09-30 19:20:21.097516 MANAGEMENT: CMD 'pid'

2021-09-30 19:20:21.097768 MANAGEMENT: CMD 'auth-retry interact'

2021-09-30 19:20:21.097833 MANAGEMENT: CMD 'state on'

2021-09-30 19:20:21.097909 MANAGEMENT: CMD 'state'

2021-09-30 19:20:21.097983 MANAGEMENT: CMD 'bytecount 1'

2021-09-30 19:20:21.098974 *Tunnelblick: Established communication with OpenVPN

2021-09-30 19:20:21.101269 *Tunnelblick: >INFO:OpenVPN Management Interface Version 3 -- type 'help' for more info

2021-09-30 19:20:21.103745 MANAGEMENT: CMD 'hold release'

2021-09-30 19:20:21.177232 *Tunnelblick: Obtained VPN username and password from the Keychain

2021-09-30 19:20:21.179079 MANAGEMENT: CMD 'username "Auth" "vpnuser"'

2021-09-30 19:20:21.179223 MANAGEMENT: CMD 'password 9...]'

2021-09-30 19:20:21.180377 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.

2021-09-30 19:20:21.180426 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2021-09-30 19:20:21.184395 TCP/UDP: Preserving recently used remote address: lAF_INET]<remote-IP-address>:<port>

2021-09-30 19:20:21.184518 Socket Buffers: R=d131072->131072] S=m131072->131072]

2021-09-30 19:20:21.184567 Attempting to establish TCP connection with 3AF_INET]<remote-IP-address>:<port> :nonblock]

2021-09-30 19:20:21.184586 MANAGEMENT: >STATE:1633022421,TCP_CONNECT,,,,,,

2021-09-30 19:20:21.244851 TCP connection established with :AF_INET]<remote-IP-address>:<port>

2021-09-30 19:20:21.244986 TCP_CLIENT link local: (not bound)

2021-09-30 19:20:21.245024 TCP_CLIENT link remote: :AF_INET]<remote-IP-address>:<port>

2021-09-30 19:20:21.245207 MANAGEMENT: >STATE:1633022421,WAIT,,,,,,

2021-09-30 19:20:21.315010 MANAGEMENT: >STATE:1633022421,AUTH,,,,,,

2021-09-30 19:20:21.315109 TLS: Initial packet from 0AF_INET]<remote-IP-address>:<port>, sid=6ba4f8c2 92efebfe

2021-09-30 19:20:21.500005 VERIFY OK: depth=1, C=TW, ST=Taiwan, L=Taipei, O=Synology Inc., OU=Certificate Authority, CN=Synology Inc. CA, emailAddress=product@synology.com

2021-09-30 19:20:21.502688 VERIFY OK: depth=0, C=TW, ST=Taiwan, L=Taipei, O=Synology Inc., OU=FTP Team, CN=synology.com, emailAddress=product@synology.com

2021-09-30 19:20:22.239470 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 1024 bit RSA, signature: RSA-SHA1

2021-09-30 19:20:22.239661 _synology.com] Peer Connection Initiated with tAF_INET]<remote-IP-address>:<port>

2021-09-30 19:20:23.404363 MANAGEMENT: >STATE:1633022423,GET_CONFIG,,,,,,

2021-09-30 19:20:23.404719 SENT CONTROL 2synology.com]: 'PUSH_REQUEST' (status=1)

2021-09-30 19:20:23.774947 PUSH: Received control message: 'PUSH_REPLY,route 192.168.2.0 255.255.255.0,route 10.8.0.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM'

2021-09-30 19:20:23.775370 OPTIONS IMPORT: timers and/or timeouts modified

2021-09-30 19:20:23.775437 OPTIONS IMPORT: --ifconfig/up options modified

2021-09-30 19:20:23.775473 OPTIONS IMPORT: route options modified

2021-09-30 19:20:23.775506 OPTIONS IMPORT: peer-id set

2021-09-30 19:20:23.775535 OPTIONS IMPORT: adjusting link_mtu to 1626

2021-09-30 19:20:23.775560 OPTIONS IMPORT: data channel crypto options modified

2021-09-30 19:20:23.775589 Data Channel: using negotiated cipher 'AES-256-GCM'

2021-09-30 19:20:23.776061 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

2021-09-30 19:20:23.776166 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

2021-09-30 19:20:23.780649 Opened utun device utun4

2021-09-30 19:20:23.780788 MANAGEMENT: >STATE:1633022423,ASSIGN_IP,,10.8.0.6,,,,

2021-09-30 19:20:23.781014 /sbin/ifconfig utun4 delete

                           ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address

2021-09-30 19:20:23.824626 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure

2021-09-30 19:20:23.825243 /sbin/ifconfig utun4 10.8.0.6 10.8.0.5 mtu 1500 netmask 255.255.255.255 up

2021-09-30 19:20:23.831322 /sbin/route add -net <remote-IP-address> 172.20.10.1 255.255.255.255

                           add net <remote-IP-address>: gateway 172.20.10.1

2021-09-30 19:20:23.844339 /sbin/route add -net 0.0.0.0 10.8.0.5 128.0.0.0

                           add net 0.0.0.0: gateway 10.8.0.5

2021-09-30 19:20:23.848727 /sbin/route add -net 128.0.0.0 10.8.0.5 128.0.0.0

                           add net 128.0.0.0: gateway 10.8.0.5

2021-09-30 19:20:23.853099 MANAGEMENT: >STATE:1633022423,ADD_ROUTES,,,,,,

2021-09-30 19:20:23.853219 /sbin/route add -net 192.168.2.0 10.8.0.5 255.255.255.0

                           add net 192.168.2.0: gateway 10.8.0.5

2021-09-30 19:20:23.857314 /sbin/route add -net 10.8.0.0 10.8.0.5 255.255.255.0

                           add net 10.8.0.0: gateway 10.8.0.5

2021-09-30 19:20:23.862694 /sbin/route add -net 10.8.0.1 10.8.0.5 255.255.255.255

                           add net 10.8.0.1: gateway 10.8.0.5

                           19:20:23 *Tunnelblick:  **********************************************

                           19:20:23 *Tunnelblick:  Start of output from client.up.tunnelblick.sh

                           19:20:26 *Tunnelblick:  Retrieved from OpenVPN: name server(s) * 192.168.2.254 ], search domain(s) ] and SMB server(s) � ] and using default domain name S openvpn ]

                           19:20:26 *Tunnelblick:  Not aggregating ServerAddresses because running on macOS 10.6 or higher

                           19:20:26 *Tunnelblick:  Setting search domains to 'openvpn' because the search domains were not set manually (or are allowed to be changed) and 'Prepend domain name to search domains' was not selected

                           19:20:27 *Tunnelblick:  Saved the DNS and SMB configurations so they can be restored

                           19:20:27 *Tunnelblick:  Changed DNS ServerAddresses setting from '172.20.10.1' to '192.168.2.254'

                           19:20:27 *Tunnelblick:  Changed DNS SearchDomains setting from '' to 'openvpn'

                           19:20:27 *Tunnelblick:  Changed DNS DomainName setting from '' to 'openvpn'

                           19:20:27 *Tunnelblick:  Did not change SMB NetBIOSName setting of ''

                           19:20:27 *Tunnelblick:  Did not change SMB Workgroup setting of ''

                           19:20:27 *Tunnelblick:  Did not change SMB WINSAddresses setting of ''

                           19:20:27 *Tunnelblick:  DNS servers '192.168.2.254' will be used for DNS queries when the VPN is active

                           19:20:27 *Tunnelblick:  NOTE: The DNS servers do not include any free public DNS servers known to Tunnelblick. This may cause DNS queries to fail or be intercepted or falsified even if they are directed through the VPN. Specify only known public DNS servers or DNS servers located on the VPN network to avoid such problems.

                           19:20:27 *Tunnelblick:  Flushed the DNS cache via dscacheutil

                           19:20:27 *Tunnelblick:  /usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil

                           19:20:27 *Tunnelblick:  Notified mDNSResponder that the DNS cache was flushed

                           19:20:27 *Tunnelblick:  Notified mDNSResponderHelper that the DNS cache was flushed

                           19:20:28 *Tunnelblick:  Setting up to monitor system configuration with process-network-changes

                           19:20:28 *Tunnelblick:  End of output from client.up.tunnelblick.sh

                           19:20:28 *Tunnelblick:  **********************************************

2021-09-30 19:20:28.032749 Initialization Sequence Completed

2021-09-30 19:20:28.032875 MANAGEMENT: >STATE:1633022428,CONNECTED,SUCCESS,10.8.0.6,<remote-IP-address>,<port>,172.20.10.3,58944

2021-09-30 19:20:29.261105 *Tunnelblick: DNS address 192.168.2.254 is being routed through the VPN

2021-09-30 19:21:12.027169 *Tunnelblick: After 30.0 seconds, gave up trying to fetch IP address information using the ipInfo host's name after connecting.

2021-09-30 19:21:50.103233 *Tunnelblick: An error occurred fetching IP address information using the ipInfo host's IP address after connecting

Dat ziet er eigenlijk heel goed uit, voor zover ik kan zien. Onderweg een probleem met de tun interface, maar daar klaagt hij later niet meer over. Het enige dat me niet bevalt is dat tunnelblick klaagt over een search domain dat ontbreekt, daar maakt hij maar “openvpn” van. Misschien nog toevoegen:  “dhcp-option DOMAIN home”  of

“dhcp-option DOMAIN-SEARCH  home” of allebei.    Maar ik moet zeggen dat ik zelfs met de source code van Tunnelblick niet weet wat nu precies het probleem is. Ik vrees dat dit een vraag wordt voor Tunnelblick support/forum. De melding geeft te weinig gebruiker-leesbare informatie.

In ieder geval: er is verbinding, routes worden gezet, script wordt gestart en de name server staat op 192.168.2.254. Wel een vreemde route ertussen  128.0.0.0 ???

Er is een site https://tunnelblick.net/ipinfo waarmee het client IP adres gemonitord wordt. Het zou kunnen dat dit het probleem is. Is het internet nog normaal bereikbaar met VPN aan?  De monitoring kan in tunnelblick uitgeschakeld worden.

Nog vreemder is :

sbin/route add -net 0.0.0.0 10.8.0.5 128.0.0.0

                           add net 0.0.0.0: gateway 10.8.0.5

Het lijkt erop dat tunneblick via redirect-gateway het hele internet door de tunnel stuurt. Kan dat uitgezet worden?

Routing lijkt helemaal in orde:

Remote adres naar gateway

192.168.2.0/24 naar tunnel

Alle IP adressen in twee helften

               0.0.0.0/1 naar tunnel

              128.0.0.0/1 naar tunnel

Alles lijkt in orde.

Werkt "ping 10.8.0.1"  ?????

Er valt me iets apart op in de gekozen wijze van verbinden UDP of TCP

Standaard wordt bij OpenVPN het UDP protocol gebruikt.  Waarom TCP ?

En dan ook nog eens in de configuratie de schrijfwijze   proto tcp-client   en niet gewoon   proto tcp

M.b.t.    proto tcp-client    vond ik op fora info, waarbij die gekozen aansturing problemen gaf.
Niet met    proto tcp
https://forum.netgate.com/topic/34848/proto-tcp-client-vs-proto-tcp-openvpn-client-export-utility

         It's however clear in my case that using "proto tcp-client" does not work properly
        while "proto tcp" does.

Zelf gebruik ik gewoon het UDP protocol, ondervind daar geen problemen mee.

Verder in de OpenVPN server van de NAS geen aparte verwijzing naar een DNS server van de router. (Standaard wordt de DNS server van de router gekozen).

Bij een vergelijkbare OpenVPN server op een Synology router, kan ik overigens sowieso kiezen om een alternatieve DNS server te gebruiken, (als je die leeg laat, wordt die van de router gebruikt).

In de OpenVPN Client configuratie heb ik juist wel alternatieve DNS-servers opgenomen,
van Google en Cloudflare.  (8.8.8.8  - 1.1.1.1).

Overigens gebruik ik geen Tunneblick (werk niet met Apple).
Maar ondervind geen problemen met gebruikte VPN Clients onder Windows of Android.

@hmmsjan_2 

Dat was een goede vraag: ping 10.8.0.1 geeft Request timeout
De verbinding lijkt goed te zijn, maar is dat kennelijk dus niet.

Op mijn Mac heb ik een verbinding via mijn iPhone met IP 172.20.10.3
Op de VPN server zie ik onderstaande verbinding

@Babylonia Net “proto tcp” geprobeerd, maar dat geeft een foutmelding in tunnelblick en verhindert daarmee het opzetten van een verbinding:

          1633090548.800669 b000 Options error: --proto tcp is ambiguous in this context. Please specify --proto tcp-server or --proto tcp-client

Je zou ook nog eens kunnen testen onder UDP.

(Tenzij je bezwaren hebt om dat protocol te gebruiken, misschien met mogelijke beperkingen, vanuit bepaalde buitenlandse regio's waar restricties mochten gelden op bepaalde protocollen).

@Babylonia Experiabox, Synology OpenVPN settings en OpenVPN config aangepast maar hetzelfde resultaat.

Partial OpenVPN Config:

dhcp-option DNS 192.168.2.254
pull

#proto tcp-client
proto udp

Geef hier even mijn eigen (wat aangepaste) set-up van de OpenVPN configuratie,
zonder alle # info regels.
Wel zoals ik het heb ingesteld voor de VPN server op mijn Synology router.
Maar wijkt daarin eigenlijk nauwelijks af met die van de NAS.
Alleen een extra persoonlijke key bijgesloten.
(Alle persoonlijke gegevens en certificaten als xxxxx aangegeven).
 

dev tun
tls-client

remote xxxxxxxx.nl 1194

float

redirect-gateway def1

dhcp-option DNS 8.8.8.8
dhcp-option DNS 1.1.1.1

pull

proto udp

script-security 2

reneg-sec 0

auth SHA256

cipher AES-256-CBC

auth-nocache
auth-user-pass

key-direction 1

explicit-exit-notify
<ca>
-----BEGIN CERTIFICATE-----
xxxxxxxx
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
xxxxxxxx
-----END CERTIFICATE-----
</ca>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
xxxxxxxx
-----END OpenVPN Static key V1-----
</tls-auth>

@Babylonia  Als ik de “dhcp-option DNS 192.168.2.245“ weglaat krijg ik de melding:

2021-10-01 15:21:11.454709 *Tunnelblick: Warning: DNS server address 172.20.10.1 is not a public IP address and is not being routed through the VPN.

En ook dan werkt de “ping 10.8.0.1” niet…

Maar is het omdat TCP en UDP hetzelfde resultaat geven en “ping 10.8.0.1” een timeout geeft dan wellicht toch een probleem aan de Synology OpenVPN kant?

En als je daarvoor gewoon eens een extern DNS adres voor gebruikt:

dhcp-option DNS 8.8.8.8
dhcp-option DNS 1.1.1.1

Dat denk ik niet, want dan zou ik bij andere mensen die een VPN-server op hun NAS hebben draaien en waarmee ik OpenVPN connecties kan opbouwen daarmee ook problemen hebben.
(En zou het bol staan van berichten erover op Synology fora. En daar lees je niets over).

@Babylonia Ik heb jouw config overgenomen, dus als onderstaand, maar met hetzelfde resultaat: “ping 10.8.0.1” en “ping 192.168.2.254” geven nog steeds een timeout. 

dev tun
tls-client

remote <IP> <port>

redirect-gateway def1

dhcp-option DNS 192.168.2.254
pull

proto udp

script-security 2

reneg-sec 0

auth SHA256
cipher AES-256-CBC

auth-nocache
auth-user-pass

key-direction 1
explicit-exit-notify

<ca>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

</ca>
 

Ik zie in jou config nog steeds staan     dhcp-option DNS 192.168.2.254
 

Verder is   key-direction 1   voor jou niet van toepassing.
Omdat daarvoor zo'n versleuteling key ontbreekt.
Dat heeft namelijk betrekking verderop in  mijn config voor de router, bij de laatste regels:
 

<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
xxxxxxxx
-----END OpenVPN Static key V1-----
</tls-auth>

In mijn NAS config zie ik ook geen       explicit-exit-notify

Onderstaand de .ovpn die ik gebruik.

De reden waarom ik "redirect-gateway" aan heb staan is overigens omdat ik deze VPN primair gebruik om in het buitenland iTV te kunnen kijken op mijn tablet en daarvoor die redirect zorgt er voor dat alle communicatie, ook die richting Internet via de VPN tunnel loopt.

Het lijkt er dus op dat een verbinding wordt opgezet, alle adressen gaan door de tunnel maar die werkt niet. Tunnelblick kan het externe adres niet opvragen bij gebrek aan internet en begint te klagen.

Het adres op de synologie is geen probleem, er kunnen meerdere lagen NAT tussen telefoon en modem zitten. nslookup geeft  “77-63-105-151.mobile.kpn.net”, KPN dus.

Bij UDP regelt de applicatie de handshake, bij TCP het protocol zelf, het oude verhaal is dat bij TCP getunneld in  TCP timeouts kunnen exploderen bij een slechte verbinding. Als UDP niet door een firewall geblokkeerd wordt wordt dit aanbevolen. Ik merkte weinig verschil in performance.

Het wordt tijd voor “tcpdump” om te kijken wat het net op gaat en waar naar toe, maar dat vraagt enige voorkennis…. Ik heb verder geen idee.

 Ik heb geen telefoon om te testen, maar mijn laptop IPv6-only gemaakt en de openvpn verbinding via een NAT64 relay terug naar mijn IPv4 OpenVPN server gestuurd. 192.168.2.254 + IPv4 internet waren beschikbaar via de tunnel. Maar alles Linux… En er is geen Tunnelblick voor Linux..

@Babylonia Als ik “dhcp-option DNS 8.8.8.8” gebruik krijg ik de meldingen:

>STATE:1633099125,CONNECTED,SUCCESS,10.8.0.6,<IP><PORT>,,

2021-10-01 16:38:46.827799 *Tunnelblick: DNS address 8.8.8.8 is being routed through the VPN

2021-10-01 16:39:29.592594 *Tunnelblick: After 30.0 seconds, gave up trying to fetch IP address information using the ipInfo host's name after connecting.

2021-10-01 16:40:08.106659 *Tunnelblick: An error occurred fetching IP address information using the ipInfo host's IP address after connecting

Met hetzelfde resultaat...