Issues with TAP - Either no DNS or no IP

[an...@dieball.net]

Hi

my Server Config:

openvpn vtun1 {
         bridge-group {
             bridge br0
         }
         description "Incoming OpenVPN Bridge"
         device-type tap
         local-port 443
         mode server
         openvpn-option "--push redirect-gateway def1"
         openvpn-option "--push route-delay 10"
         openvpn-option "--cert /config/auth/ca/keys/adieball.dvrdns.org.crt"
         openvpn-option "--key /config/auth/ca/keys/adieball.dvrdns.org.key"
         openvpn-option --duplicate-cn
         openvpn-option "--push route-gateway 10.2.2.1"
         openvpn-option --comp-lzo
         openvpn-option --tcp-nodelay
         openvpn-option "--push dhcp-option DOMAIN acme.net"
         openvpn-option "--push dhcp-option DNS 10.2.2.2"
         protocol tcp-passive
         server {
             subnet 10.2.2.0/24
         }
         tls {
             ca-cert-file /config/auth/ca/keys/ca.crt
             cert-file /config/auth/ca/keys/acme.dvrdns.org.crt
             crl-file /config/auth/ca/keys/crl.pem
             dh-file /config/auth/ca/keys/dh1024.pem
             key-file /config/auth/ca/keys/acme.dvrdns.org.key
         }
     }

I have to say, I used Viscosity before and it was working fine, but I have trouble with Tunelblick.

Using 3.5beta10 (build 4262)

When I use anything else than "Set Nameserver", I get an IP on the tap0 interface but the /etc/resolv.conf doesn't get updated.

When I use "Ser Nameserver", /etc/resolv.conf get's updated correctly, but I never get an IP on the tap0 interface.

Logfile when using "Set Nameserver":

2015-05-04 10:32:23 *Tunnelblick: openvpnstart starting OpenVPN

 

2015-05-04 10:32:22 *Tunnelblick: OS X 10.10.4; Tunnelblick 3.5beta10 (build 4262); prior version 3.5beta08 (build 4236)

2015-05-04 10:32:23 *Tunnelblick: Attempting connection with Home TCP 443 Bridged using shadow copy; Set nameserver = 1; monitoring connection

2015-05-04 10:32:23 *Tunnelblick: openvpnstart start Home\ TCP\ 443\ Bridged.tblk 1338 1 0 1 0 16754 -ptADGNWradsgnw 2.3.6

2015-05-04 10:32:24 *Tunnelblick: openvpnstart log:

     Loading tap-signed.kext

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

     

          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.6/openvpn

          --daemon

          --log

          /Library/Application Support/Tunnelblick/Logs/-SUsers-Sadieball-SLibrary-SApplication Support-STunnelblick-SConfigurations-SHome TCP 443 Bridged.tblk-SContents-SResources-Sconfig.ovpn.1_0_1_0_16754.1338.openvpn.log

          --cd

          /Library/Application Support/Tunnelblick/Users/adieball/Home TCP 443 Bridged.tblk/Contents/Resources

          --config

          /Library/Application Support/Tunnelblick/Users/adieball/Home TCP 443 Bridged.tblk/Contents/Resources/config.ovpn

          --cd

          /Library/Application Support/Tunnelblick/Users/adieball/Home TCP 443 Bridged.tblk/Contents/Resources

          --management

          127.0.0.1

          1338

          --management-query-passwords

          --management-hold

          --script-security

          2

          --up

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

          --down

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

          --route-pre-down

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


 

2015-05-04 10:32:24 *Tunnelblick: Established communication with OpenVPN

2015-05-04 10:32:24 OpenVPN 2.3.6 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Mar 30 2015

2015-05-04 10:32:24 library versions: OpenSSL 1.0.1m 19 Mar 2015, LZO 2.08

2015-05-04 10:32:24 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.

2015-05-04 10:32:24 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2015-05-04 10:32:25 Attempting to establish TCP connection with [AF_INET]87.162.80.199:443 [nonblock]

2015-05-04 10:32:26 TCP connection established with [AF_INET]87.162.80.199:443

2015-05-04 10:32:26 TCPv4_CLIENT link local: [undef]

2015-05-04 10:32:26 TCPv4_CLIENT link remote: [AF_INET]87.162.80.199:443

2015-05-04 10:32:27 [adieball.dvrdns.org] Peer Connection Initiated with [AF_INET]87.162.80.199:443

2015-05-04 10:32:30 TUN/TAP device /dev/tap0 opened

