No internet access when using Pritunl with Cloak (connected state)

Pritunl Pritunl VPN
1

Windows connects successfully via Cloak, macOS connects but has no internet

Client logs

2026-01-08 06:27:04 NOTE: debug verbosity (–verb 9) is enabled but this build lacks debug support.
2026-01-08 06:27:04 OpenVPN 2.6.12 arm-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH/RECVDA] [AEAD]
2026-01-08 06:27:04 library versions: OpenSSL 3.3.2 3 Sep 2024, LZO 2.10
2026-01-08 06:27:04 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2026-01-08 06:27:04 TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:1984
2026-01-08 06:27:04 Attempting to establish TCP connection with [AF_INET]127.0.0.1:1984
2026-01-08 06:27:04 TCP connection established with [AF_INET]127.0.0.1:1984
2026-01-08 06:27:04 TCPv4_CLIENT link local: (not bound)
2026-01-08 06:27:04 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:1984
2026-01-08 06:27:05 WARNING: this configuration may cache passwords in memory – use the auth-nocache option to prevent this
2026-01-08 06:27:06 VERIFY SCRIPT OK: depth=1, O=67a9cbc8d3593e01687fd95d, CN=67a9cbc8d3593e01687fd962
2026-01-08 06:27:06 NOTE: --mute triggered…
2026-01-08 06:27:06 8 variation(s) on previous 3 message(s) suppressed by --mute
2026-01-08 06:27:06 [67a9cbccd3593e01687fd980] Peer Connection Initiated with [AF_INET]127.0.0.1:1984
2026-01-08 06:27:06 Opened utun device utun4
2026-01-08 06:27:06 /sbin/ifconfig utun4 delete
ifconfig: ioctl (SIOCDIFADDR): Can’t assign requested address
2026-01-08 06:27:06 NOTE: Tried to delete pre-existing tun/tap instance – No Problem if failure
2026-01-08 06:27:06 /sbin/ifconfig utun4 192.168.245.9 192.168.245.9 netmask 255.255.255.0 mtu 1500 up
add net 192.168.245.0: gateway 192.168.245.9
2026-01-08 06:27:06 /tmp/pritunl/2a6bd1260e84eb40-block.sh utun4 1500 0 192.168.245.9 255.255.255.0 init
add net 127.0.0.1: gateway 192.168.0.1
add net 0.0.0.0: gateway 192.168.245.1
add net 128.0.0.0: gateway 192.168.245.1
dhcp-option DNS 1.1.1.1
dhcp-option DNS 8.8.8.8
2026-01-08 06:27:06 Initialization Sequence Completed
2026-01-08 06:27:06 Data Channel: cipher ‘AES-256-GCM’, peer-id: 0, compression: ‘stub’
2026-01-08 06:27:06 NOTE: --mute triggered…
2026-01-08 06:29:05 2 variation(s) on previous 3 message(s) suppressed by --mute
2026-01-08 06:29:05 event_wait : Interrupted system call (fd=-1,code=4)
2026-01-08 06:29:05 /tmp/pritunl/2a6bd1260e84eb40-down.sh utun4 1500 0 192.168.245.9 255.255.255.0 init
delete net 127.0.0.1: gateway 192.168.0.1
delete net 0.0.0.0: gateway 192.168.245.1
delete net 128.0.0.0: gateway 192.168.245.1
2026-01-08 06:29:09 Closing TUN/TAP interface
2026-01-08 06:29:09 /tmp/pritunl/2a6bd1260e84eb40-block.sh utun4 1500 0 192.168.245.9 255.255.255.0 init
2026-01-08 06:29:09 SIGINT[hard,] received, process exiting

Service logs

