OpenVPN Support Forum

I posted about this problem a couple of days ago, but I think I may have posted it in the wrong place (I didn’t pick a proper sub-forum) and I have hit upon a solution that may work for me, so I wanted to ask about that here… For reference, if you want to see why I am asking for this you can read my other forum post here (rather than re-posting my issue I will just link it): http://forums.openvpn.net/topic8821.html

Anyhow, due to VPN routing and improper source-IP issues on a multi-homed network, I have found a solution that will solve my issues but I don’t know how to technically implement it…

The solution would involve installing a virtual/software based network adapter, to operate on the same LAN as the physical one… This way I can assign a secondary IP address to the secondary “adapter”, and set up a persistent route on the workstations to route traffic on that interface), which will make sure that the IP traffic being routed uses the proper source IP address for the return traffic..

I thought maybe somehow I could use the tapinstall provided by OpenVPN to create a virtual network adapter on the workstations, but as far as I can tell there is no way for me to simply tell the virtual adapter to attach itself to the physical network (even if I set the link status to always connected).. Then I thought maybe bridging it to the physical adapter is what I needed to do, but that didn’t work either (bridging sort of does the opposite, and turns two separate network adapters into a single adapter with a single IP address/subnet on the bridge only)…

If I could create a separate, secondary adapter in windows and assign it to the new subnet on the physical network, then I can set up my persistent route in windows to target that interface, and that should resolve my source IP problems..

I know that this solution will work, since I have done sort of the same thing using a virtual machine as a test on the foreign network… Simply by creating a secondary NIC on the virtual machine (this looks like a new physical adapter in the windows guest), putting it on the same virtual LAN, and assigning it to the new subnet, and targeting the route for that adapter, I was able to ping from one LAN to the other over the VPN (in both directions)…

I suppose I could implement the same solution by installing a physical adapter on each machine, and wiring it up to the LAN, but obviously a software-based solution using a virtual NIC would be a better way of doing the same thing (without all the extra hardware and wiring)…

Is there a way to install a virtual network adapter to do this (using tapinstall, or some other tool) for windows??

Why using virtual adapter if you can assign another ip and mask to the phisical adapter? In windows an interface can have multiple IPs.

Mimiko wrote:Why using virtual adapter if you can assign another ip and mask to the phisical adapter? In windows an interface can have multiple IPs.

Hello Mimiko, thank you for the reply...

... The reason why we need a second physical (or virtual) adapter here is because we need some sort of method of assigning the proper source IP address for the outgoing network traffic, so they can be addressed properly on the other side of the VPN...

With one adapter and 2 IP addresses, the source IP for outgoing packets will always be the "primary" IP address of the interface used by the route, regardless of anything else.. It seems that with windows while you can specify an interface to use with a static route, you cannot simply specify a source IP address directly on a static route... So, even with a secondary IP address on the interface, the VPN traffic doesn't work because the PCs on our side of the VPN see the traffic coming from their original (not the new) LAN subnet, and we cannot route using their original LAN subnet because of an IP address space conflict (which is why we needed a new subnet on their side to begin with).. We have to see their computers using the IP addresses from the new subnet..

With two adapters (on the same LAN), each with an IP address, the source IP for the outgoing packets will be the IP address of the adapter used as the outgoing interface (in windows, you can specifiy the outgoing interface on a static route by using the 'if' option in the 'route add')... This way we can force the source IP address of the outgoing traffic to be the proper IP address as seen by the other side of the VPN, and the PCs on the other side of the VPN can return the traffic properly based on the routing set up on the other side...

