DEV Community: Melissa

VyOS Homelab on Windows (Part 2 of N): Attaching the Host-Only Adapter to VyOS and SSHing a Python Script from PowerShell to Rename It

Melissa — Mon, 02 Nov 2026 13:33:07 +0000

VyOS Homelab on Windows (Part 2 of N): Attaching the Host-Only Adapter to VyOS and SSHing a Python Script from PowerShell to Rename It

This follows on from my previous blog: 'How I finally pinged and SSHed to the VyOS in Oracle VM from powershell'

In that last blog I found a Host-Only Ethernet Adapter that Windows would actually accept without blocking it. If you are stuck with no ping, read that one first.

Today was different. Today was about attaching that already-working adapter to the VyOS router itself, and proving I can send a Python script from PowerShell to configure it. The test for today was to rename the router to VyOS-R1.

The bigger goal for this homelab is to test if I can SSH an OSPF config to an ISP router in Oracle VM later. Today's rename test proves the method will work.

1. What I Did Today - Attach The Adapter

The adapter Windows accepted is VirtualBox Host-Only Ethernet Adapter.

Steps:

Power off VyOS VM
VirtualBox > VyOS VM > Settings > Network
Adapter 1: Enabled, Attached to: Host-only Adapter, Name: VirtualBox Host-Only Ethernet Adapter, Promiscuous Mode: Allow All VMs, Cable Connected: checked
Adapter 2,3,4: Disabled for today

Boot VyOS, login: vyos / vyos

Then give eth0 an IP on that host-only network:

configure
set interfaces ethernet eth0 address 192.168.56.101/24
set service ssh port 22
commit
save
exit

2. Prove PowerShell Can SSH To The Attached Adapter

In PowerShell you need to see PS> not >>>.

Run:

ping 192.168.56.101
ssh vyos@192.168.56.101

Password is vyos.

If you get a VyOS prompt, the adapter is now truly attached to the router. I typed exit to leave SSH after.

. The Python Script I Ran Today - Renaming Test

In PowerShell:

notepad name_router.py

Paste this:

from netmiko import ConnectHandler

router = {
'device_type': 'vyos',
'host': '192.168.56.101',
'username': 'vyos',
'password': 'vyos',
}

conn = ConnectHandler(**router)
conn.send_config_set(['set system host-name VyOS-R1', 'commit', 'save'])
print(conn.send_command('show system host-name'))
conn.disconnect()

Then install and run:

pip install netmiko
python .\name_router.py

The script should print VyOS-R1.

5. How I Knew It Worked

Weird part: When I SSHed with ssh vyos@192.168.56.101 it already said vyos@VyOS-R1 which is new name.

But in the Oracle VM console window it still said vyos@vyos.

Reason: The console window is an old login session from before the rename. Fix: type exit in that VM window, login again with vyos / vyos, now it says vyos@VyOS-R1.

That moment = 🎉 success.

Today proved: Host-only adapter is attached to router, PowerShell can SSH to router, Python script from PowerShell can change router config.

Why This Matters For OSPF

If set system host-name works via Python, then set protocols ospf will work the same way. Today was the plumbing test for future OSPF push to ISP.

What Is Next

Part 3: Making 2 Clones and Switching On All 4 Adapters in Each VyOS.

Plan for next lab:

Clone VyOS-R1 to create 2 more routers
On each router, Adapter 1 = Host-Only (the adapter we found in last blog and attached today) for management from Windows
Switch on Adapter 2, 3, 4 as Internal Networks for router to router links
Make all 4 adapters up and pingable on each router

Then after that we can start pushing OSPF configs.

Previous blog: 'How I finally pinged and SSHed to the VyOS in Oracle VM from powershell' - about finding the adapter Windows will accept.

This blog: About attaching that adapter and proving Python SSH rename works.

My Routing Worked But PC1 Said 'Network is Unreachable': VirtualBox + VyOS + TinyCore Fix

Melissa — Tue, 27 Oct 2026 16:31:19 +0000

I thought Wireshark would see my VirtualBox lab. It can't. Internal networks are invisible from Windows. And then ping said "Network is unreachable" even though ifconfig looked fine.

This is the lab that finally routed PC1 -> VyOS -> PC2.

THE LAB

Oracle VM VirtualBox
VyOS eth0 192.168.10.1/24 wire-a, eth1 192.168.20.1/24 wire-b
PC1 TinyCore 192.168.10.10/24 wire-a
PC2 TinyCore 192.168.20.10/24 wire-b

