Host-based backup of VMware vSphere VMs.
Post Reply
dood
Enthusiast
Posts: 28
Liked: 4 times
Joined: Aug 23, 2010 12:32 pm
Contact:

Virtual lab route through VPN

Post by dood »

Case ID : 00179835

Hello,

Always trying to get my virtual lab working ...
Here is the network schema : http://www.apnet.fr/veeam_archi.jpg

Veeam support checked everything today and conclude that a route is missing between Veeam backup server and Virtual Lab.
I'm agree with that but before adding route i try a few things :
- Ping from the virtual lab (connecting on the console with root) to the masquerade ip of the virtual server which start on it : no answer
- Ping from the virtual server running on the virtual lab to anywhere (virtual lab, gateway, veeam, ...) : no answer

Could someone let me know which ping tests have to work based on my schema ?
(ping from Veeam Server to Virtual Lab(eth0) work)
chrisdearden
Veteran
Posts: 1531
Liked: 226 times
Joined: Jul 21, 2010 9:47 am
Full Name: Chris Dearden
Contact:

Re: Virtual lab route through VPN

Post by chrisdearden »

I don't recall if the Lab router is set to answer ICMP on any of its interfaces. Putting the lab on a different subnet to the VBR server is quite complex and generally something I'd only recommend for someone who knows their networking pretty well.
dood
Enthusiast
Posts: 28
Liked: 4 times
Joined: Aug 23, 2010 12:32 pm
Contact:

Re: Virtual lab route through VPN

Post by dood »

Hmmm interesting ... but my Veeam Server is not virtualized so i've no other place to put the lab router on :-/
The solution is maybe to rebuild my veeam physical server with a Free ESXI so i can run my virtual lab "localy" ?
tsightler
VP, Product Management
Posts: 6009
Liked: 2843 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Virtual lab route through VPN

Post by tsightler »

The big thing missing is the route to the 192.168.100.0/24 network from the Veeam server. You would need to add routes within your network so that attempts to access this network are routed from the Veeam server, through the WAN, to the vLab. It's possible, but as Chris said, a little bit tricky, especially if your not a network guy. You can also do some clever bridging with OpenVPN or Tinc between two Windows or Linux servers.

The simpler option is probably to just install a B&R server on the side with the vLab.
dood
Enthusiast
Posts: 28
Liked: 4 times
Joined: Aug 23, 2010 12:32 pm
Contact:

Re: Virtual lab route through VPN

Post by dood »

I just add a new route on my VPN link (route all the subnet 192.168.100.x through the vpn).
Veeam B&R can now ping the router interface on the 100 subnet but can't access my VM running in the virtual lab, this makes my crazy.

The simplier option can't unfortunately work for me as my B&R server must be alone on the second physical site (externalized backup).
foggy
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Virtual lab route through VPN

Post by foggy »

dood wrote:Veeam B&R can now ping the router interface on the 100 subnet but can't access my VM running in the virtual lab, this makes my crazy.
Is there a chance of the firewall being active on this VM?
tsightler
VP, Product Management
Posts: 6009
Liked: 2843 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Virtual lab route through VPN

Post by tsightler »

As stated, it's a complex setup. If you can ping the 100 subnet from the B&R server while the Surebackup job is running it really should work assuming all of the other networking is configured correctly. I've actually got this setup configured in my home lab across a network emulator and I've helped several customers get this working as well so it's possible to make it work, but you have to really understand the network of your environment, the vLab, and how the Surebackup job works.
dood
Enthusiast
Posts: 28
Liked: 4 times
Joined: Aug 23, 2010 12:32 pm
Contact:

Re: Virtual lab route through VPN

Post by dood »

foggy wrote: Is there a chance of the firewall being active on this VM?
No firewall but nice try :)
tsightler wrote:As stated, it's a complex setup. If you can ping the 100 subnet from the B&R server while the Surebackup job is running it really should work assuming all of the other networking is configured correctly. I've actually got this setup configured in my home lab across a network emulator and I've helped several customers get this working as well so it's possible to make it work, but you have to really understand the network of your environment, the vLab, and how the Surebackup job works.
Alright, good news that someone make it work.
I'm pretty sure that there's a network misconfiguration but it's a little bit hard to find where as i can't compare with a similar working solution.

Anyway, maybe you have a schema of your home lab (with routes rules you setup) ?

To check vm, Veeam sends requests through the network on 192.168.100.5 (AD01 in my example), when this request is accepted by the Virtual Lab it NAT to 192.168.1.5 in the isolated environnement.
Please correct if i'm wrong :wink:

Another wonderful schema : http://www.apnet.fr/veeam_archi_2.jpg
tsightler
VP, Product Management
Posts: 6009
Liked: 2843 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Virtual lab route through VPN

Post by tsightler »

The one thing that jumps out to me on the diagram is the 192.168.100.253 address on the router on the vLab side. This makes it look like you added a 192.168.100.253 address to the router on the vLab side, but this isn't correct (unless I'm misreading the diagram). The router on the vLab side simply needs to have a route to the 192.168.100.x network via 192.168.1.100 which is the IP address of the vLab proxy. This will cause the router to send all packets destined for 192.168.100.x addresses to the vLab proxy which will then translate those addresses to the "real" addresses in the vLab.
dood
Enthusiast
Posts: 28
Liked: 4 times
Joined: Aug 23, 2010 12:32 pm
Contact:

Re: Virtual lab route through VPN

Post by dood »

I'm making some more tests but i think it seems to work now !!!

The adress 192.168.100.253 on the router is the secondary interface for the .100 subnet, i can't mount a VPN on 2 subnets without defining this interface.
In a working case, should i be able to access "outside" (ie : google or local production network) FROM a virtual lab VM ?
tsightler
VP, Product Management
Posts: 6009
Liked: 2843 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Virtual lab route through VPN