2015-05-04 10:32:30 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -a -d -f -m -w -ptADGNWradsgnw tap0 1500 1576   init

                                        **********************************************

                                        Start of output from client.up.tunnelblick.sh

                                        Configuring tap DNS via OpenVPN

                                        Retrieved from OpenVPN: name server(s) [ 10.2.2.2 ], domain name [ domain.net ], search domain(s) [  ], and SMB server(s) [  ]

                                        Not aggregating ServerAddresses because running on OS X 10.6 or higher

                                        Setting search domains to 'domain.net' because running under OS X 10.6 or higher and the search domains were not set manually and 'Prepend domain name to search domains' was not selected

                                        Saved the DNS and SMB configurations so they can be restored

                                        Changed DNS ServerAddresses setting from '192.168.2.1 fe80::1' to '10.2.2.2'

                                        Changed DNS SearchDomains setting from '' to 'f0rd42.net'

                                        Changed DNS DomainName setting from 'speedport.ip' to 'f0rd42.net'

                                        Did not change SMB NetBIOSName setting of ''

                                        Did not change SMB Workgroup setting of ''

                                        Did not change SMB WINSAddresses setting of ''

                                        DNS servers '10.2.2.2' will be used for DNS queries when the VPN is active

                                        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.

                                        Flushed the DNS cache via dscacheutil

                                        Flushed the DNS cache via discoveryutil udnsflushcaches

                                        Flushed the DNS cache via discoveryutil mdnsflushcache

                                        No matching processes were found

                                        mDNSResponder not running. Not notifying it that the DNS cache was flushed

                                        Setting up to monitor system configuration with process-network-changes

                                        End of output from client.up.tunnelblick.sh

                                        **********************************************

2015-05-04 10:32:33 write to TUN/TAP : Input/output error (code=5)

.........

2015-05-04 10:32:42 write to TUN/TAP : Input/output error (code=5)

2015-05-04 10:32:42 write to TUN/TAP : Input/output error (code=5)

                                        add net 87.162.80.199: gateway 192.168.2.1

                                        add net 0.0.0.0: gateway 10.2.2.1

                                        add net 128.0.0.0: gateway 10.2.2.1

2015-05-04 10:32:43 Initialization Sequence Completed

2015-05-04 10:32:43 write to TUN/TAP : Input/output error (code=5)

2015-05-04 10:32:43 write to TUN/TAP : Input/output error (code=5)

2015-05-04 10:32:43 write to TUN/TAP : Input/output error (code=5)

2015-05-04 10:32:43 *Tunnelblick: No 'connected.sh' script to execute

2015-05-04 10:32:43 write to TUN/TAP : Input/output error (code=5)

2015-05-04 10:32:43 write to TUN/TAP : Input/output error (code=5)

..........

2015-05-04 10:32:48 write to TUN/TAP : Input/output error (code=5)

2015-05-04 10:32:49 *Tunnelblick: Disconnecting; VPN Details… window disconnect button pressed

2015-05-04 10:32:49 *Tunnelblick: Disconnecting using 'kill'

2015-05-04 10:32:49 event_wait : Interrupted system call (code=4)

2015-05-04 10:32:49 /Applications/Tunnelblick.app/Contents/Resources/client.route-pre-down.tunnelblick.sh -a -d -f -m -w -ptADGNWradsgnw tap0 1500 1576   init

                                        **********************************************

                                        Start of output from client.route-pre-down.tunnelblick.sh

                                        No action by client.route-pre-down.tunnelblick.sh is needed because this TAP connection does not use DHCP via the TAP device.

                                        End of output from client.route-pre-down.tunnelblick.sh

                                        **********************************************

                                        delete net 87.162.80.199: gateway 192.168.2.1

                                        delete net 0.0.0.0: gateway 10.2.2.1

                                        delete net 128.0.0.0: gateway 10.2.2.1

2015-05-04 10:32:49 /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -a -d -f -m -w -ptADGNWradsgnw tap0 1500 1576   init

                                        **********************************************

                                        Start of output from client.down.tunnelblick.sh

                                        Cancelled monitoring of system configuration changes

                                        Restored the DNS and SMB configurations

                                        Flushed the DNS cache via dscacheutil

                                        Flushed the DNS cache via discoveryutil udnsflushcaches

                                        Flushed the DNS cache via discoveryutil mdnsflushcache

                                        No matching processes were found

                                        mDNSResponder not running. Not notifying it that the DNS cache was flushed

                                        End of output from client.down.tunnelblick.sh

                                        **********************************************

2015-05-04 10:32:49 SIGTERM[hard,] received, process exiting