... Seems like a lot of work just to establish the source IP address (and it is)... It would be a lot easier if windows would let you set up a static route with a specified source IP address (and then we wouldn't need the secondary adapter), but instead the only way I know how to get the traffic to formulate properly is to use a secondary interface, and this is why I am looking for a way to install a secondary "virtual" interface on the workstations...

We could skip the secondary subnet alltogether on their network and possibly go with the network address translation (NAT) OpenVPN option on their side (I've never done this, but I know OpenVPN can probably do it), but then we will have issues when it comes to setting up the windows domain trust, and we need the windows trust for some of our network services (like SSRS, and file sharing) to work properly..

... Yes I know Windows creates these un-necesary problems, but we are stuck with it...

The problem could be solved if they re-ip their network for the new subnet, and perhaps they could use their old IP address as a secondary (and then the traffic will route properly using a single interface).. Doing that would lead to them having to re-work their DCHP, DNS, remote clients, and possibly their printer connectivity on their end, and do a lot of testing and break-fixing not just on those workstations but on their network as a whole...

This would be a change to their entire network and we didn't want to force them to do all of that just so a portion of workstation PCs could use our network services.. We wanted to find a way for them just to "add" something to the target workstations (even if that means a virtual network adapter) and not create too much upheaval for them to deal with at this time... Eventually they will re-ip their entire network using our network scheme, but that is too much for them to take on right now, and we were looking for a "simpler" solution...

I see that you don't clearly understant teh networking. Even if you will create a virtual adapter with other IP, the computers will steel go thru the ethernet adapter with primary IP, because of subnet mask. If two sites have overlaping IPs you have to netmask. In linux its easy to do. In windows you have to use some third party software which is rare. In this thread topic8821.html I posted the link to a softwre that I suggest you to try.

Mimiko wrote:I see that you don't clearly understant teh networking. Even if you will create a virtual adapter with other IP, the computers will steel go thru the ethernet adapter with primary IP, because of subnet mask. If two sites have overlaping IPs you have to netmask. In linux its easy to do. In windows you have to use some third party software which is rare. In this thread topic8821.html I posted the link to a softwre that I suggest you to try.

I'm sorry, I must not be explaining it properly...

I dont have overlapping subnets, instead I have 2 different subnets, the one that was there originally (say, 192.168.0.x) , plus the new one I want them to use (10.30.1.x) because their original subnet (192.168.0.x) conficts with another site's subnet.... I wanted to add a second (different) subnet to this new site, and then set up a VPN between the two sites so this remote site can use services at our local site...

Problem is, when the new subnet is set up as a secondary subnet on the adapter, the original subnets IP (192.168) is used as the source IP address, and therefore the traffic on the other side of the VPN gets stuck because it now has this "bad" IP address to return traffic to..

With a second adaptor with the secondary subnet, I can set up a static route to target that adapter, and therefore the secondary subnet is properly used for the source IP...

I know this works for a fact, because I actually tried this on a test workstation with two physical adapters plugged into the same network switch (same vlan)... Once I had two physical adapters on a workstation, and the static route was set up to target the secondary adapter, I was able to sucessfully ping a workstation on the other side of the VPN... With just one adapter, I was not able to ping a workstation on the other side (unless I flipped the IP addresses around, making the new subnet the primary)... It works with two adapters because windows will choose the primary IP address of the interface of the outgoing route, and with windows you can specify a target interface on an outgoing route...

... I was just hoping I could do the same exact thing, except using a virtual adapter instead of a physical one... I would set up the second (virtual) adapter the same I would the second physical one... Windows software would see this virtual adapter the same as it would a second physical adapter, and will therefore choose the primary address of this (virtual) adapter for the outgoing route...

I cant use IP masqurading (or NAT) because a windows domain trust will not work over NAT...

All I really need here is a way to set up a virtual adapter on target workstations at the remote site to keep from having an impact on their entire site... Instead it looks like we are going to re-ip that whole site out there (which is probably for the best anyhow)..

... Thank you much

Dear TPK,

I understood very well the problem. Its a common problem when joining multiple sites. The best way is indeed adjusting ip's on every site so they will not overlap. As a quick solution, linux has builtin NETMASK option. Unfortunally Windows does not have such tools. I proposed you to try one 3rd party solution. I didn't try it, because it may lead to unexpected problems to my corporate network, which I don't whant to have.

So if you are willing to use permanently the VPN - change IP's. It's better to spend time on first, than resolving problems in future.