Strange OpenVPN issue

[nikolay...@gmail.com]

Good morning fellows,

I'm new Mac user and I'm trying to migrate from Windows to Mac, but I'm stuck on my OpenVPN migration.

First I would like to thank the Tunnelblick team, for doing this great free GUI for OpenVPN connectivity.

Secondly I would like to ask the more experienced people regarding my issue.

My OpenVPN configuration is working perfectly fine on every windows PC. I'm running an OpenVPN server on a pfSense platform, configured properly. The configuration is using tap interface, UDP port and everything is in bridged mode, receiving IP addresses form my pfSense DHCP server.

However when I migrated to Mac OS X (Mavericks) the OpenVPN works randomly. By randomly I mean:

The initial OpenVPN connection is successful, the whole traffic is routed via the tunnel, no problems whatsoever, but as soon as I disconnect and reconnect again, the second connection is established, but I don't have access to the network at all. I can see that Tunnelblick has taken an IP address from my OpenVPN server, everything looks normal, but I don't have any network access, no ping, can't load any page, even if I try to type the IP address of the page there is no luck.

The strange thing is, that this happens randomly. I can't identify any pattern. When I leave my Macbook Pro for a while and then try to reconnect - the connection is successful, but as soon as I disconnect and reconnect again - no network access, despite the fact, that I have proper IP address, received via the tunnel.

I tried several different clients also - Viscosity, OpenVPN Connect Client and etc. All have the same issue. As soon as I disconnect and reconnect - no network access.

Since I spend about 2 days, trying to troubleshoot my issue I'm looking for help from you guys.

I'm quite open to any suggestions and looking forward to hearing from you!

Thank you for your time!

Regards,

Nick

[jkbull...gmail.com]

Hi. Welcome and good luck! I have a couple of things to try:

Try checking the "Reset the primary interface after disconnecting" checkbox on the Advanced settings page. (Be sure to have the configuration(s) that you want this setting to apply to selected in the list on the left of the "VPN Details…" window when you click on the checkbox, so it will be applied to the specific configuration(s) you want.)

If you are using UDP, try adding "explicit-exit-notify" to your configuration file.

If neither of those helps, please follow the instructions at Read Before You Post.

[Nikolay Zhelev]

Hi jkbull...,

Thank you very much for your quick response. I think I already tried checking the "Reset the primary interface after disconnecting" and that didn't help, but in the afternoon, when I get back home I'll try to add into my client config file the "explicit-exit-notify" line. This sounds like a possible solution to my problem, but tonight I'll provide some feedback, whether that solved my problem or not.

Have a nice day!

Regards,

Nick

[Nikolay Zhelev]

Hi jkbull...,

Unfortunately the line "explicit-exit-notify" didn't fix my problem. Still same issue. Initial connection - OK, after reconnect - no network access.

I'm looking forward to hearing from you!

Regards,

Nick

[jkbull...gmail.com]

Please follow the instructions at Read Before You Post.

[Nikolay Zhelev]

Hi jkbull...,

Please kindly find in the attached file my Tunnelblick Diagnostic Info. I hope this will give you some clue to my issue. I'm looking forward to hearing from you.

---

Regards,

Nick

[jkbull...gmail.com]

The lines

pull "redirect-gateway def1"

pull "route-gateway 192.168.0.1”

pull "dhcp-option DNS 192.168.0.1"

pull "dhcp-option DNS 8.8.8.8"

in the configuration file puzzle me. They an not valid, according to the "pull" entry on the OpenVPN 2.3 man page:

--pull

    This option must be used on a client which is connecting to a multi-client server. It indicates to OpenVPN that it should accept options pushed by the server, provided they are part of the legal set of pushable options (note that the --pull option is implied by --client ).

 

    In particular, --pull allows the server to push routes to the client, so you should not use --pull or --client in situations where you don't trust the server to have control over the client's routing table. 

 

so (A) since you have "client", you don't need "pull", and (B) the rest of the "pull" lines are being ignored -- there are no arguments to "pull".

