RMS Quick connection only works when using it the first time

fdimmel · September 17, 2025, 8:02am

Hi,

We have a RUTX09 and several devices connected behind. I would like to access one device when not on the same network.

To do so, I went in the RMS admin to the RUTX09 → Network → selected the device I want to access → VPN Quick Connect → Location Germany and created the VPN Hub.

As I’m using a Mac I downloaded Teltonika RMS VPN app and logged in. My hub shows up and after starting it, I connected. This created a new VPN connection in my Mac VPN settings.

It took a minute or so but then I could access the device remotely. Great.

fritz@Fritz-MBP-M1-2 ~ % ping 192.168.100.213
PING 192.168.100.213 (192.168.100.213): 56 data bytes
64 bytes from 192.168.100.213: icmp_seq=0 ttl=63 time=47.124 ms
64 bytes from 192.168.100.213: icmp_seq=1 ttl=63 time=43.176 ms
64 bytes from 192.168.100.213: icmp_seq=2 ttl=63 time=48.609 ms

Then I disconnected. After reconnecting, I am not able to access the device anymore. Also after stopping/starting the Hub and connecting, it just does not work anymore. I can’t ping the device, nothing.

fritz@Fritz-MBP-M1-2 ~ % ping 192.168.100.213
PING 192.168.100.213 (192.168.100.213): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2

Is this a known issue? How can I make the Hub / VPN connection to work whenever I connect to it?

Thanks

Fritz

anon65719490 · September 17, 2025, 8:33am

Hello,

Could you please confirm whether you have more than one RMS VPN hub created? If so, you should keep only a single active hub (delete the unused one).

Additionally, would it be possible for you to provide the logs from the RUTX09 client side as well as from your Mac when the VPN connection drops out or fails to re-establish?

Furthermore, does the issue reproduce when using an RMS VPN hub instead of Quick Connect?

Best regards,

fdimmel · September 17, 2025, 8:56am

Hi @anon65719490, thanks for your reply.

In fact I have created a VPN hub (but not in use as I could not get it working). That’s when I found out the “Quick connection” hubs.

I have now deleted an old instance of the same hub, so only one hub for this device is left.

I started it and connected, ping works now.

Then I disconnect using the Teltonika RMS VPN app and then I reconnect → also works now.

Now I disable the Hub, re-enable it and connect → stopped working.

Disconnect, reconnect → not working

So, it’s somehow reproducable but still odd.

Regarding log files: where would I be able to obtain these?

On the Mac: The VPN connection can be established and it also does not drop. It just does not allow me to connect to the desired device.

My suspicion is that the routes are not set correctly but I don’t know how and where I could verify this.

Any ideas?

Thanks

anon65719490 · September 17, 2025, 9:12am

Hello @fdimmel,

For testing purposes, could you please try enabling masquerading on the LAN → WAN firewall zone?

For collecting/checking logs, the RUT VPN logs can be found under Services → VPN → OpenVPN page, Logs row.

Additionally, can you confirm whether this issue can also be reproduced when using RMS VPN Hubs?

Best regards,

fdimmel · September 17, 2025, 9:36am

Hi,