2015-05-04 10:32:50 *Tunnelblick: No 'post-disconnect.sh' script to execute

2015-05-04 10:32:50 *Tunnelblick: Expected disconnection occurred.

WHat's confusing me is that it says :

No action by client.route-pre-down.tunnelblick.sh is needed because this TAP connection does not use DHCP via the TAP device. No action by client.route-pre-down.tunnelblick.sh is needed because this TAP connection does not use DHCP via the TAP device.

when disconnecting ..... where is the config bit that says NOT to use DHCP????

All other (routed, / tun) configs work, but not this TAP one.

thanks

Andre

[Andre Dieball]

anyone any idea?

[jkbull...gmail.com]

It may not help much – TAP connections are often problematic – but please follow the instructions at Read Before You Post to get the info needed to diagnose problems.

Also:

• Note that your server configuration is not an OpenVPN configuration.
  
• You are using OS X 10.10.4, which has not been released yet.
• What does "I never get an IP" mean?
  
• Does Viscosity work now (you said you used it "before")?
  

...

[Andre Dieball]

Hi

I've been though the "Read before you post", but without luck.

Yes, Viscosity still works fine.

Never get an ip means that all the routing is fine and the nameservers get set correctly (in /etc/resolv.conf), but the tap interface on the mac does not get an IP.

The other way around (as described in the original post): I do get an ip, the routing is fine, but the /etc/resolv.conf doesn't gte updated.

Andre

[jkbull...gmail.com]

Please **post** the info you get by following the procedure in the "Read before you post".

[Andre Dieball]

I understand what you want but I have provided all this already in my original post, set to "set nameserver", posted the logfile, etc.

If I'm completely misunderstanding the Readme or your request, please let me know.

thanks

[jkbull...gmail.com]

Yes, there is a misunderstanding.

What you should post is what is copied to the Clipboard by the "Copy Diagnostic Info to Clipboard" button (step 12).

The "diagnostic info" includes a lot more info that the log that you posted originally.

[Andre Dieball]

I see, sorry for that.

please find the output here: http://pastebin.com/AKdwrJxk

thanks

--

You received this message because you are subscribed to a topic in the Google Groups "tunnelblick-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tunnelblick-discuss/nDX6hN3g_rM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tunnelblick-dis...@googlegroups.com.
Visit this group at http://groups.google.com/group/tunnelblick-discuss.
For more options, visit https://groups.google.com/d/optout.

[jkbull...gmail.com]

Thanks. I think I see what's going on.

From looking at what Tunnelblick's "up" script is expecting, you need to add a "push route-gateway dhcp" to the server configuration. (I think you could add "route-gateway dhcp" to the client instead, if you want to do a quick test).

You might also need to either check or un-check (I'm not sure which) the "Set DNS after routes are set instead of before routes are set" checkbox on Tunnelblick's "Advanced" settings page.

From the OpenVPN 2.3 man page:

--route-gateway gw|'dhcp'
    Specify a default gateway gw for use with --route.
    If dhcp is specified as the parameter, the gateway address will be extracted from a DHCP negotiation with the OpenVPN server-side LAN. 

Your original post asked

where is the config bit that says NOT to use DHCP????

Not all TAP configurations are DHCP. Tunnelblick apparently assumes it is NOT DHCP unless you specify otherwise via "route-gateway dhcp".

[Andre Dieball]

I did as you suggested. Unfortunately without luck.

new diagnostic: http://pastebin.com/c5wKAskn

thanks 

[jkbull...gmail.com]

For some reason, it appears that "--push route-gateway 10.2.2.1" is being used instead of "--push route-gateway dhcp".

I can't be sure because for some reason the OpenVPN log is not showing the "push" options. OpenVPN's default setting used to be "verb 3", and would show it, but at some point apparently the default changed to "verb 1", which doesn't show much.

Please add the line

verb 3

to your client configuration, try again, and post the results.

[Andre Dieball]

hi

sorry for the delay.

new output here: http://pastebin.com/CH9immqT

I also tried (not in the diagnostics above) to delete the --push route-gateway 10.2.2.1 bit in the server config, but that ended in "waiting for DHCP" forever -......

thanks

[Andre Dieball]

anyone any idea? This is really driving me crazy. 

I can't use Viscosity anymore, as it heavily relies on python and I changed my python setup

[jkbull...gmail.com]

The only thing I can see is that your server is pushing "route-gateway dhcp,route-gateway 10.2.2.1" – I think that is confusing Tunnelblick's scripts. Try it with just "route-gateway dhcp".