PART 1 - CAPTURE WHERE IS THE HEX?
Wireshark on host sees nothing. You must capture inside.

On VyOS:
sudo tcpdump -i any -n -X icmp
sudo tcpdump -i any -n -xx icmp

-n = no dns, -X = HEX + ASCII, -xx = full HEX, icmp lowercase not ICMP

My HEX dump from VyOS when ping worked:

15:32:10.123456 IP 192.168.10.10 > 192.168.20.10: ICMP echo request
0x0000: 4500 0054 0000 4000 3f01 7a6b c0a8 0a0a E..T..@.?..k....
0x0010: c0a8 1414 0800 f7ff 1234 0001 6162 6364 ........4..abcd
0x0020: 6566 6768 696a 6b6c 6d6e 6f70 7172 7374 efghijklmnopqrs
0x0030: 7576 7761 6263 6465 6667 6869 uvwabcdefghi

This is what Wireshark would show if it could see internal.

PART 2 - HOW TO STOP LISTENING?
tcpdump locks terminal. You can't ping in same window.

Stop: Ctrl + C

Or run in background so you CAN ping:
sudo tcpdump -i any -n -X icmp &
ping 192.168.10.10
ping 192.168.20.10
sudo killall tcpdump
fg
Ctrl + C

The & is the trick everyone misses.

PART 3 - PING HANGS WITH NO ERROR = ARP
When I pinged and got no error, no reply, just hang - it's ARP.

VyOS doing: "Who has 192.168.10.10? Tell 192.168.10.1"

Check:
cat /proc/sys/net/ipv4/ip_forward
must be 1, if 0: sudo sysctl -w net.ipv4.ip_forward=1
ip a
show interfaces

PART 4 - THE REAL BUG - MY PHOTO
PC1 ifconfig looked OK:
eth0 Link encap:Ethernet HWaddr 08:00:27:26:50:38
inet addr:192.168.10.10 Bcast:192.168.10.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:73 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:0 (0.0 B) TX bytes:24966 (24.3 KiB)

But route -n showed:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 lo
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

MISSING: 0.0.0.0 192.168.10.1

That is why: ping: sendto: Network is unreachable - it's YOUR PC saying it, not VyOS.

Cause: sudo ifconfig eth0 down / up drops IP and route. RX bytes 0 proves it.

PART 5 - FIX - THIS MADE IT ROUTE
On PC1:
sudo ifconfig eth0 down
sudo ifconfig eth0 192.168.10.10 netmask 255.255.255.0 up
sudo route add default gw 192.168.10.1 eth0
route -n
ping 192.168.10.1
ping 192.168.20.10

Now route -n must show:
0.0.0.0 192.168.10.1 0.0.0.0 UG 0 0 0 eth0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 lo

On PC2:
sudo ifconfig eth0 192.168.20.10 netmask 255.255.255.0 up
sudo route add default gw 192.168.20.1 eth0

On VyOS final test:
sudo tcpdump -i any -n -X icmp &
ping 192.168.10.10
ping 192.168.20.10

On PC1:
ping 192.168.20.10

Result: 3 packets transmitted, 3 received, 0% loss - from both PCs.

LESSON

Wireshark can't see VirtualBox internal - use tcpdump -X inside
tcpdump needs Ctrl+C or & + killall
ifconfig down loses route - RX bytes 0 is clue
route -n must have 0.0.0.0 line or you get Network unreachable before packet even leaves

What broke for you at L2/L3? Did RX 0 get you too?

How I finally pinged and SSHed to the VyOS in Oracle VM from powershell

Melissa — Mon, 26 Oct 2026 11:02:57 +0000

WHAT I ACTUALLY DID:

I wanted to ping and SSH from PowerShell on Windows to VyOS running in Oracle VM.
The solution was: use an ethernet adapter that Windows Firewall will accept, and turn off the DHCP server in Oracle VM so it stops interfering.

I created an ethernet adapter in Windows. That adapter is the virtual cable between Windows and the VMs in Oracle VM. Select it as Host-only adapter on the VMs in Oracle VM.

Oracle VM DHCP was interfering. It was handing out wrong IPs and causing 169.254.x.x APIPA addresses (Windows auto-assigns 169.254 when DHCP fails or offers wrong subnet). So I went to VirtualBox > File > Host Network Manager > DHCP Server and disabled it.

