OpenVPN connected but no traffic goes thorough

[houmie75]

I have made great progress in setting up OpenVPN from scratch, however after a seemingly successful connection, no traffic seems to get thorough.
When I try to search for 'what is my ip address' the browser simply hangs until timeout. Maybe it's a DNS issue.

I have followed the conversation here viewtopic.php?t=22103 and have even stopped iptables altogether to be sure. But still no joy.

net.ipv4.ip_forward = 1 is already set.

OpenVPN.log (server)

Code: Select all

MULTI: multi_create_instance called
91.xx.xxx.xxx:64348 Re-using SSL/TLS context
91.xx.xxx.xxx:64348 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1450)
91.xx.xxx.xxx:64348 Control Channel MTU parms [ L:1571 D:1156 EF:94 EB:0 ET:0 EL:3 ]
91.xx.xxx.xxx:64348 Data Channel MTU parms [ L:1571 D:1450 EF:121 EB:397 ET:0 EL:3 ]
91.xx.xxx.xxx:64348 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1499,tun-mtu 1450,proto UDPv4,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-server'
91.xx.xxx.xxx:64348 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1499,tun-mtu 1450,proto UDPv4,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client'
91.xx.xxx.xxx:64348 TLS: Initial packet from [AF_INET]91.xx.xxx.xxx:64348, sid=842d054a 98c791dc
91.xx.xxx.xxx:64348 VERIFY OK: depth=1, CN=T CA
91.xx.xxx.xxx:64348 VERIFY OK: depth=0, CN=client1
91.xx.xxx.xxx:64348 peer info: IV_VER=3.git::3e56f9a6
91.xx.xxx.xxx:64348 peer info: IV_PLAT=ios
91.xx.xxx.xxx:64348 peer info: IV_NCP=2
91.xx.xxx.xxx:64348 peer info: IV_TCPNL=1
91.xx.xxx.xxx:64348 peer info: IV_PROTO=2
91.xx.xxx.xxx:64348 peer info: IV_AUTO_SESS=1
91.xx.xxx.xxx:64348 peer info: IV_GUI_VER=net.openvpn.connect.ios_3.2.0-3253
91.xx.xxx.xxx:64348 peer info: IV_SSO=openurl
91.xx.xxx.xxx:64348 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1499', remote='link-mtu 1471'
91.xx.xxx.xxx:64348 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 384 bit EC, curve: secp384r1
91.xx.xxx.xxx:64348 [client1] Peer Connection Initiated with [AF_INET]91.xx.xxx.xxx:64348
client1/91.xx.xxx.xxx:64348 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
client1/91.xx.xxx.xxx:64348 MULTI: Learn: 10.8.0.6 -> client1/91.xx.xxx.xxx:64348
client1/91.xx.xxx.xxx:64348 MULTI: primary virtual IP for client1/91.xx.xxx.xxx:64348: 10.8.0.6
client1/91.xx.xxx.xxx:64348 PUSH: Received control message: 'PUSH_REQUEST'
client1/91.xx.xxx.xxx:64348 SENT CONTROL [client1]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 1.0.0.1,dhcp-option DNS 1.1.1.1,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM' (status=1)
client1/91.xx.xxx.xxx:64348 Data Channel MTU parms [ L:1499 D:1450 EF:49 EB:397 ET:0 EL:3 ]
client1/91.xx.xxx.xxx:64348 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
client1/91.xx.xxx.xxx:64348 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

View OriginalServer config

port 1510
tun-mtu 1450
proto udp4
dev tun
ca ca.crt
cert server.crt
key server.key
dh none
user nobody
group nogroup
push "redirect-gateway def1 bypass-dhcp"
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.0.0.1"
push "dhcp-option DNS 1.1.1.1"
duplicate-cn
keepalive 10 120
tls-crypt ta.key
cipher AES-256-GCM
auth SHA256
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
log-append /var/log/openvpn/openvpn.log
verb 4
explicit-exit-notify 1

View OriginalClient config

client
tun-mtu 1450
dev tun
proto udp4
remote o4.xxxx.net 1510
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
mute-replay-warnings
cipher AES-256-GCM
auth SHA256
key-direction 1
verb 4
<ca>
</ca>
<cert>
</cert>
<key>
</key>
<tls-crypt>
</tls-crypt>

