Routing problem on multi-homed network

TPK

Hello all

First, let me apologize if this has been posted before… I would think that I am not the first to have this problem, but I guess I just haven’t been able to find an example of this type of problem…

Here is what I am trying to do:

We are running a centralized network, which serves several (separate) organizations with a windows based enterprise software… Some of these organizations do not have very strong IT infrastructures or full time IT directors, etc., and usually they don’t even have full time IT staff at all, so really I cannot ask them to do too much on their end, etc.. Generally what we do is we set up a point-to-point from our centralized network over to their location, and set up routing and a windows domain trust, so they have access to a bunch of network services on our network..

So far we have been lucky, in that none of these organizations have had conflicting IP address subnets (one was using 192.168.0.x, another was using 172.x, etc..), so therefore we have been able to set up the routing, dns forwarding, windows domain trust, database access, file shares, etc. just fine between our central network and all of these LANs at these other organizations.. Usually we have been using point-to-point setups via the telcoms, but now we have a situation (due to distance) where an OpenVPN tunnel over the internet would make much more sense…

Our centralized network is on a 10.20.1.0/24 LAN, and we have subnets carved out in the 10.x address space for each organization, and future organizations to join later. The idea being that these organizations would eventually re-ip to the new address scheme in the 10.x address space… Of course no one has actually re-ipd yet, since a project like that is beyond the scope of what they can do…

A new organization has just joined this consortium, and naturally they are using a 192.168.0.x/24 subnet.. So now we have an issue where we really cannot get away with just routing to their native subnet anymore… I also do not think they can re-ip their entire network at this time (perhaps they can next summer during the not-so-busy season)…

So my idea was, rather than forcing them to re-ip their network right away, that we would multi-home the PCs and Servers that need to talk to our network with an alternate IP address on the same adaptor in the new subnet (10.30.1.0/24), and then set up a VPN tunnel to connect their site to ours… This way, our network will see their network on another 10.x, and they would see our network on a different 10.x subnet… Not all of their PCs and servers require to communicate to our network, but a bunch of them do… Meanwhile all of their PCs (including the ones we need to multi-home) do of course have to talk to their local servers and routers and printers, etc, which are on their native 192.168 network..

So, to recap:

Our central network: 10.20.1.0/24
Their native network: 192.168.0.0/24
Their alternate network: 10.30.1.0/24

Anyhow, I set up an OpenVPN tunnel (I am using a windows virtual machine on both ends to act as an openVPN server/client) between the two networks…

The VPN server on their side is set up with IP addresses on both of their subnets (192.168, and 10.30), and the VPN server on our side naturally is on our single (10.20) local subnet.

I know for sure that the VPN tunnel is working just fine (I can provide the config files, but I don’t think its really necessary since I know the tunnel is working)… I have test workstations on both sides of the tunnel, and I can ping each workstation from the other, over the tunnel, provided I set things up just right…

To set things up just right, I first set up the static routes on the two workstations to route traffic destined for the other network to each sides’ VPN server (naturally), but now the problem is that in order for the routing to work right, I have to set up the test workstation on their side to use the 10.30 address as the PRIMARY address of that workstation on the network… While that is fine as a test case, I think this would really mess things up on their end if they roll that out to all the PCs and servers (they will have connectivity problems on the network on their side)…

Ideally, we would set up the workstations so that the new IP is set up as the ALTERNATE IP address, rather than the primary on the workstation adaptors... This way they can keep everything the same (their routers, printers, servers, DHCP, etc..) and just add in the new subnet to those workstations and servers that need to talk to our network (either manually as static IP addresses, or if possible it would be nice if the adaptors can receive a secondary IP address via DHCP, but that’s a topic for a later time)…

Anyhow, when the IP on the 10.30 subnet is set up as the alternate, the VPN tunneling no longer works… I can only assume that this is happening because the new IP address is not being used as the source address, when traffic is directed to our centralized network... So what happens is the traffic (say a ping from their workstation to our servers) is being routed to the VPN server on their side (via the route add we did earlier), then tunneled over to the VPN server on our side, and then sent to the destination server on our side, but when the server tries to return the ping it cannot because now it has the 192.168 address for the return ping (since its the primary address on that adapter), and so the ping dies because it cannot make its way back because its not the correct subnet..

It would be GREAT if we could set up the static route on their end so we can specify the source IP address to be the proper 10.30 address when that routing rule is used, and this is what I originally thought the interface (IF) argument was for on the route add command.. But now I understand that the IF argument can only be used to specify the physical interface, and not the source IP address for the routed network traffic, so now I am stuck..

I suppose I have rambled on long enough… Given my situation here and what I am trying to accomplish, does anyone have any suggestions for me??? I suppose if we have to we will go and re-ip their network over there, but we really don’t want to take that project on right now if there is something simpler we could try first…

Is there any way at all to somehow specify the source IP address on a route rule like that?? Are we going to have to employ NAT somehow or something like that (I hope not)??

Should I just ditch the whole idea of a corporate to corporate tunnel and just go with separate VPN connections from each client and from each server over to our VPN server (I really hope not!)??

It seems like such a simple problem to overcome (just use the proper source IP based either on the destination's subnet, or which routing rule is used), but apparently it is not as simple as I thought it was going to be...

Can anyone help??

… I look forward to anyone’s suggestion..

.. Thank you

TPK

Woud installing a "virtual" adapter on the client PC(s) that connects to the physical adapter with the secondary subnet solve my problem??

i.e. if windows "sees" another interface, then I can push a static route for the 10.x subnet to that interface (using "if" in the route add), and therefore the packet souce would be selected correctly based on that adapter...

Is that possible???

Can I use "tapinstall" to isntall a virtual adapter that connects to the physical adapter to do this??? Or is there some other method??

Mimiko

On every client you can set the second ip for the phisical network adapter with the desired IP pool from 10.30.1.0/24.

Also, if the computer on wich you install OpenVPN client is also a gateway for those problematic computers, you can try netmaping. In linux it simple,but in windows is not straight forward. You can try the software that I found: http://www.kobore.net/soft/pipmasq/. I didnt use it so does not know if it will do the jub. Read the manual of that software and try.

Good luck.