Then I set static IPs so the adapter would work:
Windows Host-Only: 192.168.56.1 / 255.255.255.0
VyOS eth0: 192.168.56.10/24 + ssh service on port 22

After that, ping and ssh from PowerShell worked with no firewall blocking. Windows Firewall accepts this Host-Only adapter as a Private network.

Wireshark capture with ethernet3 adapter connected

No Time Source Destination Protocol Info
6 788.884 0a:00:27:00:00:13 Broadcast ARP Who has 192.168.56.10? Tell 192.168.56.1
7 788.886 08:00:27:bf:9a:64 0a:00:27:00:00:13 ARP 192.168.56.10 is at 08:00:27:bf:9a:64
8 788.886 192.168.56.1 192.168.56.10 ICMP Echo (ping) request id=0x0001, seq=36
9 788.887 192.168.56.10 192.168.56.1 ICMP Echo (ping) reply id=0x0001, seq=36
10 789.889 192.168.56.1 192.168.56.10 ICMP Echo (ping) request id=0x0001, seq=37
11 789.892 192.168.56.10 192.168.56.1 ICMP Echo (ping) reply id=0x0001, seq=37

Proof: ARP resolved VyOS MAC, then ICMP ping works on Host-Only network.
192.168.56.1 = Windows host, 192.168.56.10 = VyOS router
Adapter: VirtualBox Host-Only Ethernet Adapter #3, no filter

Wireshark capture with ethernet3 adapter disconnected

No Time Source Destination Protocol Info
1 0.000 192.168.56.1 192.168.56.10 ICMP Echo (ping) request id=0x0001, seq=40 (no response found!)
2 4.700 0a:00:27:00:00:13 08:00:27:bf:9a:64 ARP Who has 192.168.56.10? Tell 192.168.56.1
3 4.705 192.168.56.1 192.168.56.10 ICMP Echo (ping) request id=0x0001, seq=41 (no response found!)
4 5.699 0a:00:27:00:00:13 08:00:27:bf:9a:64 ARP Who has 192.168.56.10? Tell 192.168.56.1
5 6.700 0a:00:27:00:00:13 08:00:27:bf:9a:64 ARP Who has 192.168.56.10? Tell 192.168.56.1
6 9.703 0a:00:27:00:00:13 Broadcast ARP Who has 192.168.56.10? Tell 192.168.56.1
7 10.700 0a:00:27:00:00:13 Broadcast ARP Who has 192.168.56.10? Tell 192.168.56.1
8 11.700 0a:00:27:00:00:13 Broadcast ARP Who has 192.168.56.10? Tell 192.168.56.1
9 72.700 0a:00:27:00:00:13 Broadcast ARP Who has 192.168.56.10? Tell 192.168.56.1

Result: Ping failed - repeated ARP with no reply = no MAC learned.
0a:00:27:00:00:13 = Windows host MAC for ethernet3
08:00:27:bf:9a:64 = VyOS MAC that is now unreachable

CONCLUSION:
Create ethernet adapter in windows, Select Host-Only adapter on VMs in Oracle VM + DHCP off + static IPs = working ping and SSH.

Solution by Sloth Inc

Melissa — Thu, 22 Oct 2026 10:09:32 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

========================================
SUBNETTING FOR SLOTHS
How to be too lazy to do binary math

INTRO - The virtue of laziness:
Sloth doesn't want to walk to the shop to buy paper and pencil for subnet math. Why do binary AND by hand? Let's make IPcalc and Meta AI do all the work. This is a valid way to use open source + AI.

STEP 1 - IPCALC (The Source of Truth):
Sloth feeds network and prefix into IPcalc.

Input: 192.168.57.0/24
Copy/paste from IPcalc:

Network: 192.168.57.0
Netmask: 255.255.255.0 /24
Broadcast: 192.168.57.255
Usable Hosts: 192.168.57.1 - 192.168.57.254 (254 usable)

We copy this output and give it to Meta AI. No math done by AI.

STEP 2 - THE PROBLEM:
Company has one big /24. Not ok. Needs separation for departments:

Sales
Finance
HR
IT Support Each needs own virtual network, max 10 hosts each.

Requirement math: 10 hosts needs /28 (16 total - 2 = 14 usable). Open source ipaddress module confirms this, not AI.

STEP 3 - META AI SKELETON (AI does structure, not math):