I have attached the logs here: 15684 Wed Sep 17 10:56:52 2025 daemon.notice openvpn(zL0ws5fb)[27117]: [teltonik - Pastebin.com (I cannot upload, because I’m a “new user”… :-/ )

There are a lot of “route” errors, confirming my suspicion.

The latest connection attempt started at ~11:31 (quite at the bottom of the log)

Thanks

fdimmel · September 18, 2025, 5:49am

@anon65719490 did you have a chance to look at the logs?

Thanks

anon65719490 · September 18, 2025, 6:12am

Hello,

From the shared logs, your suspicion might be correct, the routes are being removed after packet loss, which is accompanied by TLS errors. This leads to missed keepalive pings, causing the session to drop.

Just to confirm, have you had a chance to enable masquerading on the LAN firewall zone?

In addition, you may try increasing the tolerance on the client side by adding the following options to the client’s configuration file:

ping 10
ping-restart 60

This should make the session more resilient to temporary packet loss.

If the issue still persists after these changes, would it be possible for you to test the connectivity behavior using the RMS VPN Hub only and compare the results?

Best regards,

fdimmel · September 18, 2025, 6:16am

Hi,

2 questions:

changing masquerading - could this cause any issues? As the device is remote and if I mess it up it will be hard to reset?
I could not find the settings for masquerading. Could you please point me to where this is?

Regarding the ping/settings you mentioned: where would I put this? The connection is managed by the Teltonika RMS VPN app.

I will also give the full RPM VPN Hub a try today and share my results.

Thanks

fdimmel · September 18, 2025, 8:11am

Hi, we found out that we can use the OVPN file and imported it to Tunnelblick (VPN software for Mac). Here we also could change the ping settings you suggested. However, as previously: sometimes it works, sometimes it doesn’t.

I have setup now a full RMS VPN Hub, but we fail to connect at all. Here’s the log file of Tunnelblick:

2025-09-18 10:04:39.231448 *Tunnelblick: macOS 15.6.1 (24G90); Tunnelblick 8.0 (build 6300); prior version 6.0.1 (build 6161)
2025-09-18 10:04:40.321886 *Tunnelblick: Attempting connection with fritz@REDACTED using shadow copy; Set nameserver = 0x00000301; monitoring connection
2025-09-18 10:04:40.322234 *Tunnelblick: openvpnstart start fritz@REDACTED.tblk 50096 0x00000301 0 1 0 0x0210c130 -ptADGNWradsgnw 2.6.14-openssl-3.0.16 <password>
2025-09-18 10:04:40.427356 *Tunnelblick: openvpnstart starting OpenVPN
2025-09-18 10:04:40.799941 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2025-09-18 10:04:40.800073 OpenVPN 2.6.14 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD]
2025-09-18 10:04:40.800084 library versions: OpenSSL 3.0.16 11 Feb 2025, LZO 2.10
2025-09-18 10:04:40.803270 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:50096
2025-09-18 10:04:40.803291 Need hold release from management interface, waiting...
2025-09-18 10:04:41.586859 *Tunnelblick: openvpnstart log:
     OpenVPN started successfully.
     Command used to start OpenVPN (one argument per displayed line):
          /Library/Application Support/Tunnelblick/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.6.14-openssl-3.0.16/openvpn
          --daemon
          --log-append /Library/Application Support/Tunnelblick/Logs/-SUsers-Sfritz-SLibrary-SApplication Support-STunnelblick-SConfigurations-Sfritz@REDACTED.tblk-SContents-SResources-Sconfig.ovpn.769_0_1_0_34652464.50096.openvpn.log
          --cd /Library/Application Support/Tunnelblick/Users/fritz/fritz@REDACTED.tblk/Contents/Resources
          --machine-readable-output
          --setenv IV_GUI_VER "net.tunnelblick.tunnelblick 6300 8.0 (build 6300)"
          --verb 3
          --config /Library/Application Support/Tunnelblick/Users/fritz/fritz@REDACTED.tblk/Contents/Resources/config.ovpn
          --setenv TUNNELBLICK_CONFIG_FOLDER /Library/Application Support/Tunnelblick/Users/fritz/fritz@REDACTED.tblk/Contents/Resources
          --verb 3
          --cd /Library/Application Support/Tunnelblick/Users/fritz/fritz@REDACTED.tblk/Contents/Resources
          --management 127.0.0.1 50096 /Library/Application Support/Tunnelblick/Mips/fritz@REDACTED.tblk.mip
          --setenv IV_SSO webauth,crtext
          --management-query-passwords
          --management-hold
          --script-security 2
          --route-up "/Library/Application Support/Tunnelblick/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh" -9 -d -f -m -w -ptADGNWradsgnw
          --down "/Library/Application Support/Tunnelblick/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh" -9 -d -f -m -w -ptADGNWradsgnw
