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