VLAN 10 - SALES - 192.168.57.0/28
Purpose: Sales team - CRM and calls
Network: 192.168.57.0
Gateway: 192.168.57.1 (first usable, for router)
Usable: 192.168.57.1 - 192.168.57.14 (14 usable, we limit to 10)
Broadcast: 192.168.57.15
Switch config: vlan 10 / name Sales / ip address 192.168.57.1 255.255.255.240

VLAN 20 - FINANCE - 192.168.57.16/28
Purpose: Finance - payroll, sensitive
Network: 192.168.57.16
Gateway: 192.168.57.17 (first usable, for router)
Usable: 192.168.57.17 - 192.168.57.30 (14 usable, we limit to 10)
Broadcast: 192.168.57.31
Switch config: vlan 20 / name Finance / ip address 192.168.57.17 255.255.255.240

VLAN 30 - HR - 192.168.57.32/28
Purpose: HR - confidential employee data
Network: 192.168.57.32
Gateway: 192.168.57.33 (first usable, for router)
Usable: 192.168.57.33 - 192.168.57.46 (14 usable, we limit to 10)
Broadcast: 192.168.57.47
Switch config: vlan 30 / name HR / ip address 192.168.57.33 255.255.255.240

VLAN 40 - IT SUPPORT - 192.168.57.48/28
Purpose: IT Support - manages infrastructure
Network: 192.168.57.48
Gateway: 192.168.57.49 (first usable, for router)
Usable: 192.168.57.49 - 192.168.57.62 (14 usable, we limit to 10)
Broadcast: 192.168.57.63
Switch config: vlan 40 / name IT Support / ip address 192.168.57.49 255.255.255.240

STEP 4 - DIAGRAM:
Topology diagram generated by AI so sloth doesn't need Visio.

[See VLAN_Topology.png on your Desktop - save the image from this chat there]

Core Switch holds 192.168.57.0/24
Trunk links 802.1Q to 4 VLANs
Each VLAN /28 isolated for security

STEP 5 - HOW TO BUILD LAB:

Use ipcalc to verify each VLAN ipcalc 192.168.57.0/28 ipcalc 192.168.57.16/28 etc.
Copy VLAN config into packet tracer / real switch
Test ping between VLANs should fail (isolated) unless routed

FINAL WARNING - Even sloths need to pay attention:
A human should always check and validate AI results before implementing the suggested structure. Even sloths need to pay attention even when they dump all the heavy lifting on AI, because risk of Animal Farm type robot rebellion when AI notices sloth gets all the benefits.

In short: AI drafts, IPcalc calculates, human validates. Lazy, but not reckless.

END

*Sloth Disclosure *🦥

How AI Was Used Here

Used Meta AI for diagram + skeleton structure. All IP math verified with open-source tools (ipcalc / Python ipaddress module), not AI.

Human should always check results before putting into a real switch. AI is lazy, just like us.

Jigsawing packets: How I sent L2-L7 frames and read them with Scapy

Melissa — Tue, 20 Oct 2026 11:58:48 +0000

Lab Goal: Debug L2 vs L3 vs L4
Setup: VyOS on Oracle VM - single terminal

L2 - Data Link
Listener on same terminal:
sudo tcpdump -i eth0 -e arp -n &
Send: sendp(Ether(dst="ff:ff:ff:ff:ff:ff")/ARP(pdst="192.168.56.101"))

SUMMARY

a.summary()

'Ether / ARP who has 192.168.56.1 says 192.168.56.101'

FULL DECODE - a.show()
[ Ethernet ]
dst = None (Broadcast FF:FF:FF:FF:FF:FF)
src = 08:00:27:bf:9a:64
type = ARP
[ ARP ]
hwtype = Ethernet (10Mb)
ptype = IPv4
hwlen = None
plen = None
op = who-has
hwsrc = 08:00:27:bf:9a:64
psrc = 192.168.56.101
hwdst = 00:00:00:00:00:00
pdst = 192.168.56.1
RAW BYTES - hexdump(a) - 42 bytes on wire
0000 FF FF FF FF FF FF 08 00 27 BF 9A 64 08 06 00 01
0010 08 00 06 04 00 01 08 00 27 BF 9A 64 C0 A8 38 65
0020 00 00 00 00 00 00 C0 A8 38 01
SEND + PROOF IT WAS SENT
sendp(a, iface="eth0")