What could I be missing please?

[TinCanTech]

even stopped iptables altogether to be sure. But still no joy

You need iptables to do Masquerading, just like the thread and howto you linked to show..

[houmie75]

Hello my friend,

It's a fair point. I just have applied these rules as shown here https://arashmilani.com/post?id=53, but still no joy.

Code: Select all

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            state NEW udp dpt:1510
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

I even went beyond and added these four lines to my client1.ovpn

Code: Select all

script-security 2
up /etc/openvpn/scripts/update-systemd-resolved
up-restart
down /etc/openvpn/scripts/update-systemd-resolved
down-pre

Compiled and configured:

Code: Select all

git clone https://github.com/jonathanio/update-systemd-resolved.git
cd update-systemd-resolved
make
systemctl enable systemd-resolved.service
systemctl start systemd-resolved.service
sed -i 's/hosts:          files dns/hosts: files resolve dns myhostname/' /etc/nsswitch.conf

But still the DNS doesn't resolve.

[TinCanTech]

Please read the official Howto:
https://community.openvpn.net/openvpn/w ... oughtheVPN

[houmie75]

Thanks for the pointer. It's well explained. And yes, I have already added:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

push "redirect-gateway def1 bypass-dhcp"

And for DNS I'm now using Google:
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

By the way I'm testing via Mac and iPhone. (No Windows Client) Because it says:

(or non-Windows clients with some extra server-side scripting)

Do I need extra settings on Server for non-windows clients? Nothing further is mentioned there.

Full list of iptables commands that I ran:

Code: Select all

iptables -A INPUT -i eth0 -m state --state NEW -p udp --dport 1510 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Resulted in:

Code: Select all

# Generated by iptables-save v1.8.4 on Sun Aug  2 16:19:45 2020
*nat
:PREROUTING ACCEPT [803:49190]
:INPUT ACCEPT [282:15663]
:OUTPUT ACCEPT [16:1562]
:POSTROUTING ACCEPT [16:1562]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Sun Aug  2 16:19:45 2020
# Generated by iptables-save v1.8.4 on Sun Aug  2 16:19:45 2020
*filter
:INPUT ACCEPT [4716:771608]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6185:5006848]
-A INPUT -i eth0 -p udp -m state --state NEW -m udp --dport 1510 -j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Sun Aug  2 16:19:45 2020

[TinCanTech]

I have already added:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

This is the only iptables rule you require.

Once you have it working you can add what-ever other rules you see fit.

non-Windows clients with some extra server-side scripting

Non-Windows, eg. Linux require a script to pickup pushed DNS.

Which you already have with update-systemd-resolved.

You can test that the redirection works by simply pinging 8.8.8.8 etc (No DNS is required).
Once that works you can fix up your DNS.

[Pippin]

You're going left and right.
It's not perfect but stick to the official howto.
It's better then some random tut on the net...

Tips, add

Code: Select all

topology subnet

to the server config.

Change

Code: Select all

push "redirect-gateway def1 bypass-dhcp"

in

Code: Select all

push "redirect-gateway def1"

Flush your rules (they did nothing anyway ) and only add

Code: Select all

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Keep

Code: Select all

net.ipv4.ip_forward = 1

Restart the server.

Check

Code: Select all

iptables -t nat -vnL

and

Code: Select all

cat /proc/sys/net/ipv4/ip_forward
1

Connect the client.

Can you ping 10.8.0.1?
Can you ping 9.9.9.9?
Can you ping quad9.com?

[houmie75]

Hey Pippin,

Thank you for the additional tips. I have applied your adjustments and I'm getting mixed results.

First thing first, I have to say that I'm currently traveling in the Middle East. I'm currently in Iran. Some websites here like Facebook, Youtube etc are blocked. This forum here is also blocked by the way. The only reason I can access it is due to my IKEv2 vpn server.

On the other hand, my IKEv2 server is currently blocked in United Arab Emirates (but not Iran), so I would like to get to understand OpenVPN better and have a fall back server in place. Hence I'm not very experienced with OpenVPN. And sadly I'm really struggling with it.

