Skip to main content

EVE-NG MacAddressSpoofing On

· 4 min read
Aqueeb
Enterprise Architect, Technology Enthusiast, & an Avid Motorcyclist

If you're just interested in the solution, scroll down to the TLDR.

I was recently helping out a friend do some networking labs (something I did on a regular basis almost 15 years ago using Dynamips and a whole bunch of text files). So I started delving into current solutions and man oh man, have things evolved.

We now have access to a product called EVE-NG. According to their website, it is "...The Emulated Virtual Environment For Network, Security and DevOps Professionals"

What EVE-NG allows us to do is to have a full framework for managing emulated (think running Cisco IOS images) and virtual (think running Check Point in a VM) devices.

I've only just started to scratch the surface but already I can see that, at the very least, this is Dynamips on steroids 🔥

But rarely do things go smoothly. After following some instructions on how to get the Check Point image going in EVE-NG, I managed to get it up and running.

But no matter what I did, I could not connect to the Check Point Gateway's (CPGW) web interface from my Windows 11 browser nor could I ping the IP address (see Fig. 1).

Oddly, though, I could ping the ip from the EVE-NG virtual machine (see Fig. 2).

So what gives?

This ping proved that the IP address existed on the VM and that it was bound to an interface. So I ran some commands and indeed, the pnet0 interface was bridged to the eth0 interface and the IP address was visible in the commands (output below, redacted some superfluous lines).

root@eve-ng:~# arp
Address HWtype HWaddress Flags Mask Iface
192.168.5.31 ether 50:00:00:01:00:00 C pnet0
_gateway ether 74:ac:b9:e3:02:d8 C pnet0

root@eve-ng:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master pnet0 state UP group default qlen 1000
link/ether 00:15:5d:05:33:1b brd ff:ff:ff:ff:ff:ff
3: pnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:15:5d:05:33:1b brd ff:ff:ff:ff:ff:ff
inet 192.168.5.30/24 brd 192.168.5.255 scope global pnet0
valid_lft forever preferred_lft forever
inet6 fe80::215:5dff:fe05:331b/64 scope link
valid_lft forever preferred_lft forever
4: pnet1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether d2:d0:99:8b:83:6d brd ff:ff:ff:ff:ff:ff

After a whole bunch of online research, I found out that, by default, Hyper-V does not pass all traffic from the VM to the host operating system. The network card will only handle frames that are addressed specifically to it and since pnet0's MAC address (50:00:00:01:00:00) is different from eth0's MAC address (00:15:5d:05:33:1b), Hyper V does not pass along any traffic that is destined to or from 50:00:00:01:00:00.

TLDR

So if it's not enabled by default, how do we enable it?

We need to put the EVE-NG VM's NIC in promiscuous mode. Here's what I did in PowerShell running in Administrative Mode (right-click PowerShell in the Start Menu and then click on Run as administrator).

❯ Get-VM -Name EVE-NG | Get-VMNetworkAdapter

Name IsManagementOs VMName SwitchName MacAddress Status IPAddresses
---- -------------- ------ ---------- ---------- ------ -----------
Network Adapter False EVE-NG Bridged Network 00155D05331B {Ok} {}

❯ Get-VM -Name EVE-NG | Get-VMNetworkAdapter | Where-Object { $_.MacAddress -eq "00155D05331B" } | Set-VMNetworkAdapter -MacAddressSpoofing On
Note: You don't get any output after running the last command.

And that's it. I could suddenly ping and access the web port on the 192.168.5.31 IP address (see Fig. 3).

If this helped you out, I'd love to hear about it. Drop me a message on LinkedIn. Thx!