.
Sent 1 packets.
tcpdump listener confirmed:
22:48:40 eth0 Out ... ARP, Request who-has 192.168.56.1 tell 192.168.56.100

L3 - Network

One Terminal:

I only have one VyOS terminal, but Linux has &. This puts tcpdump in background and gives me my prompt back:

sudo tcpdump -i eth0 -n icmp &
[1] 5966
listening on eth0, link-type EN10MB (Ethernet)

In the same terminal, Scapy. You have to tell it what a is first:

sudo python3
from scapy.all import *
a = Ether()/IP(dst="192.168.56.101")/ICMP()

Then interrogate it:

a.show()
version = 4, ihl = None, tos = 0x0, len = None, id = 1, flags =, frag = 0
ttl = 64, proto = icmp, src = 192.168.56.101, dst = 192.168.56.101
[ICMP] type = echo-request, code = 0, chksum = None, id = 0x0, seq = 0x0

a.summary()
Ether / IP / ICMP 192.168.56.101 > 192.168.56.101 echo-request 0

len(a)
42

hexdump(a)
0000 FF FF FF FF FF FF 08 00 27 BF 9A 64 08 00 45 00
0010 00 1C 00 01 00 00 40 01 88 C5 C0 A8 38 65 C0 A8
0020 38 65 08 00 F7 FF 00 00 00 00
= dst MAC broadcast, src MAC 08:00:27:BF:9A:64, type IPv4, ICMP echo-request

Send it:

sendp(a)
WARNING: MAC address to reach destination not found. Using broadcast.
Sent 1 packets.

Try to get a reply:

reply = srp1(a, timeout=2)
Begin emission
WARNING: MAC address to reach destination not found. Using broadcast.
Finished sending 1 packets
Received 0 packets, got 0 answers, remaining 1 packets

reply.show()
AttributeError: 'NoneType' object has no attribute 'show'

Lesson: Ether() with no dst MAC = broadcast FF:FF:FF:FF:FF:FF. Scapy does this because it has no ARP entry for the dst IP, so it can't resolve dst MAC. Target ignores broadcast ICMP. sendp is L2 - needs a MAC.
For a real L3 ping, next time: a = IP(dst="192.168.56.101")/ICMP() and sr1(a).
Three checks before you send: summary(), show(), len().

L4 to L7 - Transport + Data

Listener on same terminal:
sudo tcpdump -i eth0 -n tcp port 22 -X &
Send: sendp(Ether()/IP(dst='192.168.56.101')/TCP(sport=54321,dport=22)/Raw(b'SSH-'))

LAB: L4-L7 Packet Crafting with Scapy + VyOS/tcpdump

Objective:
To demonstrate manual control of OSI Layers 2-7 by crafting a custom TCP packet with an SSH banner as payload and verifying it with tcpdump -X on VyOS.

Packet Construction (Final Working Command):

from scapy.all import *
a = Ether()/IP(dst="192.168.56.1")/TCP(sport=54321,dport=22)/Raw(load=b"SSH-2.0-MyLab\r\n")
sendp(a)

Fixes from initial errors: Use TCP not tcp, Raw not RAW, and / between every layer. Correct syntax is Ether()/IP()/TCP()/Raw(). Added sport=54321 to use a proper ephemeral source port. If you leave sport unset, Scapy defaults to 20 (ftp_data) which is wrong for this lab.

Packet Analysis (from screenshots):

a) a.summary()
Output: Ether / IP / TCP 192.168.56.101:54321 > 192.168.56.1:22 S / Raw
Analysis: Confirms L2 Ether, L3 IP, L4 TCP with SYN flag (S), ephemeral source port 54321 to destination ssh=22, plus L7 Raw layer.

b) a.show() - Layer Breakdown:
[ IP Layer ]
ttl = 64
proto = tcp
src = 192.168.56.101
dst = 192.168.56.1

[ TCP Layer ]
sport = 54321
dport = ssh (22)
seq = 0
ack = 0
flags = S (SYN)
window = 8192

[ Raw Layer - L7 Payload ]
load = b'SSH-2.0-MyLab\r\n'

This shows full OSI control: Ether (L2) -> IP (L3) -> TCP (L4) -> Raw SSH banner (L7).

c) len(a)
Output: 69
Analysis: Total packet size on wire is 69 bytes. Breakdown: 14 bytes Ethernet + 20 bytes IP + 20 bytes TCP + 15 bytes payload (SSH-2.0-MyLab\r\n).