2025-09-18 10:04:41.592992 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:50862
2025-09-18 10:04:41.618918 MANAGEMENT: CMD 'pid'
2025-09-18 10:04:41.619062 MANAGEMENT: CMD 'auth-retry interact'
2025-09-18 10:04:41.620416 MANAGEMENT: CMD 'state on'
2025-09-18 10:04:41.620614 MANAGEMENT: CMD 'state'
2025-09-18 10:04:41.620935 MANAGEMENT: CMD 'bytecount 1'
2025-09-18 10:04:41.624201 *Tunnelblick: Established communication with OpenVPN
2025-09-18 10:04:41.630916 *Tunnelblick: >INFO:OpenVPN Management Interface Version 5 -- type 'help' for more info
2025-09-18 10:04:41.632245 MANAGEMENT: CMD 'hold release'
2025-09-18 10:04:41.632783 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2025-09-18 10:04:41.637707 TCP/UDP: Preserving recently used remote address: [AF_INET]3.69.106.81:40566
2025-09-18 10:04:41.637851 Socket Buffers: R=[786896->786896] S=[9216->9216]
2025-09-18 10:04:41.637872 UDPv4 link local: (not bound)
2025-09-18 10:04:41.637888 UDPv4 link remote: [AF_INET]3.69.106.81:40566
2025-09-18 10:04:41.637973 MANAGEMENT: >STATE:1758182681,WAIT,,,,,,

After some time it tries to reconnect and is able to connect:

2025-09-18 10:05:41.567848 [UNDEF] Inactivity timeout (--ping-restart), restarting
2025-09-18 10:05:41.568307 SIGUSR1[soft,ping-restart] received, process restarting
2025-09-18 10:05:41.568332 MANAGEMENT: >STATE:1758182741,RECONNECTING,ping-restart,,,,,
2025-09-18 10:05:41.570419 *Tunnelblick: Delaying HOLD release for 1.000 seconds
2025-09-18 10:05:42.571453 MANAGEMENT: CMD 'hold release'
2025-09-18 10:05:42.571689 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2025-09-18 10:05:42.577722 TCP/UDP: Preserving recently used remote address: [AF_INET]3.65.167.143:40566
2025-09-18 10:05:42.577903 Socket Buffers: R=[786896->786896] S=[9216->9216]
2025-09-18 10:05:42.577945 UDPv4 link local: (not bound)
2025-09-18 10:05:42.578020 UDPv4 link remote: [AF_INET]3.65.167.143:40566
2025-09-18 10:05:42.578144 MANAGEMENT: >STATE:1758182742,WAIT,,,,,,
2025-09-18 10:05:42.596912 MANAGEMENT: >STATE:1758182742,AUTH,,,,,,
2025-09-18 10:05:42.597129 TLS: Initial packet from [AF_INET]3.65.167.143:40566, sid=1f677e33 65301d64
2025-09-18 10:05:42.621078 VERIFY OK: depth=1, C=LT, ST=Kaunas, L=Kaunas, O=Teltonika Networks, CN=RMS_VPN
2025-09-18 10:05:42.623454 VERIFY KU OK
2025-09-18 10:05:42.623541 Validating certificate extended key usage
2025-09-18 10:05:42.623569 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2025-09-18 10:05:42.623594 VERIFY EKU OK
2025-09-18 10:05:42.623619 VERIFY OK: depth=0, C=LT, ST=Vilnius, L=Vilnius, O=Teltonika, CN=teltonika-vpn-zd58rUJlUA0bE3zz
2025-09-18 10:05:42.659209 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
2025-09-18 10:05:42.659404 [teltonika-vpn-zd58rUJlUA0bE3zz] Peer Connection Initiated with [AF_INET]3.65.167.143:40566
2025-09-18 10:05:42.659479 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2025-09-18 10:05:42.659608 TLS: tls_multi_process: initial untrusted session promoted to trusted
2025-09-18 10:05:42.681359 PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,route 192.168.100.213 255.255.255.255,route 192.168.255.0 255.255.255.0,topology net30,ping 5,ping-restart 15,ifconfig 192.168.255.10 192.168.255.9,peer-id 1,cipher AES-256-GCM'
2025-09-18 10:05:42.681630 OPTIONS IMPORT: --ifconfig/up options modified
2025-09-18 10:05:42.681660 OPTIONS IMPORT: route options modified
2025-09-18 10:05:42.683037 Opened utun device utun4
2025-09-18 10:05:42.683092 MANAGEMENT: >STATE:1758182742,ASSIGN_IP,,192.168.255.10,,,,
2025-09-18 10:05:42.683138 /sbin/ifconfig utun4 delete
                           ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2025-09-18 10:05:42.733233 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2025-09-18 10:05:42.733267 /sbin/ifconfig utun4 192.168.255.10 192.168.255.9 mtu 1500 netmask 255.255.255.255 up
