Virtual lab route through VPN

VMware specific discussions

[MERGED] SureBackup advanced routing question

Veeam Logoby mdiver » Mon Oct 12, 2015 2:37 pm

Is it possible to have the production network for the routing appliance different from the B&R server itself?

In our case we have B&R server on:
192.168.1.x/24
Gateway: 192.168.1.1

The production network is reachable via the given gateway and has the range:
192.168.2.x/24
Gateway: 192.168.2.1

The proxy appliance in the production network is set to:
192.168.2.10 on the outside and 192.168.2.1 on the inside to act as the gateway of the production network inside the sandbox.

While the SureBackup job is running, the outside of the proxy appliance can be pinged from the Veeam server. So routing of the two real networks is fine.
Also the route to the masquerading range 192.168.255.x is correctly in the routing table with the outside of the proxy appliance as GW.

Though we cannot ping any of the VMs inside the sandbox from the Veeam server. In addition we can't ping from the sandbox to the Veeam server.

I think the problem is the route back from inside the sandbox. Is there any way to tell the proxy appliance that the Veeam server is behind another GW?

Thank you and regards,
Mike
mdiver
Service Provider
 
Posts: 39
Liked: 9 times
Joined: Wed Nov 04, 2009 2:08 pm

Re: SureBackup advanced routing question

Veeam Logoby mdiver » Thu Oct 15, 2015 1:51 pm

Just to clarify - as it seems nobody has understood my lengthy question :roll:

Is it supported to have the SureBackup routing-proxy-appliance in a LAN segment DIFFERENT from the B&R server (so with another routing device inbetween)?

Thanks and regards,
Mike
mdiver
Service Provider
 
Posts: 39
Liked: 9 times
Joined: Wed Nov 04, 2009 2:08 pm

Re: Virtual lab route through VPN

Veeam Logoby tsightler » Thu Oct 15, 2015 2:48 pm

I haven't tested this in a while, but it was certainly possible in previous versions to get this to work and I wouldn't expect v8 to be any different. Whether it's "supported" is a little different story as it involved making routing changes that are outside of Veeam control so it's somewhat difficult to pull that under the realm of "support".

While the SureBackup job is running, the outside of the proxy appliance can be pinged from the Veeam server. So routing of the two real networks is fine.
Also the route to the masquerading range 192.168.255.x is correctly in the routing table with the outside of the proxy appliance as GW.

Though we cannot ping any of the VMs inside the sandbox from the Veeam server. In addition we can't ping from the sandbox to the Veeam server.

This is where I lose you. Since the B&R server is on 192.168.1.x when it tries to ping the VMs in the lab it will attempt to reach them vea 192.168.255.x. Since 192.168.255.x is a different network, it will forward the packet to the GW (192.168.1.1). This gateway will then have to figure out what to do with that packet but most likely doesn't have a route. Where does the packet need to go? Specifically it needs to go to 192.168.2.10, the external interface of the proxy appliance. Does the 192.168.1.1 have a static route telling it to send packets destined for 192.168.255.x to 192.168.2.10?

I'm curious though, based on this simple design it almost seems as if everything is local, why not just put the Surebackup lab on the network with the B&R server? That would eliminate any manual network routeing setup and also any possibility of data leaking from the lab into production.
tsightler
Veeam Software
 
Posts: 4775
Liked: 1740 times
Joined: Fri Jun 05, 2009 12:57 pm
Full Name: Tom Sightler

Re: Virtual lab route through VPN

Veeam Logoby mdiver » Thu Oct 15, 2015 3:10 pm

Thanks for moving the thread to a connected problem and for the reply.
Actually our customer has the B&R server in another physical location connected by a VPN. So quite the same. I just tried to generalize in the first place.

I'm with you that it all should be routing related. Currently I just don't get why it doesn't work OOB as:

- We have a static route to 192.168.255.x which is created by Veeam on B&R server while the job is running. I checked - it's there. Veeam puts the production IP of the routing appliance as the GW for this route.
- The production network 192.168.2.x and the B&R network 192.168.1.x are already properly cross routed through the VPN tunnel.