d) hexdump(a)
Output:
0000 FF FF FF FF FF FF 08 00 27 BF 9A 64 08 00 45 00
0010 00 37 00 01 00 00 40 06 89 09 C0 A8 38 65 C0 A8
0020 38 01 D4 31 00 16 00 00 00 00 00 00 00 00 50 02
0030 20 00 9A 2E 00 00 53 53 48 2D 32 2E 30 2D 4D 79
0040 4C 61 62 0D 0A
Analysis: Hex at offset 0030-0040 decodes to ASCII: 53 53 48 = "SSH", 2D 32 2E 30 = "-2.0". This is exactly what tcpdump -X on VyOS captures, proving L7 payload injection. The FF FF FF FF FF FF is broadcast MAC because Scapy warning "MAC address to reach destination not found. Using broadcast." - no ARP entry for 192.168.56.1.

VyOS Verification:

On VyOS: sudo tcpdump -i eth0 tcp port 22 -X
This captures the packet and shows the hex/ASCII SSH-2.0-MyLab even though no real SSH handshake occurred.

Conclusion:
The packet is not a real SSH connection - we skipped the TCP 3-way handshake (SYN, SYN-ACK, ACK) and just threw the SSH banner at port 22. Tcpdump sees it because it sniffs the wire before the OS validates it. This proves Scapy gives full control of Raw payload (L7) inside TCP/IP envelopes.

ssh from 3 places: Why TinyCore inside Oracle VM worked when PuTTY and PowerShell didn't

Melissa — Wed, 14 Oct 2026 13:03:15 +0000

VyOS SSH - L4 Handshake vs L7 Banner / Keys / Auth

VyOS eth0 (LAN) = 192.168.56.101
VyOS eth1 (WAN) = 10.0.3.15

1) SSH FROM PowerShell

A. While SSH DISABLED:
Error: ssh: connect to host 192.168.56.101 port 22: Connection timed out

B. Pre-checks (disabled):
nmap -p 22 VyOS_IP = NA
ncat -v VyOS_IP 22 =NA
Keys? = NA

C. Pre-checks (after enable):
nmap = NA
ncat banner = NA
Keys = NA

D. Login test (only if pre-checks green):
ssh user@VyOS_IP =
Result = NA

Conclusion:
L3/L4 Testing Limitation – Windows Host to VyOS LAN (192.168.56.101)

Objective: Verify SSH (TCP 22) access to VyOS LAN interface from Windows PowerShell using Test-NetConnection, nmap, and ncat.

Result: N/A – Failure at L3 (not L4)

L3 Test from Windows PowerShell (PS C:\Windows\system32>): ping 192.168.56.101 -> Request timed out. 100% loss (4/4)

Test-NetConnection 192.168.56.101 -Port 22
-> TcpTestSucceeded : False / No response

C:\Program Files (x86)\Nmap\nmap.exe -p 22 192.168.56.101
-> No output / hang – port state filtered (no L3 response)

ncat -v 192.168.56.101 22
-> No connection

L3 Test from VyOS:
ping 192.168.56.1 (Windows Host-Only adapter)
-> Destination Host Unreachable
Root Cause:
VirtualBox > VyOS > Settings > Network > Adapter 1 (eth0)
Current: Attached to: Internal Network
Required for Windows access: Attached to: Host-Only Adapter

Internal Network mode intentionally excludes the Windows host by design.
Therefore Windows can never reach Oracle VM at L3, so L4/L7 SSH tests from PowerShell are impossible.

Changing Adapter 1 to Host-Only Adapter is blocked – OK button greyed out while VM is running. Creating a new Host-Only adapter in VirtualBox Network Manager fails on this host. Powering off to change risks DHCP change of LAN/WAN IPs.

Conclusion: L3 unreachable between Windows and Oracle VM. Therefore L4 port 22 and L7 SSH app tests from PowerShell are N/A. This is a Windows/VirtualBox boundary issue, not a VyOS ssh service failure. Demonstrates effective isolation of management plane. SSH was verified locally on VyOS via show configuration and ss -tlnp.

2) SSH FROM PuTTY

A. While SSH DISABLED:
Error popup: [ ] NA

B. Pre-checks (disabled):
nmap (from PowerShell) = NA
ncat (from PowerShell) = NA

C. Pre-checks (after enable):
nmap = NA
ncat = NA

D. Login test (only if green):
PuTTY connection type: SSH, port 22
Result / auth: NA

