Tunnelblick works over mobile tethering, but not over home router

[koolnez]

So this has got me utterly flummoxed. Hope the experts here can help me track this down.

The entire OpenVPN/Tunnelblick setup between home and office works without problem when I'm tether over mobile network, but doesn't work over the home router. 

Mac OS X 10.11.4, Tunnelblick 3.5.5 (build 4270.4461)

OVER HOME ROUTER

------------

(1) Tunnelblick is able to connect to server

(2) tun0 device is created, ip address is allocated

(3) routing table is setup, DNS is updated

(4) nslookup is able to resolve the server, ping is able to ping the server, traceroute is able to trace the route to server

(5) *BUT* when I try to connect to server in the browser, it times out with error.  (Note that this is a https:// URL)

(6) curl is able to resolve the server name, connect to it, but finally drops the connection with the following error:

[code]

* SSLRead() return error -9806

* Closing connection 2

curl: (56) SSLRead() return error -9806

[/code]

OVER MOBILE TETHERING

----------

All the above steps work without problem, browser connects happily to server, curl returns the html page.

So the questions are:

(1) What setting on the router could possibly be affecting the application level functioning AFTER the tunnel is setup?

(2) What information would you need to help debug this?

(3) Is there anything else I can try on the router? I've exhausted all possibilities I could think of on the router.

If it helps, the ISP is Distributel in Montreal, Canada. The router is a SMART/RG SR505n, firmware version 2.5.0.8

[jkbull...gmail.com]

It isn't necessarily a router setting, but it might be. It depends on your OpenVPN setup (your OpenVPN configuration file, what is "pushed" to your computer by the OpenVPN server, and Tunnelblick option settings – it's complicated).

"nslookup", "ping", and other commmand-line tools on OS X do not use the standard OS X DNS resolution that browsers do. The fact that they "work" is not an indication that DNS resolution is working properly. In fact, from your description, I think it likely that DNS is the problem – but there are other possibilities, too.

Get the diagnostic info (see Before You Post) for connecting/disconnecting with both the tethered and home router setups. Either compare them yourself or post the info for both here.

You should use Tunnelblick 3.6beta18 for this, and have Tunnelblick "Check if the apparent public IP address changed after connecting" (on the "Settings" tab of the "VPN Details" window). That setting will try to access https://tunnelblick.net/ipinfo using "tunnelblick.net" by name, and if that fails, by using the "tunnelblick.net" IP address, so it is a good check on DNS problems.

[koolnez]

Hi,

Thank you for the reply.

(1) I updated to 3.6Beta and compared the logs. They are exactly identical except for the timestamps, IP address of the gateways, and a few other place where time values were different.

(2) The apparent public IP change is not significant since all traffic is not routed over the VPN. And the same message is displayed in both cases ("Public IP address not changed").

(3) Specific routes are pushed from the server and they get successfully added to the routing table -- verified using netstat -nr

(4) I can reach the Internet without problem with OpenVPN connected on the home router. It's only the office VPN sites that are unreachable.

(5) Thanks for the tip on nslookup, etc. Is there a native tool that could be used on OS X?

(6) I used scutil --dns and got this response:

resolver #1

  search domain[0] : companyname.com

  nameserver[0] : 10.93.32.2

  nameserver[1] : 10.93.32.3

  nameserver[2] : 10.93.32.4

  if_index : 4 (en0)

  flags    : Scoped, Request A records

Reachable

Which seems to be correct.

(7) Running "dig" on the server also returns correct information.

[koolnez]

Running dscacheutil -q host -a name servername.com

returns correct IP address. 

Using the "Native" Network Utility also returns correct IP address with the Lookup tool

So it seems that DNS issues may be ruled out?

[jkbull...gmail.com]

I didn't realize you want a "split tunnel" (some traffic through the VPN, some not). So the server you want to browse to is within the VPN (a private Intranet) and access to other Internet sites is working normally (e.g., Google, Apple, etc.) even when your VPN is connected.

To troubleshoot this, you should temporarily set it up to route everything through the VPN. I expect that will cause you not to be able to browse at all. (For simplicity, please use Safari to test this; Chrome does it's own name resolution sometimes, I think). But with these settings the "Check if IP address changes" logic will help pinpoint this as a DNS problem (if it is one).

DNS issues may not be ruled out. "dig" also does not use the standard OS X DNS resolution, and neither does the "Lookup" tool in Network Utility (it just runs one of the command line tools). I don't know of any command line tools that do. When you say it returns "the correct information", actually, it is not. It is returning information that some command line tools will use, but not the information that OS X applications will use.

On Tuesday, January 26, 2016 at 1:50:21 PM UTC-5, koolnez wrote:

[koolnez]

Hi, Thank you for helping me. Really appreciate it.

Now I arrived at a client's office and used their WiFi to connect to the VPN and again everything works as expected. It is ONLY when I'm on my home WiFi / Home Router that this problem crops up. It is beyond annoying!

I will do the test that you suggest when I get back home.

Just to clarify the logic:

What is the expected outcome if I route all traffic through VPN? I think I tried it once before and I could not reach the sites on the Internet.

If it is indeed a DNS issue, what should we see? The logs in Tunnelblick don't display anything after the connection is established. Is there a way to monitor the network activity?

Thank you once again.

[jkbull...gmail.com]

Try sending everything through the VPN and having Tunnelblick check for IP address changes. If the result is:

• Browsers are not be able to access the Internet; and
  
  
• Tunnelblick is not able to access tunnelblick.net by name, but is able to access it by IP address

then it is a DNS problem.

I can't say what is causing the problem without both sets of "diagnostic info". If you'd rather send it to me privately, do so at my Gmail address,  jkbullard.

[koolnez]

So, I tried your suggestion of routing all traffic through the VPN. The result is that:

(1) Internet is not accessible,

(2) Tunnelblick is not accessible even by IP address:

2016-01-26 23:22:26 *Tunnelblick: After 30.0 seconds, gave up trying to fetch IP address information using the ipInfo host's name after connecting.

2016-01-26 23:23:02 *Tunnelblick: After 30.0 seconds, gave up trying to fetch IP address information using the ipInfo host's IP address after connecting.

[koolnez]

Hi,

Any more ideas to try? Did you get time to analyze the logs that I sent you?

Thanks.

On Tuesday, January 26, 2016 at 4:17:30 PM UTC-5, jkbull...gmail.com wrote:

[koolnez]

Hi,

Figured it out finally with the help of Wireshark. See the relevant capture data attached. The problem turned out to be the MTU size of the TCP packet. I noticed that the packet was getting fragmented and the server acknowledgement was never received. ("Ignored unknown record" error). All this happened after the SSL/TLS exchange.

So then I checked the MTU size in the router and it was set to 1452 bytes. I changed it to 1492 bytes, which is more or less standard for PPPoE, and voila!, everything started working perfectly!

I would really like to thank you for your time and interest in solving this problem. It is on account of dedicated individuals like you, that the community is thriving.

Best regards,

On Tuesday, January 26, 2016 at 4:17:30 PM UTC-5, jkbull...gmail.com wrote:

[jkbull...gmail.com]

Ah. Thanks for writing up the solution and for your kind words.

I'm sorry I wasn't able to actually help, though – I hadn't thought about MTU as being a problem.