With my OpenVPN connection up and running I can ping 10.8.0.1, 9.9.9.9 and quad9.com. But most websites don't open at all, and some only open after a few minutes waiting. My OpenVpn setup is extremely slow. I don't understood it, performance shouldn't be that much different than IKEv2.

I don't expect any major DPI happening in Iran, since those only come into effect when there is a political crisis to be dealt with. So how comes I have these problems? Is it interference or rather config error? I can't say.

Btw I have compiled OpenVPN 2.4.9 with XOR patch (https://github.com/clayface/openvpn_xorpatch) to hide it better.
But I had the same connectivity issues with plain OpenVPN 2.4.7 that comes with Ubuntu 20.04.

Not quite sure what to do next....

Many Thanks,

[TinCanTech]

Not quite sure what to do next....

Try angristan or Nyr openvpn-install scripts, they do most of the work for you.

Btw I have compiled OpenVPN 2.4.9 with XOR patch

This may not help much .. it is still very easy for an adversary to block you, if they want to..

[houmie75]

Try angristan or Nyr openvpn-install scripts, they do most of the work for you.

Thank you, that was actually very useful.

I installed Nyr once on default settings and installed Agristan four times with different settings.

None of them works. They all struggle to resolve URLs.

This is either something with the ISP, where they block OpenVPN partially. Or there is something I have missed.

The same author has also written a WireGuard repo https://github.com/angristan/wireguard-install

I tried that one and it works right out of the box. Impressive. But due lack of accounting (Free Radius integration) it might be not suitable. I keep researching.

Thank you,

[TinCanTech]

None of them works. They all struggle to resolve URLs

DNS either works or it does not, there is no "struggle" ..

[houmie75]

DNS either works or it does not, there is no "struggle" ..

Well, please don't shoot the messenger.

bbc.com works after 30 seconds waiting time.
google.com times out entirely - every time.

And I'm using the scripts you gave me. There can't be a configuration issue. Happy to take a video to prove it.

[TinCanTech]

According to the configs you posted, you are messing about with --tun-mtu ..

The manual clearly states:

• In most cases, you will probably want to leave this parameter set to its default value

[houmie75]

Oh sorry, that's a misunderstanding. I'm no longer working with my initial setup. I'm now working with the Angristan script that you sent me on a fresh new AWS instance. Allow me to share the new config:

View Originalserver

port 1194
proto udp
dev tun
user nobody
group nogroup
persist-key
persist-tun
keepalive 10 120
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 84.200.69.80"
push "dhcp-option DNS 84.200.70.40"
push "redirect-gateway def1 bypass-dhcp"
dh none
ecdh-curve prime256v1
tls-crypt tls-crypt.key 0
crl-verify crl.pem
ca ca.crt
cert server_Gby3WDZVd01F3bP3.crt
key server_Gby3WDZVd01F3bP3.key
auth SHA256
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
tls-server
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
client-config-dir /etc/openvpn/ccd
status /var/log/openvpn/status.log
verb 3

View Originalclient

client
proto udp
explicit-exit-notify
remote 18.133.xxx.xx 1194
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_Gby3WDZVd01F3bP3 name
auth SHA256
auth-nocache
cipher AES-128-GCM
tls-client
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
ignore-unknown-option block-outside-dns
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3
<ca></ca>
<cert></cert>
<key></key>
<tls-crypt></tls-crypt>

These were completely auto generated for me.

I just borrowed a Windows Laptop and tried the client.ovpn there and it works fine. No issues with DNS.
But it doesn't seem to work on iPhone and Mac.

[TinCanTech]

Allow me to share the new config

Config looks good.

I just borrowed a Windows Laptop and tried the client.ovpn there and it works fine. No issues with DNS.

Good.

But it doesn't seem to work on iPhone and Mac.

Do you mean DNS doesn't work or the VPN ? -- Need to see client logs..

[houmie75]

Hey thank you so much for helping me.

Yes the DNS resolution doesn't work for the same VPN on Mac. But it works on Windows.

Mac client log: (I tried to go to google.com, but it didn't work, see log below)

Code: Select all

2020-08-03 20:22:09.325873 *Tunnelblick: macOS 10.15.6 (19G73); Tunnelblick 3.8.3 (build 5520)
2020-08-03 20:22:09.780814 *Tunnelblick: Attempting connection with c1 using shadow copy; Set nameserver = 769; monitoring connection
2020-08-03 20:22:09.781094 *Tunnelblick: openvpnstart start c1.tblk 53671 769 0 1 0 1098032 -ptADGNWradsgnw 2.4.9-openssl-1.1.1g
2020-08-03 20:22:09.803925 *Tunnelblick: openvpnstart starting OpenVPN
2020-08-03 20:22:10.009666 Unrecognized option or missing or extra parameter(s) in /Library/Application Support/Tunnelblick/Users/houmie/c1.tblk/Contents/Resources/config.ovpn:19: block-outside-dns (2.4.9)
2020-08-03 20:22:10.012724 OpenVPN 2.4.9 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jul 24 2020
2020-08-03 20:22:10.012782 library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10
2020-08-03 20:22:10.014279 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:53671
2020-08-03 20:22:10.014325 Need hold release from management interface, waiting...
2020-08-03 20:22:10.405046 *Tunnelblick: openvpnstart log:
     OpenVPN started successfully.
     Command used to start OpenVPN (one argument per displayed line):
          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.4.9-openssl-1.1.1g/openvpn
          --daemon
          --log /Library/Application Support/Tunnelblick/Logs/-SUsers-Shoumie-SLibrary-SApplication Support-STunnelblick-SConfigurations-Sc1.tblk-SContents-SResources-Sconfig.ovpn.769_0_1_0_1098032.53671.openvpn.log
          --cd /Library/Application Support/Tunnelblick/Users/houmie/c1.tblk/Contents/Resources
          --machine-readable-output
          --setenv IV_GUI_VER "net.tunnelblick.tunnelblick 5520 3.8.3 (build 5520)"
          --verb 3
          --config /Library/Application Support/Tunnelblick/Users/houmie/c1.tblk/Contents/Resources/config.ovpn
          --setenv TUNNELBLICK_CONFIG_FOLDER /Library/Application Support/Tunnelblick/Users/houmie/c1.tblk/Contents/Resources
          --verb 3
          --cd /Library/Application Support/Tunnelblick/Users/houmie/c1.tblk/Contents/Resources
          --management 127.0.0.1 53671 /Library/Application Support/Tunnelblick/dpldianofjndlnlmephklpdjdjanalngiefgnlac.mip
          --management-query-passwords
          --management-hold
          --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
2020-08-03 20:22:10.406655 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:53671
2020-08-03 20:22:10.414071 MANAGEMENT: CMD 'pid'
2020-08-03 20:22:10.414131 MANAGEMENT: CMD 'auth-retry interact'
2020-08-03 20:22:10.414153 MANAGEMENT: CMD 'state on'
2020-08-03 20:22:10.414166 MANAGEMENT: CMD 'state'
2020-08-03 20:22:10.414192 MANAGEMENT: CMD 'bytecount 1'
2020-08-03 20:22:10.416521 *Tunnelblick: Established communication with OpenVPN
2020-08-03 20:22:10.417068 *Tunnelblick: >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
2020-08-03 20:22:10.417965 MANAGEMENT: CMD 'hold release'
2020-08-03 20:22:10.418072 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2020-08-03 20:22:10.427938 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2020-08-03 20:22:10.428346 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2020-08-03 20:22:10.428367 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2020-08-03 20:22:10.428379 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2020-08-03 20:22:10.429110 TCP/UDP: Preserving recently used remote address: [AF_INET]18.133.xxx.xx:1194
2020-08-03 20:22:10.429177 Socket Buffers: R=[786896->786896] S=[9216->9216]
2020-08-03 20:22:10.429190 UDP link local: (not bound)
2020-08-03 20:22:10.429201 UDP link remote: [AF_INET]18.133.xxx.xx:1194
2020-08-03 20:22:10.429245 MANAGEMENT: >STATE:1596469930,WAIT,,,,,,
2020-08-03 20:22:10.559186 MANAGEMENT: >STATE:1596469930,AUTH,,,,,,
2020-08-03 20:22:10.559261 TLS: Initial packet from [AF_INET]18.133.xxx.xx:1194, sid=0b076cf7 88d7af2b
2020-08-03 20:22:10.824134 VERIFY OK: depth=1, CN=cn_7WwgXp118ar6DPrY
2020-08-03 20:22:10.825733 VERIFY KU OK
2020-08-03 20:22:10.825762 Validating certificate extended key usage
2020-08-03 20:22:10.825778 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2020-08-03 20:22:10.825792 VERIFY EKU OK
2020-08-03 20:22:10.825804 VERIFY X509NAME OK: CN=server_Gby3WDZVd01F3bP3
2020-08-03 20:22:10.825817 VERIFY OK: depth=0, CN=server_Gby3WDZVd01F3bP3
2020-08-03 20:22:10.974286 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 256 bit EC, curve: prime256v1
2020-08-03 20:22:10.974414 [server_Gby3WDZVd01F3bP3] Peer Connection Initiated with [AF_INET]18.133.xxx.xx:1194
2020-08-03 20:22:12.203012 MANAGEMENT: >STATE:1596469932,GET_CONFIG,,,,,,
2020-08-03 20:22:12.203219 SENT CONTROL [server_Gby3WDZVd01F3bP3]: 'PUSH_REQUEST' (status=1)
2020-08-03 20:22:12.328151 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 84.200.69.80,dhcp-option DNS 84.200.70.40,redirect-gateway def1 bypass-dhcp,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-128-GCM'
2020-08-03 20:22:12.328403 OPTIONS IMPORT: timers and/or timeouts modified
2020-08-03 20:22:12.328443 OPTIONS IMPORT: --ifconfig/up options modified
2020-08-03 20:22:12.328463 OPTIONS IMPORT: route options modified
2020-08-03 20:22:12.328483 OPTIONS IMPORT: route-related options modified
2020-08-03 20:22:12.328501 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2020-08-03 20:22:12.328520 OPTIONS IMPORT: peer-id set
2020-08-03 20:22:12.328539 OPTIONS IMPORT: adjusting link_mtu to 1624
2020-08-03 20:22:12.328557 OPTIONS IMPORT: data channel crypto options modified
2020-08-03 20:22:12.328750 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
2020-08-03 20:22:12.328778 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
2020-08-03 20:22:12.329619 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2020-08-03 20:22:12.329818 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2020-08-03 20:22:12.329874 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2020-08-03 20:22:12.329906 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2020-08-03 20:22:12.329935 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2020-08-03 20:22:12.329963 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2020-08-03 20:22:12.329990 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2020-08-03 20:22:12.330018 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2020-08-03 20:22:12.330371 Opened utun device utun8
2020-08-03 20:22:12.330727 MANAGEMENT: >STATE:1596469932,ASSIGN_IP,,10.8.0.2,,,,
2020-08-03 20:22:12.330786 /sbin/ifconfig utun8 delete
                           ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2020-08-03 20:22:12.339232 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2020-08-03 20:22:12.339284 /sbin/ifconfig utun8 10.8.0.2 10.8.0.2 netmask 255.255.255.0 mtu 1500 up
2020-08-03 20:22:12.342013 /sbin/route add -net 10.8.0.0 10.8.0.2 255.255.255.0
                           add net 10.8.0.0: gateway 10.8.0.2
2020-08-03 20:22:12.347235 /sbin/route add -net 18.133.xxx.xx 192.168.1.1 255.255.255.255
                           add net 18.133.xxx.xx: gateway 192.168.1.1
2020-08-03 20:22:12.349157 /sbin/route add -net 0.0.0.0 10.8.0.1 128.0.0.0
                           add net 0.0.0.0: gateway 10.8.0.1
2020-08-03 20:22:12.352028 /sbin/route add -net 128.0.0.0 10.8.0.1 128.0.0.0
                           add net 128.0.0.0: gateway 10.8.0.1
                           20:22:12 *Tunnelblick:  **********************************************
                           20:22:12 *Tunnelblick:  Start of output from client.up.tunnelblick.sh
                           20:22:14 *Tunnelblick:  Disabled IPv6 for 'USB 10/100/1000 LAN'
                           20:22:14 *Tunnelblick:  Disabled IPv6 for 'Wi-Fi'
                           20:22:14 *Tunnelblick:  Disabled IPv6 for 'Bluetooth PAN'
                           20:22:14 *Tunnelblick:  Disabled IPv6 for 'Thunderbolt Bridge'
                           20:22:14 *Tunnelblick:  Disabled IPv6 for 'wg0-client-4aFpW3Hnw8'
                           20:22:14 *Tunnelblick:  Retrieved from OpenVPN: name server(s) [ 84.200.69.80 84.200.70.40 ], search domain(s) [ ] and SMB server(s) [ ] and using default domain name [ openvpn ]
                           20:22:14 *Tunnelblick:  Not aggregating ServerAddresses because running on macOS 10.6 or higher
                           20:22:14 *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
                           20:22:16 *Tunnelblick:  Saved the DNS and SMB configurations so they can be restored
                           20:22:16 *Tunnelblick:  Changed DNS ServerAddresses setting from '192.168.1.1 0.0.0.0' to '84.200.69.80 84.200.70.40'
                           20:22:16 *Tunnelblick:  Changed DNS SearchDomains setting from '' to 'openvpn'
                           20:22:16 *Tunnelblick:  Changed DNS DomainName setting from '' to 'openvpn'
                           20:22:16 *Tunnelblick:  Did not change SMB NetBIOSName setting of ''
                           20:22:16 *Tunnelblick:  Did not change SMB Workgroup setting of ''
                           20:22:16 *Tunnelblick:  Did not change SMB WINSAddresses setting of ''
                           20:22:16 *Tunnelblick:  DNS servers '84.200.69.80 84.200.70.40' will be used for DNS queries when the VPN is active
                           20:22:16 *Tunnelblick:  The DNS servers include only free public DNS servers known to Tunnelblick.
                           20:22:16 *Tunnelblick:  Flushed the DNS cache via dscacheutil
                           20:22:16 *Tunnelblick:  /usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil
                           20:22:16 *Tunnelblick:  Notified mDNSResponder that the DNS cache was flushed
                           20:22:16 *Tunnelblick:  Not notifying mDNSResponderHelper that the DNS cache was flushed because it is not running
                           20:22:16 *Tunnelblick:  Setting up to monitor system configuration with process-network-changes
                           20:22:16 *Tunnelblick:  End of output from client.up.tunnelblick.sh
                           20:22:16 *Tunnelblick:  **********************************************
2020-08-03 20:22:16.427963 Initialization Sequence Completed
2020-08-03 20:22:16.428033 MANAGEMENT: >STATE:1596469936,CONNECTED,SUCCESS,10.8.0.2,18.133.xxx.xx,1194,,
2020-08-03 20:22:16.576785 *Tunnelblick: Could not determine this computer's apparent public IP address before the connection was completed
2020-08-03 20:22:17.643412 *Tunnelblick: DNS address 84.200.69.80 is being routed through the VPN
2020-08-03 20:22:17.757208 *Tunnelblick: DNS address 84.200.70.40 is being routed through the VPN

[TinCanTech]

Yes the DNS resolution doesn't work for the same VPN on Mac

According to your log I think DNS has been setup OK. Try using a different service ..

Also, just to be sure the tunnel works for the MAC etc, try ping 8.8.8.8 (No DNS)

[houmie75]

Yeah ping works.

Code: Select all

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=101 time=134.612 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=101 time=137.281 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=101 time=127.615 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=101 time=126.740 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=101 time=146.328 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=101 time=155.729 ms
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 126.740/138.051/155.729/10.249 ms

I tried already 8.8.8.8 and OpenDNS, and 1.1.1.1 to resolve DNS on the server side. Strange right?

[TinCanTech]

Yeah ping works.

Good.

the DNS resolution doesn't work for the same VPN on Mac. But it works on Windows

Strange right?

Odd .. -- Do both machines use the same internet connection ?

[TinCanTech]

I notice this in your Tunnelblick log:

2020-08-03 20:22:12.330018 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2020-08-03 20:22:12.330371 Opened utun device utun8
2020-08-03 20:22:12.330727 MANAGEMENT: >STATE:1596469932,ASSIGN_IP,,10.8.0.2,,,,
2020-08-03 20:22:12.330786 /sbin/ifconfig utun8 delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2020-08-03 20:22:12.339232 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2020-08-03 20:22:12.339284 /sbin/ifconfig utun8 10.8.0.2 10.8.0.2 netmask 255.255.255.0 mtu 1500 up

utun8 suggests you are already using utun0 to utun7 for something else ..