VPN-over-VPN and Route All Traffic setting

[John Robison]

Hello,

We use Tunnelblick and a self-managed OpenVPN server to connect to a private network in AWS. This has been working fine for a few years.

A new corporate policy will enforce usage of a different VPN for all internet traffic using a managed SaaS VPN provider. This also works fine on its own, although it doesn't provide access to our AWS network. Connecting to the AWS network requires connecting Tunnelblick over top of the SaaS VPN. I'm seeing a strange but reproducible issue when using the two VPN's together.

My goal is to route all internet-bound traffic over the SaaS VPN, and route only AWS bound traffic through the Tunnelblick VPN. Here's the steps I'm seeing which reproduce the problem:

1. Connect the SaaS VPN

2. Connect the Tunnelblick AWS VPN, which does connect successfully, and it pushes a route to the AWS network (10.7.0.0/16) and a route for the SaaS VPN (10.255.0.0/16).

3. HTTP traffic to AWS won't work.

4. In Tunnelblick, enable the setting for Route All IPv4 Traffic Through the VPN, even though I don't actually want to route all traffic through AWS.

5. Reconnect Tunnelblick to enable that setting.

6. HTTP traffic to AWS will now work.

7. Disable the setting for Route All IPv4, since I don't really want that anyway.

8. Reconnect Tunnelblick to lock in that setting

9. HTTP traffic to AWS will still work. 

10. Anytime I disconnect from the SaaS VPN, I have to redo steps 2-9 to get AWS-bound HTTP traffic to work, including the enable/disable dance on the Route All IPv4 setting.

Can anybody tell me why enabling/disabling the Route All IPv4 setting is seemingly required to get traffic flowing over the Tunnelblick VPN? I'm happy to share any relevant configuration bits from the OpenVPN server or from Tunnelblick.

Thanks.

[Tunnelblick developer]

You might be better off asking the SAS VPN provider how to do this, since it must be a common situation, but here's my take on it:

OpenVPN uses routing, and only routing, to direct traffic, so it is critical to understand what routes are being set up. To see what is going on, examine the routing tables on the Mac. It's often also helpful to look at the routing that OpenVPN sets up, which can be seen in the Tunnelblick/OpenVPN log. I've included details about Tunnelblick's "Route all IPv4 traffic through the VPN" setting below.

An important question is "how is the SAS VPN controlling traffic"? If via routing, what routes does it set to accomplish that? If via some other mechanism, how does that mechanism affect routing?

My suspicion is that it either uses routing and sets up routing so that OpenVPN's modifications mess things up, or it uses some other mechanism which doesn't work well with the routing that OpenVPN uses to set up the VPN.

I'm not a routing expert, but it seems to me that you should NOT be setting a route to the SaaS VPN in the Tunnelblick/OpenVPN VPN. All the Tunnelblick VPN should do is set a route to the OpenVPN server, and a route to direct all traffic to the AWS network through that OpenVPN server. The previously existing network setup should then send everything else through the SAS VPN.

What I think you want is:

• Normally, all traffic goes through the SAS VPN.
  
  
• When Tunnelblick sets up an OpenVPN VPN to the AWS network, it routes only traffic to the AWS network through the OpenVPN server, leaving the other mechanism in place to go through the SAS VPN.

What "Route all traffic through the VPN" Does

Tunnelblick's "Route all IPv4 traffic through the VPN" checkbox causes Tunnelblick to include the "redirect-gateway def1" option in the command line it uses to start OpenVPN. That option can also be included in the OpenVPN configuration file, and/or it may be "pushed" by the OpenVPN server to the OpenVPN client that is using Tunnelblick.

If OpenVPN is provided with the option by any of those methods, OpenVPN adds two routes when it establishes the VPN: one which routes all IPv4 addresses with a high-bit of 0 through the VPN, the other routes all IPv4 traffic with the high bit of 1 through the VPN.

Because of the way routing works, any "more specific" routes will override those two routes.