Firewall NIC Configuration

Those steps are simply some of the first steps, which are commonly done to many machines. Here are a bunch of additional steps that are rather specific to the design that is intended for this system, which will become a firewall.

Firewall System's NIC configuration

Additionally, since this is the firewall system, there are some updates to perform regarding networking. This is not commonplace, because most systems will only need one NIC. However, this system uses 3 NICs: one for communicating with other virtual machines, and two for communication with the physical system that is running the “virtual machine” softare.

Firewall command line updates

Here are some details about adjustments made to the command line to support the additional NICs.

echo VMDirBas=${VMDirBas} VMGenNam=${VMGenNam} VMLILNAM=${VMLILNAM}
echo ${VISUAL}
sudoedit ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/sysstart/exc_${VMLILNAM}

On a side note:

Commentary: Alternate approaches

Note: this part of the directions are heavily dependent on using the public script. If you are not using the publicly available script as a template, then you may need to substantially deviate from these directions. (In that case, see Qemu documentation ( /usr/local/share/doc/qemu/qemu-doc.html ), “Network emulation” section or perhaps Qemu (Wiki) Documentation/Networking. Those who are using the public script may choose to simply follow the instructions from the remaining part of this section of this guide.)

Qemu Wiki documentation, “The legacy -net option” refers to some command line options, which these instructions happen to use. The documentation says, about these options, “This is considered obsolete since QEMU 0.12, although it continues to work.” This guide (containing these instructions) has not been updated to reflect newer syntax.

For those following this guide:

Handling the first NIC type
Newer approach

This is taken care of if VMScrGen is set to 2.

Older approach

Find the lines that sets the VMNICONEVLAN variable.

VMNICONEVLAN=

e.g., maybe it is part of some lines that look like this:

Current example
VMNICONEVLANNUM="1${VMNUM}"
VMNICONEVLAN=",vlan=${VMNICONEVLANNUM}"
VMNICONEALTVLAN=${VMNICONEVLAN}
Older example
export VMNICONEVLAN=,vlan=1"
export VMNICONEALTVLAN=",vlan=1"

Make VMNICONEALTVLAN's value match VMNICONEVLAN's value. One way to do this is to change the line that defines the value of VMNICONEALTVLAN, and just have it refer to the value from the ${VMNICONEVLANNUM} variable. For example, with the “older example”, replace the above lines with these lines (which has no change in the first line)...

export VMNICONEVLAN=,vlan=1"
#export VMNICONEALTVLAN=,vlan=1"
export VMNICONEALTVLAN=${VMNICONEVLAN}

Find the line that says:

VMNICONETYP=default

(Older versions of this startup script had the word export at the start of the line. That word caused a value to unnecessarily remain accessible after the script ends, which was not a particularly problematic thing. The word export is unnecessary, but can be safely ignored in this case, so feel free to simply leave it alone.)

Make it say:

VMNICONETYP=VMNICTUNTAP
Enabling NIC(s) beyond the first one

Use one of the following methods for setting two other NICs.

Newer instructions

Find the lines that say:

VMNICTWOTYP=default
VMNICTHRTYP=default

(Older versions of this startup script had the word export at the start of the line. That word caused a value to unnecessarily remain accessible after the script ends, which was not a particularly problematic thing. The word export is unnecessary, but can be safely ignored in this case, so feel free to simply leave it alone.)

Make them say this instead:

VMNICTWOTYP=VMNICTUNTAP
VMNICTHRTYP=VMNICTUNTAP
Older details