2025-09-18 10:05:42.761385 MANAGEMENT: >STATE:1758182742,ADD_ROUTES,,,,,,
2025-09-18 10:05:42.761613 /sbin/route add -net 192.168.100.213 192.168.255.9 255.255.255.255
                           add net 192.168.100.213: gateway 192.168.255.9
2025-09-18 10:05:42.778912 /sbin/route add -net 192.168.255.0 192.168.255.9 255.255.255.0
                           add net 192.168.255.0: gateway 192.168.255.9
                           10:05:42 *Tunnelblick:  **********************************************
                           10:05:42 *Tunnelblick:  Start of output from client.up.tunnelblick.sh
                           10:05:42 *Tunnelblick:  Primary network service: Wi-Fi
                           10:05:46 *Tunnelblick:  Disabled IPv6 for 'USB-C Dock Ethernet'
                           10:05:46 *Tunnelblick:  Disabled IPv6 for 'USB-C Dock Ethernet 2'
                           10:05:46 *Tunnelblick:  Disabled IPv6 for 'USB 10/100/1000 LAN'
                           10:05:46 *Tunnelblick:  Disabled IPv6 for 'USB 10/100/1000 LAN 2'
                           10:05:46 *Tunnelblick:  Disabled IPv6 for 'USB 10/100/1000 LAN 3'
                           10:05:46 *Tunnelblick:  Disabled IPv6 for 'Mac USB-C ETH Adapter'
                           10:05:46 *Tunnelblick:  Disabled IPv6 for 'USB 10/100/1000 LAN 5'
                           10:05:46 *Tunnelblick:  Disabled IPv6 for 'USB 10/100/1000 LAN 4'
                           10:05:46 *Tunnelblick:  Disabled IPv6 for 'USB 10/100/1000 LAN 6'
                           10:05:46 *Tunnelblick:  Disabled IPv6 for 'USB 10/100 LAN'
                           10:05:46 *Tunnelblick:  Disabled IPv6 for 'AX88179A'
                           10:05:46 *Tunnelblick:  Disabled IPv6 for 'Wi-Fi'
                           10:05:46 *Tunnelblick:  Disabled IPv6 for 'Thunderbolt Bridge'
                           10:05:47 *Tunnelblick:  No changes to DNS servers have been requested
                           10:05:47 *Tunnelblick:  DNS servers '192.168.0.1' will be used for DNS queries when the VPN is active
                           10:05:47 *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.
                           10:05:47 *Tunnelblick:  Will not monitor for network configuration changes.
                           10:05:47 *Tunnelblick:  Have written State:/Network/OpenVPN for no DNS changes and to inhibit network monitoring
                           10:05:47 *Tunnelblick:  Flushed the DNS cache via dscacheutil
                           10:05:47 *Tunnelblick:  /usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil
                           10:05:47 *Tunnelblick:  Notified mDNSResponder that the DNS cache was flushed
                           10:05:47 *Tunnelblick:  Not notifying mDNSResponderHelper that the DNS cache was flushed because it is not running
                           10:05:47 *Tunnelblick:  End of output from client.up.tunnelblick.sh
                           10:05:47 *Tunnelblick:  **********************************************
2025-09-18 10:05:47.135640 Initialization Sequence Completed
2025-09-18 10:05:47.135656 MANAGEMENT: >STATE:1758182747,CONNECTED,SUCCESS,192.168.255.10,3.65.167.143,40566,,
2025-09-18 10:05:47.135663 Data Channel: cipher 'AES-256-GCM', peer-id: 1, compression: 'stub'
2025-09-18 10:05:47.135668 Timers: ping 5, ping-restart 15
2025-09-18 10:05:48.255774 *Tunnelblick: Warning: Empty expected DNS address. It is likely that no DNS address was pushed by the VPN server.
2025-09-18 10:05:48.365432 *Tunnelblick: Routing info stdout:
   route to: 192.168.0.1
destination: 192.168.0.1
  interface: en0
      flags: <UP,HOST,DONE,LLINFO,WASCLONED,IFSCOPE,IFREF,ROUTER>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500      1198 
stderr:

