How does PIA's openvpn/tap implementation choose which system interface to use?

JackO

I have multiple Windows 10 systems with two physical interfaces each system. Planning on some changes in the network, some which may involve changing/adding default routes and interface/route metric's. I need to know how PIA's openvpn/Tap implementation chooses which interface to use in the system.

Is it the interface with the lowest interface metric, or lowest route metric, or is it the interface with the default route 0.0.0.0/0 in the route table, or is a combination of these or is it something else?

I tried looking at the sources but there is no open source available for the PIA windows implementation on the PIA open source page.  

[Deleted User]

Hello Jacko, 

It is an open source protocol and is at your disposal of dissecting for that particular information. However we see you have created a ticket regarding this request. We will respond in the ticket once we have finished our end of the researching of the required information. If you need further assistance, please let us know! - PIA CS TEAM

JackO

Yes, I did create a ticket asking this after I posted, just in case one of the forum members knew.

yes, it is open source. Although it can be "dissected" there is no where in the source documentation where it outlines how openvpn does what I asked about plus its always focused on a linux implementation and windows seems to be an after thought and you folks are selling a windows product so should know.

There is plenty of information for linux (and a little for windows) on how to set routes and metrics and the sort but there is nothing which tells how openvpn chooses which hardware interface it uses in the system.

After wasting almost two weeks trying to make contact with the openvpn people over at the openvpn site they directed me back to PIA because its PIA's implementation in the PIA product.

If you want to answer the question in the support ticket response that's fine but the email I got was not even on topic for the question asked and sounded as if it was saying "go away, not gonna answer" and the response danced around the subject like support was trying to avoid it. The initial response I got in email was basically telling me that you don't give support on computer use or network changes when that's not what I'm asking for, and additionally the email directed me to the openvpn documentation which does nothing to answer the question and i've already been over and over and further the email gave a brief explanation of what openvpn and a tap adapter is when I already know that and does nothing to answer the question.

Then further the email tells me that I need to disable some of the Interfaces in the systems because, basically, PIA's product does not work with multiple interfaces (which curiously a lot of the people over at openvpn have been doing fine for years in linux). When I already have ,multiple interfaces operating fine in the windows systems with PIA with no issues and its what PIA support told me could be done years ago when I started with PIA and I successfully did and have been doing over years of PIA use. But now the time has come to make changes and I do not want to upset how PIA is functioning as some of the changes will involve changing a lot of routes and interface metrics, etc..., . Yet, all this in support email response dancing around the question trying not to answer it when a few simple words is all that was needed, e.g. 'lowest metric', 'binding order', 'route metric', 'default route' etc....  

