Mimiko wroteWhy 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...