2025-09-18 10:05:48.378419 *Tunnelblick: Warning: DNS server address 192.168.0.1 is not a public IP address and is not being routed through the VPN.


2025-09-18 10:05:53.845026 *Tunnelblick: This computer's apparent public IP address (212.183.52.124) was unchanged after the connection was made

However, ping does not work.

I don’t understand what is happening. Any more ideas?

Thanks

anon65719490 · September 18, 2025, 8:28am

Hello,

Thank you for providing additional details.

The masquerading option can be found under Network → Firewall → Zones. You would enable it on the LAN → WAN zone. Enabling this shouldn’t cause any issues.

Just to confirm: is the VPN hub tunnel type set to TUN, not TAP? Also, could you verify that the routes on the Mac side have been added correctly using netstat -rn, and that the target device appears in the router’s ARP table with arp -a?

Best regards,

fdimmel · September 23, 2025, 6:07am

Hi,

it’s working now, but I don’t know what exactly was the reason in the end.

However: If I connect, initially the connection does not work (see the log files in my previous post). It’s stuck in the step:

2025-09-18 10:04:41.637872 UDPv4 link local: (not bound)
2025-09-18 10:04:41.637888 UDPv4 link remote: [AF_INET]3.69.106.81:40566
2025-09-18 10:04:41.637973 MANAGEMENT: >STATE:1758182681,WAIT,,,,,,

Exactly 1 minute later, a retry happens and then the connection / authentication steps pass and my client is able to connect. Routes are working (at least now and reproducable).

Thanks for your support, I don’t know what exactly helped, but at least we got it working (with the VPN hub now).

Best regards,

Fritz

anon65719490 · September 23, 2025, 6:19am

Hello Fritz,

Thank you for the update, and I’m glad I could assist you with this matter. My guess is that enabling LAN masquerading may have contributed to improving the situation, though it’s difficult to say for certain. If the issue happens again, please feel free to leave a comment here or create a new topic.

Have a great day.

Best regards,

fdimmel · September 23, 2025, 7:21am

Hi @anon65719490 ,

one more thing came up: I have now created a 2nd hub for another router (we need them to be managed separately). All the settings are the same. However, after the 1min waiting on connect, I get now a TLS handshare error message:

2025-09-23 09:17:21.168346 UDPv4 link local: (not bound)
2025-09-23 09:17:21.168361 UDPv4 link remote: [AF_INET]3.69.106.81:40829
2025-09-23 09:17:21.168416 MANAGEMENT: >STATE:1758611841,WAIT,,,,,,
2025-09-23 09:18:21.827997 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2025-09-23 09:18:21.828238 TLS Error: TLS handshake failed
2025-09-23 09:18:21.829916 SIGUSR1[soft,tls-error] received, process restarting
2025-09-23 09:18:21.830035 MANAGEMENT: >STATE:1758611901,RECONNECTING,tls-error,,,,,
2025-09-23 09:18:21.836069 *Tunnelblick: Delaying HOLD release for 1.000 seconds
2025-09-23 09:18:22.838708 MANAGEMENT: CMD 'hold release'
2025-09-23 09:18:22.838855 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2025-09-23 09:18:22.844193 TCP/UDP: Preserving recently used remote address: [AF_INET]3.65.167.143:40829
2025-09-23 09:18:22.844314 Socket Buffers: R=[786896->786896] S=[9216->9216]
2025-09-23 09:18:22.844376 UDPv4 link local: (not bound)
2025-09-23 09:18:22.844414 UDPv4 link remote: [AF_INET]3.65.167.143:40829
2025-09-23 09:18:22.844514 MANAGEMENT: >STATE:1758611902,WAIT,,,,,,

Where might this come from?

I have restarted the VPN hub already, no success.

Thanks

anon65719490 · September 23, 2025, 7:48am

Hello,

Could you confirm whether this router is not connected to both hubs simultaneously? Also, does changing the hub’s location and updating the client certificates make any difference? Just to mention, make sure the hub type is set to TUN.

It would also be helpful if you could provide some additional logs from the client of this VPN hub. After regenerating the certificates, please try restarting the hub as well. If the issue still persists, could you share full configuration screenshots of this VPN hub?

Best regards,

fdimmel · September 23, 2025, 8:01am

Hi,

after the TLS error, and after waiting a bit more (few seconds to a minute), it is able to connect.