Post by tsightler »

dood wrote:In a working case, should i be able to access "outside" (ie : google or local production network) FROM a virtual lab VM ?
By default behavior, no, you should not. Otherwise it wouldn't really be "isolated". However, you can enable access to websites using a simple proxy that's available on the vLab proxy appliance as described in the following KB article:

http://www.veeam.com/kb1165
dood
Enthusiast
Posts: 28
Liked: 4 times
Joined: Aug 23, 2010 12:32 pm
Contact:

Re: Virtual lab route through VPN

Post by dood » 2 people like this post

Here we go, everything you need to make this work* :

Image

Production site is in one datacenter (site A), Veeam B&R is in an other datacenter (site B)
Veeam B&R is not virtualized.

VPN connections are established through Sonicwall Appliances

I don't give you lots of details about Virtual Lab configuration because there's nothing very specific.
For my example :

Application Group :
AD01 (Active Directory server, 192.168.1.5)

Virtual Lab :
Proxy
- IP address : 192.168.1.110
- Subnet mask : 255.255.255.0
- Gateway : 192.168.1.250
- DNS Server : 192.168.1.5
Networking :
- Advanced
Network Settings :
- IP address : 192.168.1.250
- Mask : 255.255.255.0
- Masquerade IP address : 192.168.100.D


The Veeam B&R server should be able to ping virtual lab VMs when started.
Virtual lab's VM can be pinged through their masquerade IP (ie : 192.168.100.5 for AD01).
So you need to route this subnet on VPN connections.

On Sonicwall, you can make one VPN connection and route n subnet inside.

On the Site A Sonicwall :

Go to "Network/Interfaces", click "Add Interface ..." and set :
Zone : LAN
VLAN Tag : 1
Parent interface : X0 (LAN zone)
IP Address : 192.168.100.1 (any available address on the 100 subnet)
Subnet mask : 255.255.255.0

Assuming you already get your vPN working with only one subnet and would like to add the masquerade subnet :
Just check your VPN Policie, in "Network" tab "Choose local network from list : LAN Subnets"

Finally add a NAT rule :
In "Network/NAT Policies" click "Add ..."
Original Source: Any
Translated Source: Original
Original Destination: 192.168.100.5
Translated Destination: 192.168.1.110
Original Service: Any
Translated Service: Original

On the Site B Sonicall :

Edit your working VPN policie :
In "Network" tab "Choose destination network from list : <predefined object>"
<predefined object> is a address group which contains 2 address objects : obj1 and obj2
Name : obj1
Zone assignement : LAN
Type : Network
Network : 192.168.1.0
Netmask : 255.255.255.0

Name : obj2
Zone assignement : LAN
Type : Network
Network : 192.168.100.0
Netmask : 255.255.255.0


Some things i've read on topics :
- Check VM firewall (disable for testing purpose)
- Check antivirus (Symantec seems to be problematic)

* : not work totally but can ping virtual lab's vm :mrgreen:
dood
Enthusiast
Posts: 28
Liked: 4 times
Joined: Aug 23, 2010 12:32 pm
Contact:

Re: Virtual lab route through VPN

Post by dood »

tsightler wrote: By default behavior, no, you should not. Otherwise it wouldn't really be "isolated". However, you can enable access to websites using a simple proxy that's available on the vLab proxy appliance as described in the following KB article:
http://www.veeam.com/kb1165
Fine, so no issue here.
dood
Enthusiast
Posts: 28
Liked: 4 times
Joined: Aug 23, 2010 12:32 pm
Contact:

Re: Virtual lab route through VPN

Post by dood »

Get some time to try to make this thing work.

My virtual lab's VM starts now successfully but except ICMP frames no TCP traffic seems to pass (telnet from Veeam B&R to 192.168.100.5:389 fail).

Telnet tests work fine to the production VM (from the Veeam B&R server and through the same VPN), so no software firewall/antivirus issue
When trying same test with ICMP packet, i get a 100% success.

The NAT rule which i define on my firewall apply to all services (TCP, UDP, ICMP).

I run packet monitor on the production and veeam routers and it seems that everything is fine :
Image

Does ICMP and TCP frames are processed in a different way by the virtual lab ?
foggy
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Virtual lab route through VPN

Post by foggy »

ICMP and TCP traffic is processed by the virtual appliance in the same way, so masquerade addresses should be accessible by both protocols. Seems like something environmental, I recommend to ask support for assistance.
mdiver
Veeam Legend
Posts: 201
Liked: 33 times
Joined: Nov 04, 2009 2:08 pm
Location: Heidelberg, Germany
Contact:

[MERGED] SureBackup advanced routing question

Post by mdiver »

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
Veeam Legend
Posts: 201
Liked: 33 times
Joined: Nov 04, 2009 2:08 pm
Location: Heidelberg, Germany
Contact:

Re: SureBackup advanced routing question

Post by mdiver »

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
tsightler
VP, Product Management
Posts: 6009
Liked: 2843 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Virtual lab route through VPN

Post by tsightler »

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.
mdiver
Veeam Legend
Posts: 201
Liked: 33 times
Joined: Nov 04, 2009 2:08 pm
Location: Heidelberg, Germany
Contact:

Re: Virtual lab route through VPN

Post by mdiver »

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
tsightler
VP, Product Management
Posts: 6009
Liked: 2843 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Virtual lab route through VPN

Post by tsightler » 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.
mdiver
Veeam Legend
Posts: 201
Liked: 33 times
Joined: Nov 04, 2009 2:08 pm
Location: Heidelberg, Germany
Contact:

Re: Virtual lab route through VPN

Post by mdiver »

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
Post Reply

Who is online

Users browsing this forum: No registered users and 81 guests