[2026-01-08 07:19:17][INFO] ▶ utils: Restore DNS
[2026-01-08 07:19:18][INFO] ▶ utils: Restore DNS
[2026-01-08 07:19:19][INFO] ▶ utils: Clearing DNS state
[2026-01-08 07:19:19][INFO] ▶ profile: Disconnected without restart ◆ client_disconnect=true ◆ client_disconnect_waiters=0 ◆ client_disconnected=true ◆ client_provider=true ◆ client_startime=125 ◆ data_iface=“” ◆ data_mode=“” ◆ data_remotes=string{“54.254.176.234:8443*”, “127.0.0.1”} ◆ data_status=“disconnected” ◆ data_timestamp=0 ◆ data_tun_iface=“” ◆ ovpn_auth_failed=false ◆ ovpn_cmd=true ◆ ovpn_connected=true ◆ ovpn_dir=“” ◆ ovpn_last_auth_failed=-1 ◆ ovpn_management_pass=false ◆ ovpn_management_port=0 ◆ ovpn_path=“/Applications/Pritunl.app/Contents/Resources/pritunl-openvpn” ◆ ovpn_remotes=string{“127.0.0.1(1984/tcp-client)”} ◆ ovpn_running=-1 ◆ ovpn_tap_iface=“” ◆ profile_device_auth=false ◆ profile_disable_dns=false ◆ profile_disable_gateway=false ◆ profile_dynamic_firewall=false ◆ profile_force_connect=false ◆ profile_force_dns=false ◆ profile_geo_sort=false ◆ profile_id=“2a6bd1260e84eb40” ◆ profile_mode=“ovpn” ◆ profile_reconnect=true ◆ profile_sso_auth=false ◆ profile_system_profile=false ◆ profile_timeout=false ◆ state_closed=true ◆ state_closed_waiters=0 ◆ state_deadline=false ◆ state_delay=false ◆ state_id=“f3775c497ee7f971” ◆ state_interactive=true ◆ state_no_reconnect=true ◆ state_stop=true ◆ state_system_interactive=false ◆ state_temp_paths=string{“/tmp/pritunl/2a6bd1260e84eb40”, “/tmp/pritunl/2a6bd1260e84eb40.auth”, “/tmp/pritunl/2a6bd1260e84eb40-block.sh”, “/tmp/pritunl/2a6bd1260e84eb40-up.sh”, “/tmp/pritunl/2a6bd1260e84eb40-down.sh”} ◆ state_time=time.Date(2026, time.January, 8, 7, 17, 13, 836192000, time.Local) ◆ wg_bash_path=“/Applications/Pritunl.app/Contents/Resources/bash” ◆ wg_conf_path=“” ◆ wg_conf_path2=“” ◆ wg_connected=false ◆ wg_last_handshake=0 ◆ wg_path=“/Applications/Pritunl.app/Contents/Resources/wg” ◆ wg_priv_key=false ◆ wg_pub_key=false ◆ wg_quick_path=“/Applications/Pritunl.app/Contents/Resources/wg-quick” ◆ wg_server_pub_key=false ◆ wg_sso_start=time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC) ◆ wg_sso_token=false ◆ wg_util_path=“”
[2026-01-08 07:19:22][INFO] ▶ utils: Restore DNS

2

If you are needing to do that it’s likely packet inspection that is blocking the connection. Packet inspection only inspects a fraction of packets to reduce the compute requirements then blocks the connection. So it’s normal to see it connect and have issues after some time connected. I don’t have any plans on adding features to avoid this. The focus of the software is on enterprise use cases not personal VPN use. Generally what will work is running the Pritunl server on one of the major cloud providers in a datacenter that is in the same region as the client. These connections are far less likely to get blocked as it’s more indicative of a corporate VPN connection.

Also try updating the OpenVPN package on the server as documented in the update OpenVPN documentation. There are some connection issues that can occur when the client is significantly newer OpenVPN version then the server.

3

Hi @zach ,

Thank you for the confirmation.

Yes, OpenVPN packages are updated already

4

Why it’s working in windows then @zach ?

5

I don’t know enough about that software to understand how to fix it. There is some general information in the client debugging documentation. Setting the Tunnel MTU to 1300 and switching to TCP could rule out any MTU issues.

6

We’re using TCP as of the moment