The Router is only in this VPN hub.

Attaching the full logs from the client, you can see, at first it waits a minute, then on 2nd attempt I get the TLS handshake error, but then, after a few seconds, it connects.

2025-09-23 09:56:02.107982 *Tunnelblick: macOS 15.6.1 (24G90); Tunnelblick 8.0 (build 6300); prior version 6.0.1 (build 6161)
2025-09-23 09:56:02.577841 *Tunnelblick: Attempting connection with fritz@REDACTED using shadow copy; Set nameserver = 0x00000301; monitoring connection
2025-09-23 09:56:02.578841 *Tunnelblick: openvpnstart start fritz@REDACTED.tblk 61927 0x00000301 0 1 0 0x0210c130 -ptADGNWradsgnw 2.6.14-openssl-3.0.16 <password>
2025-09-23 09:56:02.621294 *Tunnelblick: openvpnstart starting OpenVPN
2025-09-23 09:56:02.916717 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2025-09-23 09:56:02.916822 OpenVPN 2.6.14 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD]
2025-09-23 09:56:02.916832 library versions: OpenSSL 3.0.16 11 Feb 2025, LZO 2.10
2025-09-23 09:56:02.917345 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:61927
2025-09-23 09:56:02.917355 Need hold release from management interface, waiting...
2025-09-23 09:56:03.203704 *Tunnelblick: openvpnstart log:
     OpenVPN started successfully.
     Command used to start OpenVPN (one argument per displayed line):
          /Library/Application Support/Tunnelblick/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.6.14-openssl-3.0.16/openvpn
          --daemon
          --log-append /Library/Application Support/Tunnelblick/Logs/-SUsers-Sfritz-SLibrary-SApplication Support-STunnelblick-SConfigurations-Sfritz@REDACTED--REDACTED.tblk-SContents-SResources-Sconfig.ovpn.769_0_1_0_34652464.61927.openvpn.log
          --cd /Library/Application Support/Tunnelblick/Users/fritz/fritz@REDACTED.tblk/Contents/Resources
          --machine-readable-output
          --setenv IV_GUI_VER "net.tunnelblick.tunnelblick 6300 8.0 (build 6300)"
          --verb 3
          --config /Library/Application Support/Tunnelblick/Users/fritz/fritz@REDACTED.tblk/Contents/Resources/config.ovpn
          --setenv TUNNELBLICK_CONFIG_FOLDER /Library/Application Support/Tunnelblick/Users/fritz/fritz@REDACTED.tblk/Contents/Resources
          --verb 3
          --cd /Library/Application Support/Tunnelblick/Users/fritz/fritz@REDACTED.tblk/Contents/Resources
          --management 127.0.0.1 61927 /Library/Application Support/Tunnelblick/Mips/fritz@REDACTED.tblk.mip
          --setenv IV_SSO webauth,crtext
          --management-query-passwords
          --management-hold
          --script-security 2
          --route-up "/Library/Application Support/Tunnelblick/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh" -9 -d -f -m -w -ptADGNWradsgnw
          --down "/Library/Application Support/Tunnelblick/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh" -9 -d -f -m -w -ptADGNWradsgnw
