Surebackup routing issue from v8 patch 2

[marc.rousseau]

Hello,

I use the Surebackup feature for several months to mount virtual labs for our development team.
Our virtual labs contains 2 or 3 isolated Vlans routed by veeam proxy appliance.
Everything worked perfectly until I installed patch 2. Since patch2, routing of isolated vlans doesn't work anymore: VM1 in isolated VLAN1 cannot ping VM2 in isolated VLAN2, although the checkbox "Route network traffic between vNICs" is checked.
It's obviously not a configuration problem, because we always use the same parameters for our virtual labs.

ISO image of Veeam proxy appliance has changed and after investigating inside veeam proxy appliance, I identified the source of my issue :

Veeam v8 patch1 proxy appliance
# iptables -t mangle -L -v -n
Chain PREROUTING (policy ACCEPT 11059 packets, 1764K bytes)
pkts bytes target prot opt in out source destination
0 0 MARK all -- lo * 0.0.0.0/0 !127.0.0.1 MARK set 0x2
5854 869K MARK all -- eth1 * 0.0.0.0/0 !10.32.1.254 MARK set 0x2
3585 769K MARK all -- eth2 * 0.0.0.0/0 !10.32.2.254 MARK set 0x2
0 0 MARK all -- eth0 * 0.0.0.0/0 10.32.6.8 MARK set 0x6
0 0 MARK all -- eth0 * 0.0.0.0/0 10.32.6.9 MARK set 0x6
0 0 MARK all -- eth0 * 0.0.0.0/0 10.32.6.11 MARK set 0x6
0 0 MARK all -- eth0 * 0.0.0.0/0 10.251.5.0/24 MARK set 0x6
0 0 MARK all -- eth0 * 0.0.0.0/0 10.251.4.0/24 MARK set 0x6


Veeam v8 patch2 proxy appliance

# iptables -t mangle -L -v -n
Chain PREROUTING (policy ACCEPT 14928 packets, 1097K bytes)
pkts bytes target prot opt in out source destination
0 0 MARK all -- eth0 * 0.0.0.0/0 10.32.6.8 MARK set 0x6
0 0 MARK all -- eth0 * 0.0.0.0/0 10.32.6.9 MARK set 0x6
0 0 MARK all -- eth0 * 0.0.0.0/0 10.32.6.11 MARK set 0x6
0 0 MARK all -- eth0 * 0.0.0.0/0 10.251.5.0/24 MARK set 0x6
0 0 MARK all -- eth0 * 0.0.0.0/0 10.251.4.0/24 MARK set 0x6

3 lines are missing from iptables. These lines are responsible for internal routing traffic tagging (MARK set 0x2)

To fix my isolated Vlan routing issue, I just need to run these lines:
iptables -t mangle -A PREROUTING -i lo ! -d 127.0.0.1 -j MARK --set-mark 2
iptables -t mangle -A PREROUTING -i eth1 ! -d 10.32.1.254 -j MARK --set-mark 2
iptables -t mangle -A PREROUTING -i eth2 ! -d 10.32.2.254 -j MARK --set-mark 2

So why these lines are missing since patch2 installation ?
It seems there's a little bug into startup script "/etc/init.d/network/network-up.sh" of veeam proxy appliance

Code: Select all

if [ ! -f $FLR_FLAG_FILE ]; then
    if [ `xmlstarlet sel -t -v "settings/nat/enable_internal_routing" $CONFIG_FILE` = "true" ]; then
        ENABLE_INTERNAL_ROUTING=1;
    fi
fi
(….)
        if [ $ENABLE_INTERNAL_ROUTING ]; then
            iptables -t mangle -A PREROUTING -i $PHYS_DEV \! -d $IP -j MARK --set-mark 2
        fi

The problem is : FLR_FLAG_FILE is not declared or is missing. A possible way to fix this problem could be :

Code: Select all

if [ -z $FLR_FLAG_FILE ] || [ ! -f $FLR_FLAG_FILE ]; then

instead of

Code: Select all

if [ ! -f $FLR_FLAG_FILE ]; then

So I decided to rebuild Veeam proxy appliance ISO image.
Grab ISO file here : C:\Program Files\Veeam\Backup and Replication\Backup\LiveCD\drv-va.iso , copy it on a linux computer and follow this (at you risk) :

Code: Select all

mkdir iso
mount -t iso9660 -o loop drv-va.iso iso/
mkdir newiso

cp iso/* newiso/
umount iso/

cd newiso/

mv initrd.img initrd.gz
gunzip initrd.gz
mkdir tmp
cd tmp
cpio -id < ../initrd
vi etc/init.d/network/network-up.sh

comment this line : #if [ ! -f $FLR_FLAG_FILE ]; then
add this line below : if [ -z $FLR_FLAG_FILE ] || [ ! -f $FLR_FLAG_FILE ]; then

find . | cpio --create --format newc > ../newinitrd
cd ..

rm initrd
mv newinitrd initrd
gzip initrd
mv initrd.gz initrd.img

rm -rf tmp

mkisofs -R \
-no-emul-boot -boot-load-size 4 \
-boot-info-table -joliet-long \
-o ../NEWISO.iso \
-b isolinux.bin \
-c boot.cat \
-V "CDROM" .

Finally copy your new image NEWISO.iso in folder "C:\Program Files\Veeam\Backup and Replication\Backup\LiveCD" and rename it "drv-va.iso"
Edit your virtual lab to force veeam to reupload the new image into vmware, start your sure backup job

No more internal routing issue.
I hope this post could help people having the same issue as me with sure backup since patch2 ...

Marc

[bbomgardner]

Thanks, Marc! This is exactly the trouble I was having in my lab. I was about to dig into it this morning when a colleague pointed me to your post.

[marc.rousseau]

I am pleased that my post has helped you Ben !

[foggy]

Marc, thanks for sharing, much appreciated. Actually, QA is aware of this and those lines should be put back in the next major update.

[ara686]

Hello,

I think that we have a same problem.
Exists any official update for this?

Regards

Jirka

[foggy]

Jiří, you can take my previous post as an official update.