(AT THE MOMENT, these may be skipped...

That should complete adjustments related to the first NIC. For the second two NICs, we'll insert some lines into the Qemu command line.

Find the lines that say this:

 -monitor telnet:127.0.0.1:72${VMNUM},server,nowait \
 -net nic${VMNICONEVLAN},macaddr=52:54:00:12:${VMNUM}:01 \
 ${CLIOPTVMNICONE} \
 ${VMDISP} \

(The first line that was just quoted, and the last line that was just quoted, are simply shown for reference. The main thing to look for is the -net line.)

Insert some lines, so that the result looks like this:

 -monitor telnet:127.0.0.1:72${VMNUM},server,nowait \
 -net nic${VMNICONEVLAN},macaddr=52:54:00:12:${VMNUM}:01 \
 ${CLIOPTVMNICONE} \
 -net nic,vlan=5,macaddr=52:54:00:12:${VMNUM}:51 \
 -net socket,vlan=5,listen=127.0.0.1:${VMNICONETCP} \
 -net nic,vlan=6,macaddr=52:54:00:12:${VMNUM}:61 \
 -net tap,vlan=6,ifname=tun1,script=${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif2,downscript=${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/dnif2 \
 ${VMDISP} \

(So, the new addition contains 4 “ -net ” lines.)

Make sure that the specified MAC-48 addresses will be unique on the system. In the above example, the last digits of the MAC-48 addresses were used to reflect the VLAN number and a reference to which NIC is being used. That's just what the example did, and is not meant to be trying to implement any kind of widespread standard convention. Use whatever methods/patterns you like, as long as the result is a MAC-48 address that will be unique on the link/segment/subnet.

(The virtual machine one: NIC type (Virtual Machine's Networking: Enabling Full Networking on the Local Link) section remains available for review, in case that is helpful at all.)

Rationale: Socket type

There was some thought of trying to do this:

-net socket,vlan=5,mcast=239.0.0.1:43000

instead of:

-net socket,vlan=5,listen=127.0.0.1:43000

Then, for the other machines, the script would try to use:

export VMNICONETYP=VMNICSOCKMCAST

This was rejected. There were hopes that multicast would prove to be more stable then the listen/connect mode. However, multicast resulted in “hairpin” scenarios, which means that the host would receive a copy of the traffic it sent. This completely broke IPv6 due to the “duplicate address detection” (“DAD”) feature. Some review indicated that each operating system could disable the IPv6 “duplicate address detection” feature. However, that removes functionality that could be useful, and may require a different process for each different operating system that is used. A decision was made, which is that the better approach is to avoid the problems in the first place, by not using network communications that are known to break IPv6 DAD.

Rationale: Socket address

The number 43000 is believed to have been chosen from IANA's range of user ports, being rather high (somewhat close to 49151, which is the last of those ports), being relatively easy to remember, and being chosen somewhat randomly.

The only real benefit to using 43000 is that it is the default used by the public script provided by the same resource as this guide.

Only one virtual machine is allowed to listen on the same TCP port on a single system. So if there is another piece of software (like another Qemu machine) that is using 43000, then that number will need to be customized. (Or, if another piece of software will be using TCP port 43000, then the TCP port should be customized to avoid the conflict that could easily occur later.)

To customize the TCP port 43000 port number that is used, locate this line:

export VMNICONETCP="43000"

Choose an unused positive number that is 65535 or less.

Additional file updates

For now, these instructions continue to be meant for the “physical” machine which runs the “virtual machine” software. Actually, at this very moment in the process, there is not even an assumption that the virtual machine is even running. It could still be powered off, and that would be fine.

sudo chown $(id -un) ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/sysstart/exc_${VMLILNAM}
sudo chmod u+gx ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/sysstart/exc_${VMLILNAM}
ls -l ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/sysstart/exc_${VMLILNAM}
sudo mkdir ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/
echo \#!/bin/sh| sudo -n tee -a ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif0
echo \#!/bin/sh| sudo -n tee -a ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/dnif0
echo \#!/bin/sh| sudo -n tee -a ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif2
echo \#!/bin/sh| sudo -n tee -a ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/dnif2
sudo chmod u+x ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/??if?
ls -l ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/
Supporting networking
Setting variables
Overview/Rationale

For this particular part of the entire process of setting up a network, there are a number of commands that need to refer to different TUN/TAP devices. Therefore, this guide uses some variables to minimize how many commands will need the manual effort of customization.

This guide uses the technique of naming TUN/TAP devices with a consistent formula: the number of a NIC, followed by the value of the VMNUM.

This guide decided not to use a variable named VMNUM, because that name is used in many other places. If the value was accidentally left unchanged after work began on a new system, theoretically problems could easily occur (in many other potential spots). So, instead, this guide uses a variable named VMCrTpNm (“virtual machine: current TUN/TAP number”) for the same purpose.

This guide will also create variables for keeping track of each TUN/TAP NIC. That is probably less necessary, but probably simplifies things as well. The guide is also designed around starting with three TUN/TAP devices. There's nothing too magical about the number 3. Even two would allow for much of this guide to work as it was designed. Five would also not be unreasonable (Outside, VMSvrs, Inside Untrusted LAN, Inside Wi-Fi, Inside OKLAN). However, three seemed like a good balance for simplicity and what many networks will want right away.

Setting VMCrTpNm

If you need a quick reminder of the VMNUM value, check documentation or run:

grep -i "VMNUM=" ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/sysstart/exc_${VMLILNAM}
grep -i "VMNUM=" ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/sysstart/exc_${VMLILNAM} | head -1 | cut -d = -f 3
  • Make sure to customize this!
    • The value ought to match the VMNUM used by the “virtual machine” that will be performing firewalling services.
If the automated example above showed the desired VMNUM
export VMCrTpNm=$( grep -i "VMNUM=" ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/sysstart/exc_${VMLILNAM} | head -1 | cut -d = -f 3 )
Otherwise, manually customize this:
  • If a custom approach is needed, proceed with customizing the value.
    export VMCrTpNm=44
echo VMCrTpNm=${VMCrTpNm}
Supporting TUN/TAP device name

Since different operating systems use different NIC names, just specify here what NIC name your operating system uses.

OpenBSD
OSTnDvNm=tun
Infusing variables with TUN/TAP NIC names

This guide shows support for three NICs. (As mentioned in the Rationale/Overview section, that might not be completely ideal, so feel free to customize these instructions if your setup varies.)

VMTpDv1=${OSTnDvNm}1${VMCrTpNm}
VMTpDv2=${OSTnDvNm}2${VMCrTpNm}
VMTpDv3=${OSTnDvNm}3${VMCrTpNm}
echo VMTpDv1=${VMTpDv1}
echo VMTpDv1=${VMTpDv2}
echo VMTpDv1=${VMTpDv3}
Making TUN/TAP

The process of using ./MAKEDEV was seen before (at Preparing for Offspring and Virtual Machine's Networking: Enabling Full Networking on the Local Link), and it is time to do that again.

So, since the firewall has 3 NICs, and because each NIC is using a TUN/TAP device, 3 TUN/TAP devices need to be made. If the VMNUM is 44, the TUN/TAP devices would be 144, 244, and 344...:

ls -l /dev/tun[0-9]*
pwd
cd /dev/
sudo ./MAKEDEV ${VMTpDv1}
sudo ./MAKEDEV ${VMTpDv2}
sudo ./MAKEDEV ${VMTpDv3}
cd ${OLDPWD}
pwd
Supporting bridging

The eventual plan is that the firewall's second NIC will be part of a bridge. This will affect firewall configuration for the “physical machine” (which runs the “virtual machine” software), and gets discussed further when this guide discusses routing in more detail. However, for now, know that the traffic on the second NIC will be part of a bridge.

Interfaces that will be part of a bridge should be marked so that the firewall configuration can know to treat such network traffic uniquely. (Namely, special rules for the firewall configuration will tell the firewall to just allow the traffic, effectively leaving the traffic alone.) As a generalization, a convenient time to identify such network interfaces is when the network interface is created.

ls -l /etc/hostname.${VMTpDv2}
[ -e /etc/hostname.tun244 ] && cpytobak /etc/hostname.${VMTpDv2}
echo group tunbrdge| sudo -n tee -a /etc/hostname.${VMTpDv2}

Placing that line in the text file does not cause the interface to join the group until that text file gets used. That will happen when the system reboots, or when /etc/netstart is used on that network interface, which will probably be happening soon.

Adjusting NIC configuration files : Describing the NICs

The process of customizing the NIC configuration files was seen before (at Preparing for Offspring and Virtual Machine's Networking: Enabling Full Networking on the Local Link), and it is time to do that again.

cd /etc/
ls -l hostname.tun*

Copy the configuration file from another virtual machine's TUN/TAP interface for the virtual machine's first NIC. (If there is a reasonable chance that they are not all the same, then configuration files related to the TUN/TAP device for the “parent” “virtual machine” may be a reasonable choice.)

Also, copy the configuration file from the old virtual machine's TUN/TAP interface for the virtual machine's third NIC. (Do not bother doing this for the second NIC.)

Then, edit the file, and make any changes to the IP addresses(/subnets) that are appropriate.

It is also a good idea to describe each of the TUN/TAP interfaces.

ls -l /etc/hostname.${VMTpDv1}
[ -e /etc/hostname.${VMTpDv1} ] && cpytobak /etc/hostname.${VMTpDv1}
echo description \"NIC \1 of Qemu VMNUM \#\#${VMCrTpNm} ${VMLILNAM} : OutsideVM \(External Net\)\"| sudo -n tee -a /etc/hostname.${VMTpDv1}
echo ${VISUAL}
sudoedit /etc/hostname.${VMTpDv1}

Like the results? Try applying them, and see whether the description shows up nicely for the NIC.

ls -l /etc/hostname.${VMTpDv1}
sudo ${SHELL} -c ". /etc/netstart ${VMTpDv1}"
ifconfig ${VMTpDv1}

Do likewise for the other NICs. Here are some commands for the second one:

ls -l /etc/hostname.${VMTpDv2}
[ -e /etc/hostname.${VMTpDv2} ] && cpytobak /etc/hostname.${VMTpDv2}
echo description \"NIC \2 of Qemu VMNUM \#\#${VMCrTpNm} ${VMLILNAM} : vmSvrs Net of server VMs\"| sudo -n tee -a /etc/hostname.${VMTpDv2}
sudoedit /etc/hostname.${VMTpDv2}

Like the results? Try applying them, and see whether the description shows up nicely for the NIC.

ls -l /etc/hostname.${VMTpDv2}
sudo ${SHELL} -c ". /etc/netstart ${VMTpDv2}"
ifconfig ${VMTpDv2}

This is also the chance to verify that the second NIC has joined the “tunbrdge group.

Do likewise for each remaining NIC. Here are some commands for the third one:

ls -l /etc/hostname.${VMTpDv3}
[ -e /etc/hostname.${VMTpDv3} ] && cpytobak /etc/hostname.${VMTpDv3}
echo description \"NIC \3 of Qemu VMNUM \#\#${VMCrTpNm} ${VMLILNAM} : Internal Nets\"| sudo -n tee -a /etc/hostname.${VMTpDv3}
sudoedit /etc/hostname.${VMTpDv3}

Like the results? Try applying them, and see whether the description shows up nicely for the NIC.

ls -l /etc/hostname.${VMTpDv3}
sudo ${SHELL} -c ". /etc/netstart ${VMTpDv3}"
ifconfig ${VMTpDv3}

If you have more than three NICs, there may be a couple of options. One is to perform the same sort of process on the other NICs, which will require setting some additional variables. The other option may be to just get by with the first three NICs for the time being. (Other equipment might not be usable, for the time being. However, getting some other services operational might be more useful to focus on first. For example, the “automatic addressing” service(s) (e.g. DHCP/IPv4), and “name resolution” (DNS).

Checking the groups

The previous task just added descriptions, and applied them. When applying the descriptions, that should also have adjusted the group for the NIC that will be having the traffic be bridged. You may wish to also check those results. See that the NIC did, indeed, join the group that specifies that the traffic will be getting bridged.

ifconfig ${VMTpDv2} | grep groups:

Placing that line in the text file does not cause the interface to join the group until that text file gets used. That will happen when the system reboots, or when /etc/netstart is used on that network interface, which will probably be happening soon.

Assign IP addresses

The first NIC will be running a DHCP/IPv4 server, so it needs to have an IPv4 address. (The DHCP/IPv4 server” software will not run unless the NIC has an IPv4 address.)

Determine addresses

Check documentation, if needed, to remember what the desired IP addresses are. (May as well plan to handle both IPv6 and IPv4.)

Adjust configuration
cpytobak /etc/hostname.${VMTpDv1}
echo ${VISUAL}
sudoedit /etc/hostname.${VMTpDv1}

Get the IPv6 and IPv4 addresses assigned. (OpenBSD manual page for /etc/hostname.* files) e.g.:

!echo Now configuring ${if}...
!ifconfig ${if} link0
inet6 2001:db8:8::9 126
inet 198.51.100.249 255.255.255.252 NONE
!ifconfig ${if} up

(Actually, to make the file neater, it may be good to place the first of those lines at the top of the file... and maybe even to place more lines, perhaps even all of those lines, at the top of the file.)

(The numbers shown are from the demo subnet. If you're using subnets that are an IPv4 /24 or larger, you may wish to use .1 to match sample numbering shown at system address: early addresses.)

Apply updated config

sudo ${SHELL} -c ". /etc/netstart ${VMTpDv1}"
ifconfig ${VMTpDv1}
Making more DHCP server configuration files

The process of creating a configuration file for a DHCP server was seen before (at Preparing for Offspring and Virtual Machine's Networking: Enabling Full Networking on the Local Link), and it is time to do that again.

cd /etc/
ls -l dhcpd-tun*

  • For the first NIC:
    • Copy the configuration file from the old virtual machine's TUN/TAP interface for the virtual machine's first NIC.
      • Customize this as needed. (It might, actually, not even require any customizing. If there is just one file that matches the wildcard, no customization will be needed when doing this for the first time. However, to be safe, review and customize as needed.)
      echo $( ls -1 /etc/dhcpd-*.conf | head -1 ) /etc/dhcpd-${VMTpDv1}.conf
      sudo cp -pi $( ls -1 /etc/dhcpd-*.conf | head -1 ) /etc/dhcpd-${VMTpDv1}.conf
      • (This sample command, which was just shown, is presuming that the first line of the directory listing (which is the output of the ls command) is the configuration file from the “demonstration” virtual machine (or, maybe even better, the “parent” virtual machine). If that's not the case, adjust the sample as necessary.
    • Edit the configuration file, making any changes to the IP addresses(/subnets) that are appropriate. cpytobak /etc/dhcpd-${VMTpDv1}.conf
      echo ${VISUAL}
      sudoedit /etc/dhcpd-${VMTpDv1}.conf
      • For example, place commands to assign appropriate IP addresses that reflect the “OutsideVM” subnet. This includes the subnet line, any line that says “routers”, and any line that says “fixed-address”. It might be that no changes are needed for any of these things.
      • Update the MAC address to reflect the VMNUM of this machine. (This likely does require a change to be made to the file.)
    • Check DHCP server config sudo dhcpd -n -c /etc/dhcpd-${VMTpDv1}.conf
      echo ${?}
    • Start up the DHCP server
    • sudo dhcpd -c /etc/dhcpd-${VMTpDv1}.conf ${VMTpDv1}
      echo ${?}
    • Verify that the server is running.
      • ps -auxww | grep -i dhcpd-${VMTpDv1}\\.conf | grep -v grep
        Some notes about using ps

        Note that although the above syntax will work okay with OpenBSD, ps syntax differences are significant enough that no single syntax is preferred by all the Unix implementations. Users of other operating systems may need to adjust the example shown. (Common modifications may include taking out the hyphen right after the word ps and/or removing some parameters, such as one or both of the w characters.)

        Multiple redirections are shown. The final redirection is discussed in the section about “Having grep exclude itself”.

    • Check the server's logs.
      Checking logs in OpenBSD
      sudo tail /etc/messages
      • (You won't be able to easily fully verify that the server is operational until the “virtual machine” is started. But these checks can be done.)
  • (Do not bother doing this for the second NIC)
  • Update: Current plan for the third NIC is to ignore it for now. (Do not bother setting up DHCP/IPv4 on it, at this time. Instead, the firewall will be the DHCP/IPv4 server, by running a DHCP/IPv4 Relay.)
    Old info:
    For the third NIC, follow the same process as the first NIC.
    • Copy the configuration file from the old virtual machine's TUN/TAP interface for the virtual machine's third NIC.
    • Edit the configuration file, making any changes to the IP addresses(/subnets) that are appropriate. cpytobak /etc/dhcpd-${VMTpDv3}.conf
      echo ${VISUAL}
      sudoedit /etc/dhcpd-${VMTpDv3}.conf
    • Check the DHCP server config sudo dhcpd -n -c /etc/dhcpd-${VMTpDv3}.conf
      echo ${?}
    • Start up the DHCP server sudo dhcpd -c /etc/dhcpd-${VMTpDv3}.conf ${VMTpDv3}
      echo ${?}
    • Verify that the server is running. Check the server's logs. (You won't be able to easily fully verify that the server is operational until the “virtual machine” is started. But these checks can be done.)
virtual machine NIC configuration scripts (nicscr/.)
Script for first NIC upif0

Update to reflect new IP address/subnets:

ls -l ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/

Make sure this script file is loading DHCP server:

[ -f ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif0 ] && cpytobak ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif0
echo echo Resetting DHCP server for ${VMTpDv1}...| sudo -n tee -a ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif0
echo sudo pkill -f /etc/dhcpd-${VMTpDv1}.conf| sudo -n tee -a ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif0
echo sudo dhcpd -c /etc/dhcpd-${VMTpDv1}.conf ${VMTpDv1}| sudo -n tee -a ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif0
echo echo Done resetting DHCP server for ${VMTpDv1}...| sudo -n tee -a ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif0

The recommended process is to review the script file after the changes have been made.

echo ${VISUAL}
sudoedit ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif0

Here's another command provided for convenience.

ls -l ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/
Old notes

SKIP THIS FOR NOW: Make similar for third NIC.

ls -l ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/
sudo cp -p ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif0 ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif2
echo ${VISUAL}
sudoedit ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif2

SKIP THIS FOR NOW:Make sure this script file is loading DHCP server:

sudo pkill -f /etc/dhcpd-${VMTpDv3}.conf
sudo dhcpd -c /etc/dhcpd-${VMTpDv3}.conf ${VMTpDv3}

Naturally, those references to tun344 should be customized to reflect the TUN/TAP device that is actually being used.

Other/misc files

(Do proceed with this...

ls -l ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/

The second NIC doesn't need to start DHCP on the main system. So the script can look quite a bit different. However, it does need to exist.

This example actually takes care of multiple scripts.

sudo cp -pi ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/dnif0 ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif1
sudo cp -pi ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/dnif0 ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/dnif1
sudo cp -pi ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/dnif0 ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/dnif2

See results:

ls -l ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/
Perform clean-up
unset VMCrTpNm OSTnDvNm VMTpDv1 VMTpDv2 VMTpDv3