2025-09-23 09:56:03.218899 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:61620
2025-09-23 09:56:03.258772 MANAGEMENT: CMD 'pid'
2025-09-23 09:56:03.258868 MANAGEMENT: CMD 'auth-retry interact'
2025-09-23 09:56:03.258913 MANAGEMENT: CMD 'state on'
2025-09-23 09:56:03.258951 MANAGEMENT: CMD 'state'
2025-09-23 09:56:03.259023 MANAGEMENT: CMD 'bytecount 1'
2025-09-23 09:56:03.259382 *Tunnelblick: Established communication with OpenVPN
2025-09-23 09:56:03.270371 *Tunnelblick: >INFO:OpenVPN Management Interface Version 5 -- type 'help' for more info
2025-09-23 09:56:03.271443 MANAGEMENT: CMD 'hold release'
2025-09-23 09:56:03.272360 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2025-09-23 09:56:03.279839 TCP/UDP: Preserving recently used remote address: [AF_INET]3.69.106.81:40829
2025-09-23 09:56:03.279977 Socket Buffers: R=[786896->786896] S=[9216->9216]
2025-09-23 09:56:03.280004 UDPv4 link local: (not bound)
2025-09-23 09:56:03.280028 UDPv4 link remote: [AF_INET]3.69.106.81:40829
2025-09-23 09:56:03.280094 MANAGEMENT: >STATE:1758614163,WAIT,,,,,,
2025-09-23 09:57:03.533496 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2025-09-23 09:57:03.533705 TLS Error: TLS handshake failed
2025-09-23 09:57:03.534698 SIGUSR1[soft,tls-error] received, process restarting
2025-09-23 09:57:03.534740 MANAGEMENT: >STATE:1758614223,RECONNECTING,tls-error,,,,,
2025-09-23 09:57:03.843065 *Tunnelblick: Delaying HOLD release for 1.000 seconds
2025-09-23 09:57:04.845814 MANAGEMENT: CMD 'hold release'
2025-09-23 09:57:04.846173 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2025-09-23 09:57:04.850806 TCP/UDP: Preserving recently used remote address: [AF_INET]3.65.167.143:40829
2025-09-23 09:57:04.851322 Socket Buffers: R=[786896->786896] S=[9216->9216]
2025-09-23 09:57:04.851358 UDPv4 link local: (not bound)
2025-09-23 09:57:04.851387 UDPv4 link remote: [AF_INET]3.65.167.143:40829
2025-09-23 09:57:04.851469 MANAGEMENT: >STATE:1758614224,WAIT,,,,,,
2025-09-23 09:57:04.872319 MANAGEMENT: >STATE:1758614224,AUTH,,,,,,
2025-09-23 09:57:04.872627 TLS: Initial packet from [AF_INET]3.65.167.143:40829, sid=f7a5bdac 2141767c
2025-09-23 09:57:04.901311 VERIFY OK: depth=1, C=LT, ST=Kaunas, L=Kaunas, O=Teltonika Networks, CN=RMS_VPN
2025-09-23 09:57:04.902435 VERIFY KU OK
2025-09-23 09:57:04.902462 Validating certificate extended key usage
2025-09-23 09:57:04.902483 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2025-09-23 09:57:04.902500 VERIFY EKU OK
2025-09-23 09:57:04.902516 VERIFY OK: depth=0, C=LT, ST=Vilnius, L=Vilnius, O=Teltonika, CN=teltonika-vpn-8Wy1uZa7ehoH9A1Y
2025-09-23 09:57:04.936709 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
2025-09-23 09:57:04.936929 [teltonika-vpn-8Wy1uZa7ehoH9A1Y] Peer Connection Initiated with [AF_INET]3.65.167.143:40829
2025-09-23 09:57:04.936988 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2025-09-23 09:57:04.937114 TLS: tls_multi_process: initial untrusted session promoted to trusted
2025-09-23 09:57:04.958211 PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,route 192.168.0.233 255.255.255.255,route 192.168.255.0 255.255.255.0,topology net30,ping 5,ping-restart 15,ifconfig 192.168.255.6 192.168.255.5,peer-id 0,cipher AES-256-GCM'
2025-09-23 09:57:04.958503 OPTIONS IMPORT: --ifconfig/up options modified
2025-09-23 09:57:04.958536 OPTIONS IMPORT: route options modified
2025-09-23 09:57:04.961992 Opened utun device utun8
2025-09-23 09:57:04.962169 MANAGEMENT: >STATE:1758614224,ASSIGN_IP,,192.168.255.6,,,,
2025-09-23 09:57:04.962299 /sbin/ifconfig utun8 delete
                           ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2025-09-23 09:57:05.015763 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2025-09-23 09:57:05.015899 /sbin/ifconfig utun8 192.168.255.6 192.168.255.5 mtu 1500 netmask 255.255.255.255 up
2025-09-23 09:57:05.038453 MANAGEMENT: >STATE:1758614225,ADD_ROUTES,,,,,,
2025-09-23 09:57:05.038782 /sbin/route add -net 192.168.0.233 192.168.255.5 255.255.255.255
                           add net 192.168.0.233: gateway 192.168.255.5