I would like to think that PIA knows how its product works, the support response sounded a lot like a contrived canned response trying its best not to answer the question so I'm not happy with it trying to marginalize my question so it will go away because PIA should know how its product works in all aspects and be prepared to answer questions about it product in all aspects. I'm not asking for support for computer work or support for network changes, i'm asking about the purchased PIA product. It does not matter if openvpn is open source or not, you guys package it into your product and sell that product and get paid for the product so should know how it functions for a thing like i'm asking. So since the email from sup[port on the ticket did not answer the question, I ask again...

How does PIA's openvpn/Tap implementation chooses which interface to use in the system? Is it the interface with the lowest interface metric, or lowest route metric, or is it the interface with the default route 0.0.0.0/0 in the route table, or is a combination of these or is it something else?

Omnibus_IV

This link does not explain how the local machine uses the TAP in the VPN network, but it does explain in technical terms the purpose of the TAP adapter.

https://buffered.com/glossary/tun-tap/

JackO

Thanks for your reply Omnibus_IV

I already understand the purpose of the TAP adapter.

Actually its openvpn that is selecting the existing hardware interface in the system to use but indirectly through the TAP.

The TAP gets installed as if its an actual interface but instead its a virtual software interface.

What I need to know is the criteria used by openvpn/TAP through the TAP for selecting which system hardware interface to use.

Many people use two hardware interfaces in their systems, one hard line NIC connection and one wireless. Its not uncommon for openvpn users to have two interfaces installed and you can find examples of people doing this over at the openvpn forums. Our systems have two interfaces installed and its been that way for years and we have been successfully using PIA on those systems.

However, the time has come to make some changes in our network. Doing this is going to involve some changes in route metric, interface metric's adding/removing/changing default routes, etc... the question is, if we make these changes are they going to interfere with how PIA's openvpn/Tap install/implementation is it going to function for selecting the correct interface. To compensate for this we need to know how PIA's openvpn/Tap install/implementation selects which system hardware interface it binds PIA's openvpn/Tap too. For example, if it uses the lowest interface metric we need to know that so we do not set a hardware interface metric lower than the one we want PIA to use. This is very important as many of these changes are going to be automated and we need to write scripts and code compensating for how PIA's openvpn/Tap install/implementation makes the selection for the hardware network adapter it uses.  

Omnibus_IV

Understood. I guess I misunderstood your original question.

JackO

Finally got an answer from PIA. Its as I suspected, but did not really know because did not know if PIA did anything different in their implementation of openvpn. Had to know for sure. According to PIA:

"At a high level, the physical interface is selected using the OS’s routing table to reach the VPN server’s IP address.  Generally this means that more specific routes are preferred over less specific routes (the default gateway being the least specific of course), and if there’s a tie, a lower route metric is preferred (which is of course influenced by the interface metric)."

But, after some research with information from Microsoft and some openvpn people finally getting back to me while waiting for PIA to answer I'd like to add to that a little more actually correct for specifically Windows 10 which is what I was asking about, and something else that has to be taken into consideration, in case anyone ever has this question again. Beginning with Windows 10 the "preferred" interface is chosen by the OS based upon the sum of the route metric and interface metric (rmet + ifmet). The lowest sum interface is the preferred interface (usually, and should normally be, on the default route). So for example, if the route metric of the TAP is 0 and the Tap interface metric is 3 then 0 + 3 = 3 = sum A, and further if the next lowest is route metric 0 and interface metric 25 then 0 + 25 = 25 = Sum B - so... on VPN the Tap will bind to the next lowest sum interface (if the TAP is the lowest sum which is should be even in systems without multiple physical interfaces) and it will be sum A interface > binds to > sum B interface. The next lowest sum interface after the TAP adapter will be the one with the default route. So although PIA is correct in a way because for systems prior Windows 10 it was that way, in Windows 10 its different and the preferred interface is selected based upon the sum of route metric and interface metric.

In addition to that, the lowest possible interface metric Windows 10 natively automatically sets for interfaces is 10. To set an interface metric lower than 10 you have to do it manually and that's how the TAP adapter gets the lowest interface metric to ensure that your VPN traffic goes through the TAP to the bound interface. When the TAP is installed its interface metric and route metric is manually set in the install lower than interfaces already in the system to ensure the sum for the tap adapter makes it the preferred interface when the VPN is connected. This metric manually set during the TAP install is an interface metric lower then 10  (from 2 to 9) but excluding 1 in windows systems because that's the system loopback adapter and if the TAP interface metric is set to 1 it will be in contention with the loopback adapter and there will be all sorts of weird issues with the VPN if it even works at all. Then that lower sum Tap adapter interface binds to the next lowest sum physical interface in the system and your VPN tunnel with your data inside goes to the PIA VPN private network (thus a private IP address for the TAP adapter - because you have 'joined a private network) through your ISP network via that interface which the TAP adapter binds to out through the gateway you connected to. When you disconnect from the VPN the TAP adapter vanishes from the route table and the interface that was the bind interface goes back to being the lowest sum interface in the route table. So make sure that no other interfaces are set lower in metric than the TAP virtual adapter because it could mean that even though your VPN traffic seems to be ok, it could be leaking out of another interface with a lower metric than the TAP if you have multiple physical interfaces in the system so set up those route and interface metrics carefully.