So e.g. ping to 192.168.255.x from B&R should hop like 192.168.1.y (B&R) -> 192.168.2.z (Proxy Appliance) -> 192.168.255.x -> inside LAB -> 192.168.2.x and now back via proxy appliance and now the normal route.
So the ping routes slightly different than the pong, but should reach the destination.

But I could try it using static routing on the real GW. Wouldn't I have to prevent B&R from adding the route to the B&R servers routing table then?

Thanks,
Mike
mdiver
Service Provider
 
Posts: 39
Liked: 9 times
Joined: Wed Nov 04, 2009 2:08 pm

Re: Virtual lab route through VPN

Veeam Logoby tsightler » Thu Oct 15, 2015 3:44 pm 1 person likes this post

mdiver wrote:- We have a static route to 192.168.255.x which is created by Veeam on B&R server while the job is running. I checked - it's there. Veeam puts the production IP of the routing appliance as the GW for this route.
- The production network 192.168.2.x and the B&R network 192.168.1.x are already properly cross routed through the VPN tunnel.


I think you may be misunderstanding how IP routing works. The static route added to the B&R server won't do anything since the B&R server cannot directly reach the 192.168.2.x network. It will just sit there and be ignored, see more detailed description below.

mdiver wrote:So e.g. ping to 192.168.255.x from B&R should hop like 192.168.1.y (B&R) -> 192.168.2.z (Proxy Appliance) -> 192.168.255.x -> inside LAB -> 192.168.2.x and now back via proxy appliance and now the normal route.

I don't think you mentioned the IP address of the B&R server, but let's just assume it's 192.168.1.10 for this example:

B&R Server: 192.168.1.10
Gateway: 192.168.1.1
Static route to 192.168.255.x via 192.168.2.10

So when the B&R server attempts to send a packet to 192.168.255.x it will look at it's local routing table and find the static route that says it should send that packet to 192.168.2.10, however, it will also find that it has no interface directly attached to that network so it can't actually send a packet destined for 192.168.255.x directly to 192.168.2.x so it will then consider this route "unreachable" and effectively ignore it. It will then fall back to the next route that matches, which will be the default gateway, i.e. 192.168.1.1. When the packet destined for 192.168.255.x is delivered to 192.168.1.1, unless it also has a static route, it will not know what to do with it.

That means the route is for a packet destined for 192.168.255.x is:
192.168.1.10 (B&R) -->192.168.1.1 (GW)-->192.168.2.1 (remote GW)---192.168.2.10 (Proxy)

So both 192.168.1.1, and 192.168.2.1 must both know what to do with a packet that is destined for 192.168.255.x, and they probably have no clue right now.

The "pong" direction is easy since it's destined for 192.168.1.10 which both the 192.168.1.1 and 192.168.2.1 gateway will know how to reach, however, using VPN does potentially add even more complication because, in many cases, the VPN will not even carry traffic for networks that it doesn't know about, such as the 192.168.255.x network. For example on OpenVPN you have to add explicit configuration for all networks that will be routed across the network. So be sure to check that as well.
tsightler
Veeam Software
 
Posts: 4775
Liked: 1740 times
Joined: Fri Jun 05, 2009 12:57 pm
Full Name: Tom Sightler

Re: Virtual lab route through VPN

Veeam Logoby mdiver » Fri Oct 16, 2015 7:51 am

Hi Tom.

Thanks for your reply. You are of course absolutely right. I missed that the gateway specified here is already in a different subnet. No two gateways for one routing table... :)
I'll have the network guys add the static routes fwd and rev on the tunnel/firewall and see how it goes. As I read in the thread above it'll principally work with back routing from the proxy appliance.

Regards,
Mike
mdiver
Service Provider
 
Posts: 39
Liked: 9 times
Joined: Wed Nov 04, 2009 2:08 pm

Previous

Return to VMware vSphere



Who is online

Users browsing this forum: larry and 22 guests