2025-09-23 09:57:05.085588 /sbin/route add -net 192.168.255.0 192.168.255.5 255.255.255.0
                           add net 192.168.255.0: gateway 192.168.255.5
                           09:57:05 *Tunnelblick:  **********************************************
                           09:57:05 *Tunnelblick:  Start of output from client.up.tunnelblick.sh
                           09:57:05 *Tunnelblick:  Primary network service: Wi-Fi
                           09:57:09 *Tunnelblick:  Disabled IPv6 for 'USB-C Dock Ethernet'
                           09:57:09 *Tunnelblick:  Disabled IPv6 for 'USB-C Dock Ethernet 2'
                           09:57:09 *Tunnelblick:  Disabled IPv6 for 'USB 10/100/1000 LAN'
                           09:57:09 *Tunnelblick:  Disabled IPv6 for 'USB 10/100/1000 LAN 2'
                           09:57:09 *Tunnelblick:  Disabled IPv6 for 'USB 10/100/1000 LAN 3'
                           09:57:09 *Tunnelblick:  Disabled IPv6 for 'Mac USB-C ETH Adapter'
                           09:57:09 *Tunnelblick:  Disabled IPv6 for 'USB 10/100/1000 LAN 5'
                           09:57:09 *Tunnelblick:  Disabled IPv6 for 'USB 10/100/1000 LAN 4'
                           09:57:09 *Tunnelblick:  Disabled IPv6 for 'USB 10/100/1000 LAN 6'
                           09:57:09 *Tunnelblick:  Disabled IPv6 for 'USB 10/100 LAN'
                           09:57:09 *Tunnelblick:  Disabled IPv6 for 'AX88179A'
                           09:57:09 *Tunnelblick:  Disabled IPv6 for 'Wi-Fi'
                           09:57:09 *Tunnelblick:  Disabled IPv6 for 'Thunderbolt Bridge'
                           09:57:09 *Tunnelblick:  No changes to DNS servers have been requested
                           09:57:09 *Tunnelblick:  DNS servers '192.168.0.1' will be used for DNS queries when the VPN is active
                           09:57:09 *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.
                           09:57:09 *Tunnelblick:  Will not monitor for network configuration changes.
                           09:57:09 *Tunnelblick:  Have written State:/Network/OpenVPN for no DNS changes and to inhibit network monitoring
                           09:57:09 *Tunnelblick:  Flushed the DNS cache via dscacheutil
                           09:57:09 *Tunnelblick:  /usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil
                           09:57:09 *Tunnelblick:  Notified mDNSResponder that the DNS cache was flushed
                           09:57:09 *Tunnelblick:  Not notifying mDNSResponderHelper that the DNS cache was flushed because it is not running
                           09:57:09 *Tunnelblick:  End of output from client.up.tunnelblick.sh
                           09:57:09 *Tunnelblick:  **********************************************
2025-09-23 09:57:09.627546 Initialization Sequence Completed
2025-09-23 09:57:09.627565 MANAGEMENT: >STATE:1758614229,CONNECTED,SUCCESS,192.168.255.6,3.65.167.143,40829,,
2025-09-23 09:57:09.627572 Data Channel: cipher 'AES-256-GCM', peer-id: 0, compression: 'stub'
2025-09-23 09:57:09.627575 Timers: ping 5, ping-restart 15
2025-09-23 09:57:10.743692 *Tunnelblick: Warning: Empty expected DNS address. It is likely that no DNS address was pushed by the VPN server.
2025-09-23 09:57:10.860613 *Tunnelblick: Routing info stdout:
   route to: 192.168.0.1
destination: 192.168.0.1
  interface: en0
      flags: <UP,HOST,DONE,LLINFO,WASCLONED,IFSCOPE,IFREF,ROUTER>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500      1179 
stderr:

2025-09-23 09:57:10.870298 *Tunnelblick: Warning: DNS server address 192.168.0.1 is not a public IP address and is not being routed through the VPN.

Very strange…

Thanks

anon65719490 · September 23, 2025, 8:38am

From the provided logs, the connection sequence now looks successful, the TLS handshake completes, certificates are validated, an IP is assigned, routes are pushed, and the initialization sequence finishes with the tunnel marked as CONNECTED.

Could you please monitor the tunnel connection for a longer period and let me know if it stays stable over time or any further issues arise?

Best regards,

system · September 25, 2025, 8:39pm

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.