You should remove those lines and try again, but I doubt that will resolve your problem -- I think OpenVPN is just ignoring them.

The fact that if you "wait for a while" you can connect again makes me think this is a problem with the server, or a device between your client and the server. I suggest you look on the server logs to see what you can. And try using the client from somewhere different (like an Internet cafe or other wireless hotspot) which will have different devices between it and the server.

As an alternative, when the problem happens, try to reset your router and/or cable/satellite modem or other devices on your network and see if that clears up the problem. I've heard of problems with routers that have trouble learning new routes (or maybe it's Ethernet addresses, I don't remember) and it takes 10 or 15 minutes for the old routes/addresses to be flushed.

It might be helpful to see the full log of a successful connect/disconnect cycle, to see if anything odd happens during the disconnect and verify that OpenVPN properly removes the routing it sets up when connecting.

On Tuesday, October 14, 2014 3:50:35 PM UTC-4, Nikolay Zhelev wrote:

Hi jkbull...,

Please kindly find in the attached file my Tunnelblick Diagnostic Info. I hope this will give you some clue to my issue. I'm looking forward to hearing from you.

---

Regards,

Nick

On Tuesday, 14 October 2014 17:55:45 UTC+1, jkbull...gmail.com wrote:

[Nikolay Zhelev]

Hi jkbull...,

Thank you for your immediate response!

I removed the "pull" arguments, but that didn't change anything. Following your advice, I connected my Macbook to my iPhone in order to remove my router from the network, but the problem is present again. I have one Windows PC and another windows laptop and they both work fine with my OpenVPN connection.

While my Macbook was experiencing the issue, I checked my server logs and I can see that Macbook is connected. So the server sees my macbook. The OpenVPN log on my server is normal, nothing unusual.

I'm almost 100% sure that the problem lies in the Mac OS, or somewhere between the OS and the OpenVPN client, but unfortunately I don't have experience with Mac OS and can't resolve it.

Thank your for your time, if something else comes on your mind, feel free to share. 

[Nikolay Zhelev]

Hi jkbull...,

After extensive troubleshooting (I spent around 6 hours) I identified the problem.

OpenVPN for Mac OS X can't use "redirect-gateway def1" and "route-gateway xx.xx.xx.xx." at the same time. It omits one or the other.

A more detailed explanation regarding my case:

My OpenVPN configuration is bridged using tap interface. My clients are receiving their IP addresses, DNS servers and Gateway via my DHCP server located on my OpenVPN server platform. Since that's my case, when I try to use any OpenVPN client for Mac OS X (I tried the official OpenVPN Connect Client, Viscosity and Tunnelblick) it requires both "redirect-gateway def1" and "route-gateway xx.xx.xx.xx" in order to receive full network configuration from my DHCP server. There were some suggestions to try to use "route-delay 10" or more, but that didn't helped. The problem is still present.  

I tried to perform the same thing on Windows - my configuration works great. Not a single issue. Apparantley the OpenVPN version for windows can execute both "redirect-gateway def1" and "route-gateway xx.xx.xx.xx." at the same time.

Please, can you advise me, how can I overcome the problem in Mac OS X?

I'm looking forward to hearing from you!

---

Regards,

Nick

[jkbull...gmail.com]

What you are describing must be an OpenVPN issue, not a Tunnelblick issue.

I suppose you could try using "route-gateway xx.xx.xx.xx" and implementing your own version of "redirect-gateway def1" using OpenVPN's "--route" option, which is how OpenVPN implements it; it does two routing command to route everything to the OpenVPN server. Typical commands I see to implement "redirect-gateway def1" are (for example):

2014-10-15 20:37:09 /sbin/route add -net 0.0.0.0 10.9.0.17 128.0.0.0

                                        add net 0.0.0.0: gateway 10.9.0.17

2014-10-15 20:37:09 /sbin/route add -net 128.0.0.0 10.9.0.17 128.0.0.0

                                        add net 128.0.0.0: gateway 10.9.0.17

