Why I needed to reinstall nmap:
After a Windows update, nmap stopped showing any results. This happens because Windows removes the Npcap driver that nmap needs to scan. Reinstalling nmap fixes it by reinstalling Npcap.

What I am using nmap for:
To make sure the port 22 of VyOS-R1, R2 and R3 are open so we can ssh a python loop to the ISP.

Command:
nmap -p 22 192.168.56.101 192.168.56.102 192.168.56.103

What nmap showed:
Port 22 of R1 (192.168.56.101) - open
Port 22 of R2 (192.168.56.102) - closed
Port 22 of R3 (192.168.56.103) - closed

Next step:
Enable ssh on R2 and R3 so the Python loop can reach them.

On VyOS-R2 and VyOS-R3, run:
configure
set service ssh port 22
commit
save
exit

Then re-run nmap to confirm all three show 22 open.

The Clone Ghost and the SSH Listen Problem

When you clone a VM in VirtualBox, by default it keeps the same MAC address as the original. VyOS binds an interface name (eth0) to a specific MAC address using the hw-id setting.

So when I cloned R1 to make R3, I ended up with two VMs with the same MAC. VirtualBox then gave R3 a new MAC when I checked "Generate new MAC addresses", but VyOS was still looking for the old MAC for eth0. That's why R3 showed:

"Interface eth0 does not exist" and the new card appeared as eth1 with hw-id 08:00:27:c2:04:05.

The fix was to make VyOS forget the old MAC binding:

configure
delete interfaces ethernet eth0
delete interfaces ethernet eth1
set interfaces ethernet eth0 address 192.168.56.103/24
commit
save

This forces VyOS to recreate eth0 with the new MAC.

Then the second problem: SSH not listening.

I checked all three routers with:

sudo ss -tlnp sport = :22

R2 and R3 showed:
0.0.0.0:22 - which means SSH is listening on ALL interfaces (0.0.0.0).

R1 showed:
192.168.56.101:22 - which means SSH is only listening on that one specific IP.

Why 0.0.0.0 is better for lab routers:
If SSH is locked to 192.168.56.101 and that IP changes or eth0 fails, SSH dies and you are locked out. If it listens on 0.0.0.0, it will work no matter what IP eth0 has. Note: 0.0.0.0 is an address, 0.0.0.0/24 is not valid - you can't use /24 on a listen address.

On R1, SSH had been enabled on 192.168.56.101 like this:
set service ssh listen-address 192.168.56.101

To make it listen on all interfaces (0.0.0.0) I deleted the specific listen-address:

configure
delete service ssh listen-address
commit
save

After that, ss -tlnp showed 0.0.0.0:22 on all three routers - R1 (.101), R2 (.102) and R3 (.103) - and SSH was stable across clones.

*VyOS Lab Fix: R2 IP and SSH Listening Issue *

I had an issue where the IP address disappeared from R2, causing ping to fail
for R1. Nmap was used from Windows to verify SSH availability across the
host-only network.

NMAP SCAN RESULT - Before Fix:
I ran: nmap -p 22 192.168.56.0/24

Results showed:

  • 192.168.56.100 - Host is up, 22/tcp closed ssh - R1 was unreachable
  • 192.168.56.101 - Host is up, 22/tcp open ssh - R2 was partially up
  • 192.168.56.103 - Host is up, 22/tcp open ssh - R3 working
  • 192.168.56.1 - Host is up, 22/tcp closed ssh - Gateway

Nmap done: 256 IP addresses (4 hosts up) scanned in 5.43 seconds

ROOT CAUSE:
On R2 (VyOS-R2), checking show service ssh inside configure mode showed:
listen-address 192.168.56.101
listen-address 0.0.0.0
listen-address 192.168.56.102
port 22

VyOS was configured to listen on specific IPs. When 192.168.56.101 disappeared
from the interface, the SSH service threw a boot config error:
"WARNING: There was a config error on boot: rewrite data."

This caused SSH to fail to bind correctly. Having both 0.0.0.0 (all interfaces)
AND specific IPs creates a conflict if the IP is not present at boot.

THE FIX:
I set the hostname and re-added the IP, then forced SSH to listen on all
interfaces with only 0.0.0.0.

Commands run on R2:

configure
set system host-name VyOS-R2
set interfaces ethernet eth0 address 192.168.56.102/24
commit
save
exit
show interfaces
ping 192.168.56.1

Then fixed SSH listening:

configure
delete service ssh listen-address 192.168.56.101
delete service ssh listen-address 192.168.56.102
set service ssh listen-address 0.0.0.0
commit
save
exit

Verification:
show service ssh (inside configure)

  • Now shows only: listen-address 0.0.0.0, port 22 show listening
  • Shows 0.0.0.0:22 LISTEN

Re-running Nmap now shows all routers with 22/tcp open ssh.

WHY I CAN NOW SSH A PYTHON SCRIPT TO THE ISP:
Because 0.0.0.0:22 means ssh is listening on every active interface, including
192.168.56.102/24 which has connectivity to 192.168.56.1. There is no longer a
dependency on a specific IP being present at boot time, so the service will
not crash if an IP flaps. The Nmap SYN Stealth Scan confirms port 22 is open
and reachable from the Windows host. This stable SSH transport allows me to
use Paramiko / Netmiko in Python to securely push configuration or scripts to
the ISP router at 192.168.56.1.

Next step:
Start syslog on the ISP router to log all incoming SSH sessions and script
execution for auditing.### One more issue before pushing OSPF - standardizing interfaces

Before enabling syslog and OSPF I hit a classic cloning ghost. R1 had its Host-Only IP (192.168.56.101) on eth0, while R2 and R3 had theirs on eth1. This happened because I cloned the VMs in VirtualBox without regenerating MAC addresses, so eth0 was fighting for the same MAC on the Host-Only network. VyOS then wouldn't bring eth0 up reliably on all three.

Instead of fighting it, I standardized everything on eth1. I disabled the unused Adapter 1 in VirtualBox for R1 and enabled Adapter 2 as Host-Only only, so R1 now boots with eth1 only - matching R2 and R3. I then moved the IP:

configure
delete interfaces ethernet eth0 address 192.168.56.101/24
set interfaces ethernet eth1 address 192.168.56.101/24
set interfaces ethernet eth1 description "HOST-ONLY TO WINDOWS"
commit
save
exit
reboot

After reboot, ping to 192.168.56.1 (Windows) worked, but nmap from Windows showed port 22 filtered. That was because sshd was still bound to the old eth0 IP. Fix:

configure
delete service ssh listen-address 192.168.56.101
set service ssh listen-address 0.0.0.0
commit
save

Now verification from Windows:

nmap -p 22 192.168.56.101
nmap -p 22 192.168.56.102
nmap -p 22 192.168.56.103

All three routers show:

PORT STATE SERVICE
22/tcp open ssh

With interfaces consistent and SSH reachable from Windows, I could now push the syslog and OSPF configs without chasing eth0 vs eth1 typos across routers.