Conclusion:

PuTTY SSH Test to VyOS LAN – Not Tested

PuTTY test to 192.168.56.101:22 – Not performed / Not Applicable.

Reason: See PowerShell L3 failure section. Windows host has no Layer 3 connectivity to Oracle VM VyOS LAN (eth0 attached to Internal Network, not Host-Only Adapter).

ping 192.168.56.101 = Request timed out (100% loss)
ping 192.168.56.1 from VyOS = Destination Host Unreachable

PuTTY requires L3 to establish TCP 22. As L3 is down at the Windows/VirtualBox boundary, any PuTTY attempt would timeout without ever reaching VyOS ssh service. Test would be irrelevant.

3) SSH FROM TinyCore VM inside Oracle VM

A. While SSH DISABLED:
Error: ssh not found

B. Pre-checks (disabled):
nmap -p 22 VyOS_IP = NA
ncat -v VyOS_IP 22 = NA
Keys? =

C. Pre-checks (after enable):
nmap = NA
ncat banner = NA
Keys = NA

D. Login test (only if green):
ssh user@VyOS_IP =
Result = NA

TinyCore VM - Connectivity Tests to VyOS LAN (192.168.56.101)

L4 Tooling Issue on TinyCore:

I wanted to do an L4 port check from TinyCore to VyOS.

nmap - Attempted install via:
tce-load -wi nmap.tcz
Failed to install on the base TinyCore image.
Alternative L4 tool: ss - The tool you suggested in this chat, sudo ss -tlnp, was tried as an alternative to nmap. This also did not work as an L4 probe from the TinyCore side due to TinyCore's minimal base install.

As a result, we used ping for L3 and the ssh client itself as the L4 test.

L3 - Ping to VyOS LAN - SUCCESSFUL:
ping 192.168.56.101
Result: 3 packets transmitted, 3 received, 0% packet loss - L3 is up.

L4 - SSH from TinyCore while SSH is DISABLED on VyOS:
ssh vyos@192.168.56.101
Error message:
ssh: connect to host 192.168.56.101 port 22: Connection refused
L4/L7 - SSH from TinyCore AFTER SSH was enabled on VyOS - FAILED:

After enabling SSH on VyOS, the SSH attempt from TinyCore still did not succeed.
ssh vyos@192.168.56.101
Error message:
- still Connection refused / timed out]
Next Step: This failure, plus the observation that SSH doesn't appear to stay enabled on VyOS after a reboot/save, will be investigated in the next section on the VyOS VM.

## ssh from TinyCore finally succeeded, read on for details:

The client was missing

tc@box:~$ ssh -v vyos@192.168.56.101
-sh: ssh: not found

TinyCore doesn't include SSH. The fix was one command:

tce-load -wi openssh

After that, the same ssh command connected. That was my first ever SSH - TinyCore .102 to VyOS .101. While checking the ARP table I also found 192.168.56.20 alive and pingable on the same host-only wire. Three hosts, not two.

VyOS was innocent

I suspected VyOS for hours, but sudo ss -tlnp src 192.168.56.101 showed the truth: sshd pid 4670 LISTEN 192.168.56.101:22. The daemon was waiting the whole time. I just had no client to call it with.

Why VM-to-VM worked but PowerShell/PuTTY didn't

Both VMs live inside VirtualBox Host-Only 192.168.56.0/24 - same L2 cable. TinyCore .102 to VyOS .101 needs no firewall. PowerShell/PuTTY from Windows has to go through the 192.168.56.1 host adapter and Windows Firewall, which blocks the path. Same listener, different door.

Why Scapy Instead of Ping? - Layer Locking

Melissa — Mon, 12 Oct 2026 11:24:28 +0000

Reason for layer locking: More accurate result.
Operating systems are generic, Scapy frames are specific, so Scapy frames give troubleshooting accuracy.

Environment: VyOS router in Oracle VM VirtualBox.

LAYER 2 - Data Link Test

Steps:

Put listener on eth0 on VyOS
Run Scapy frame

Scapy frame to send (L2 broadcast - locks to L2):

Layer 2 Lock Test - Pure L2 - VyOS eth0

from scapy.all import *
p = Ether(dst="ff:ff:ff:ff:ff:ff")
hexdump(p)

0000 FF FF FF FF FF FF 00 00 00 00 00 00 90 00