Otherwise,  I suggest you consult OpenVPN resources such as:

• OpenVPN FAQ
• OpenVPN HOWTO
• OpenVPN 2.3 Man Page
• OpenVPN Documentation
• OpenVPN Users Forum
• OpenVPN Users Mailing List

[Nikolay Zhelev]

Ji jkbull...,

Thank you very much for your quick reply! I tried removing the redirect-gateway command and setting up manual routing, but under Mac OS it doesn't work. Same result. Windows is fine with manual and automatic routing, but Mac is a different story.

I traced the problem to Default Gateway prioritising issue in Mac OS. Apparently OpenVPN can't prioritise it's gateway over my Wi-Fi gateway or at least I couldn't do it. By the way my goal is to route all of my traffic via my VPN tunnel.

I read about similar issue in your post here: https://groups.google.com/forum/#!topic/tunnelblick-discuss/IdDRnr6x9TY

Can you share please what was the outcome?

P.S. I managed to get my OpenVPN working by using Viscosity. In Viscosity I introduced route-delay 10 and the configuration was OK, unfortunately with Tunnelblick I couldn't manage to make it work.

Thank you very much for your time. I'll be happy to see what was the outcome from the long discussion in the above mentioned topic.

Have a nice evening.

[jkbull...gmail.com]

Hi. There was no outcome from the long discussion you linked to. I don't understand enough about this whole issue to implement anything.

On Thursday, October 16, 2014 6:28:57 PM UTC-4, Nikolay Zhelev wrote:

Ji jkbull...,

Thank you very much for your quick reply! I tried removing the redirect-gateway command and setting up manual routing, but under Mac OS it doesn't work. Same result. Windows is fine with manual and automatic routing, but Mac is a different story.

I traced the problem to Default Gateway prioritising issue in Mac OS. Apparently OpenVPN can't prioritise it's gateway over my Wi-Fi gateway or at least I couldn't do it. By the way my goal is to route all of my traffic via my VPN tunnel.

I read about similar issue in your post here: https://groups.google.com/forum/#!topic/tunnelblick-discuss/IdDRnr6x9TY

Can you share please what was the outcome?

P.S. I managed to get my OpenVPN working by using Viscosity. In Viscosity I introduced route-delay 10 and the configuration was OK, unfortunately with Tunnelblick I couldn't manage to make it work.

Thank you very much for your time. I'll be happy to see what was the outcome from the long discussion in the above mentioned topic.

Have a nice evening.

On Thursday, 16 October 2014 01:40:25 UTC+1, jkbull...gmail.com wrote:

[Nikolay Zhelev]

I posted my problem in the OpenVPN community, so I hope they will come with some feedback regrading the redirect-gateway directive and why it's not working correctly under Mac OS X.

Regards,

Nick

[jkbull...gmail.com]

It isn't that redirect-gateway isn't working (it works for lots of people) -- it is some combination of things that includes redirect-gateway. I think it has to do with the way that OS X prioritizes devices, based on their order in the Network System Preferences.

[Nikolay Trifonov Zhelev]

Hi jkbull…,

Sorry for my mistake, I’m a bit tired of this issue, took me more than 3 days.

I think the problem is present when I use —redirect-gateway in combination with —route-gateway in OpenVPN bridged configuration, where the clients are receiving their IP addresses from a DHCP server behind the OpenVPN server, which is my case.

I hope this will be resolved in the next OpenVPN release.

Kind Regards,

Nikolay Zhelev

--
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/XVtK9J01hi0/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.

[Nikolay Zhelev]

Dear fellows,

Problem Resolved!

Please be aware, that this solution is valid only for Mac users, trying to connect to OpenVPN server, which is bridged with a DHCP server using tap interface and UDP protocol. Also the final goal is to route all traffic via the VPN tunnel.

Tunnelblick now works. Finally I managed to solve my problem. Just for reference, today I installed security update 2014-005 for OS X Mavericks and disabled ipv6 protocol by typing the following command in Bash:

networksetup -setv6off wi-fi

I’m not sure whether this had any effect on my configuration or not, but it’s good to know what I’ve done.

In Tunnelblick my configuration works only with: Set nameserver (3.0b10)

The problem was that when I was using both redirect-gateway and route-gateway in my client configuration file, my tap adapter was not receiving any IP address from the DHCP server. Because of that OpenVPN was just skipping the fact that my tap adapter doesn’t have any IP address and proceeding to routing table modification, but since there was nothing to route, the client was proceeding to the next command –route-gateway.

Since my tap adapter didn’t have an IP address, the --route-gateway command was assigning the pre-defined gateway IP address to my Wi-Fi adapter.

Result: Complete mess.

When I introduced the –route-delay 10 command, I set a 10 seconds holding time, before the execution of –redirect-gateway and route-gateway commands. This holding time allowed my tap adapter to receive a proper network configuration from my DHCP server and from that point all other commands make sense.

Please if you see something, which is not right in the text above, feel free to correct me.

Good luck to all of you, trying to resolve similar cases!

Regards,
Nick

[jkbull...gmail.com]

OK. I **think** I understand.

Nikolay's setup gets DHCP from a DHCP server that was in the VPN. In this situation, it can take a long time to get the DHCP information -- many seconds. To avoid a long delay, Tunnelblick tells OpenVPN to go ahead and finish establishing the connection while Tunnelblick waits for the DHCP information. If it takes too long, and if OpenVPN needs to do certain things that depend on the DHCP address (such as setting up certain routing), then there are problems.

The solution Nikolay found, to add "route-delay 10" to the configuration, introduces a delay before OpenVPN does anything with the routing. That ten seconds is to give Tunnelblick time to get the DHCP info and deal with it. However, it is possible that getting the DHCP info will take more than ten seconds, in which case the connection will probably fail the same way it did without any delay.

The best solution may be to have a checkbox that tells Tunnelblick to wait until after Tunnelblick has processed the DHCP info to tell OpenVPN to continue. That way, if the DHCP info comes in quickly, OpenVPN will be able to continue quickly, and if the DHCP info is delayed longer than ten seconds, the connection will proceed when it does arrive. I will look into doing that.

[Nikolay Zhelev]

Hi jkbull...,

Thanks for all your help!

Yes, you've understood correctly my situation! I believe, introducing a check box under the advanced options named for example "DHCP over TAP" would be very good improvement, or you can make it automatically in case the config file has tap interface and is using udp protocol (I'm not sure whether or not you can have bridged configuration with tcp).

I'm very pleased that you developers are looking for continuous improvement of your software and also I believe that's the key to success, thank you!

Yours sincerely,

Nikolay Zhelev

--

[jkbull...gmail.com]

@Nikolay --

Thanks for reporting your solution to the problem. That's very helpful, and I forgot to thank you earlier.

Before I work on adding a checkbox or doing this automatically, could you please post the diagnostic info from a successful connect/disconnect cycle (with the delay that makes it work)? I'd like to verify my understanding of a couple of things. If you prefer, you could send it to me privately to my gmail address, which is jkbullard.

(I don't know why TAP wouldn't work over TCP; it would be slower, of course, but it should work. But then, I'm not an OpenVPN expert.)

On Saturday, October 18, 2014 6:25:36 AM UTC-4, Nikolay Zhelev wrote:

Hi jkbull...,

Thanks for all your help!

Yes, you've understood correctly my situation! I believe, introducing a check box under the advanced options named for example "DHCP over TAP" would be very good improvement, or you can make it automatically in case the config file has tap interface and is using udp protocol (I'm not sure whether or not you can have bridged configuration with tcp).

I'm very pleased that you developers are looking for continuous improvement of your software and also I believe that's the key to success, thank you!

Yours sincerely,

Nikolay Zhelev

On 17 Oct 2014, at 20:59, "jkbull...gmail.com"  wrote:

OK. I **think** I understand.

Nikolay's setup gets DHCP from a DHCP server that was in the VPN. In this situation, it can take a long time to get the DHCP information -- many seconds. To avoid a long delay, Tunnelblick tells OpenVPN to go ahead and finish establishing the connection while Tunnelblick waits for the DHCP information. If it takes too long, and if OpenVPN needs to do certain things that depend on the DHCP address (such as setting up certain routing), then there are problems.

The solution Nikolay found, to add "route-delay 10" to the configuration, introduces a delay before OpenVPN does anything with the routing. That ten seconds is to give Tunnelblick time to get the DHCP info and deal with it. However, it is possible that getting the DHCP info will take more than ten seconds, in which case the connection will probably fail the same way it did without any delay.

The best solution may be to have a checkbox that tells Tunnelblick to wait until after Tunnelblick has processed the DHCP info to tell OpenVPN to continue. That way, if the DHCP info comes in quickly, OpenVPN will be able to continue quickly, and if the DHCP info is delayed longer than ten seconds, the connection will proceed when it does arrive. I will look into doing that.

On Friday, October 17, 2014 1:27:21 PM UTC-4, Nikolay Zhelev wrote:

Dear fellows,

Problem Resolved!

Please be aware, that this solution is valid only for Mac users, trying to connect to OpenVPN server, which is bridged with a DHCP server using tap interface and UDP protocol. Also the final goal is to route all traffic via the VPN tunnel.

Tunnelblick now works. Finally I managed to solve my problem. Just for reference, today I installed security update 2014-005 for OS X Mavericks and disabled ipv6 protocol by typing the following command in Bash:

networksetup -setv6off wi-fi

I’m not sure whether this had any effect on my configuration or not, but it’s good to know what I’ve done.

In Tunnelblick my configuration works only with: Set nameserver (3.0b10)

The problem was that when I was using both redirect-gateway and route-gateway in my client configuration file, my tap adapter was not receiving any IP address from the DHCP server. Because of that OpenVPN was just skipping the fact that my tap adapter doesn’t have any IP address and proceeding to routing table modification, but since there was nothing to route, the client was proceeding to the next command –route-gateway.

Since my tap adapter didn’t have an IP address, the --route-gateway command was assigning the pre-defined gateway IP address to my Wi-Fi adapter.

Result: Complete mess.

When I introduced the –route-delay 10 command, I set a 10 seconds holding time, before the execution of –redirect-gateway and route-gateway commands. This holding time allowed my tap adapter to receive a proper network configuration from my DHCP server and from that point all other commands make sense.

Please if you see something, which is not right in the text above, feel free to correct me.

Good luck to all of you, trying to resolve similar cases!

Regards,
Nick

--
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/XVtK9J01hi0/unsubscribe.

To unsubscribe from this group and all its topics, send an email to tunnelblick-discuss+unsub...@googlegroups.com.

[Nikolay Zhelev]

Hi jkbull...,

You are very welcome! Always happy to help! I'll send you details to your e-mail address.

Please consider the topic as closed, issue resolved.

Have a nice weekend!

Regards,

Nick

To unsubscribe from this group and all its topics, send an email to tunnelblick-dis...@googlegroups.com.

[jkbull...gmail.com]

Recent beta versions of Tunnelblick include a checkbox to "Set DNS after routes are set instead of before routes are set". It is in the "Advanced" settings window.

On Saturday, October 18, 2014 at 7:33:47 AM UTC-4, Nikolay Zhelev wrote:

Hi jkbull...,

You are very welcome! Always happy to help! I'll send you details to your e-mail address.

Please consider the topic as closed, issue resolved.

Have a nice weekend!

Regards,

Nick

[Vaibhav Singh]

Can you help me here, I'm facing the same issue. Unable to reach the server even after successfully connecting with VPN.

[Tunnelblick developer]

@Vaibhav - Please post the diagnostic info obtained by following the instructions at Read Before You Post.