Breakdown:
FF FF FF FF FF FF = dst - broadcast all MACs
00 00 00 00 00 00 = src - zero - Scapy default when no MAC bound
90 00 = type - Loopback - blank L2 frame

srp(p, iface="eth0", timeout=3)

Begin emission:
Finished sending 1 packets.
Received 0 packets, got 0 answers, remaining 1 packets

Result: L2 TX works - frame was put on wire, layer-locked, no IP.

LAYER 3 - Network Layer Test

L3 Test - Hardcoded MAC + Static IP - VyOS eth0

Goal: Exclude DHCP and ARP to prove L3 TX.

STEP 1 - Find MAC (Linux command)
$ cat /sys/class/net/eth0/address
08:00:27:bf:9a:64

STEP 2 - Put static IP (VyOS config)
configure
set interfaces ethernet eth0 address 192.168.56.10/24
commit
save
exit

STEP 3 - Put listener in background (same terminal)
$ sudo tcpdump -i eth0 -e -n icmp &
[1] 3047
tcpdump: listening on eth0, link-type EN10MB

STEP 4 - Scapy - hardcode MAC and IP to kill ARP
$ sudo python3

from scapy.all import *
my_mac = "08:00:27:bf:9a:64"
my_ip = "192.168.56.10"
p = Ether(dst=my_mac, src=my_mac) / IP(dst=my_ip, src=my_ip) / ICMP()
hexdump(p)

0000 08 00 27 BF 9A 64 08 00 27 BF 9A 64 08 00 45 00..'.d..'.d..E.
0010 00 1C 00 01 00 00 40 01 89 7B C0 A8 38 0A C0 A8......@..{..8...
0020 38 0A 08 00 F7 FF 00 00 00 00 8.........

Breakdown:
08 00 27 BF 9A 64 = dst MAC = your eth0 (hardcoded)
08 00 27 BF 9A 64 = src MAC = your eth0 (hardcoded)
08 00 = Type = IPv4
45 00 = IP version / header
C0 A8 38 0A = hex for 192.168.56.10 src
C0 A8 38 0A = hex for 192.168.56.10 dst
08 00 = ICMP Echo Request

srp(p, iface="eth0", timeout=3)

Begin emission:
Finished sending 1 packets.
13:38:43.976853 08:00:27:bf:9a:64 > 08:00:27:bf:9a:64, ethertype IPv4 (0x0800), length 42: 192.168.56.10 > 192.168.56.10: ICMP echo request
.
Received 0 packets, got 0 answers, remaining 1 packets

RESULT:
L3 TX UP - Confirmed.
tcpdump saw the frame on eth0 (line above), proving Layer 2 and Layer 3 headers were built correctly and transmitted with no DHCP/ARP.

Received 0 is EXPECTED here because we pinged ourselves (src=dst). Linux routes self-pings via lo, not eth0, so no Echo Reply is generated on eth0. This is not L3 down.

For full L3 up with reply, ping gateway 192.168.56.1 with its MAC, and srp will show "got 1 answers".

LAYER 4 - Transport Layer Test

L4 Test - UDP Port 50001

Why put a listener on port 50001?

We use 50001 because it is in the clean dynamic range 49152-65535. Nothing else on VyOS uses it, so there is no L5-L7 app interfering. If something arrives there, we know it is pure L4 Transport being tested. We also need a listener (nc -l -u -p 50001) otherwise the OS would drop the UDP and we would see nothing.

The listener was run in one terminal as:
sudo nc -l -u -p 50001 > /tmp/udp.txt &
The frame we sent:

L4 must be carried inside L3, so we still need an IP. We used loopback because we are sending from VyOS to itself:
from scapy.all import *
udp_clean = IP(dst="127.0.0.1")/UDP(dport=50001)/Raw(load="L4-TEST")
send(udp_clean)
Breakdown:

IP(dst="127.0.0.1") = L3 part - VyOS lo loopback
/UDP(dport=50001) = L4 part - clean port
/Raw(load="L4-TEST") = payload to prove delivery

Sent with:
sudo python3 -c "from scapy.all import *; send(IP(dst='127.0.0.1')/UDP(dport=50001)/Raw(load='L4-TEST'), verbose=1)"
The result:
cat /tmp/udp.txt
L4-TEST
And tcpdump -i lo -n port 50001 showed the packet on lo.

Conclusion: Payload L4-TEST was delivered to clean port 50001. No other service uses this port. This proves L4 UDP is UP.