I wanted to run an nmap scan to see who´s on the network right now.
For this I wanted to issue the command nmap -sP 192.168.122.0/24 .
BTW: I got this result:
Starting Nmap 7.80 ( https://nmap.org ) at 2023-07-18 14:21 CEST
Nmap scan report for rosika-Lenovo-H520e (192.168.122.1)
Host is up (0.00078s latency).
Nmap scan report for 192.168.122.174
Host is up (0.018s latency).
Nmap done: 256 IP addresses (2 hosts up) scanned in 3.16 seconds
So it worked well.
But this was the second attempt.
Unfortunately there was a typo in my first command. In actual fact I typed: nmap -sP 192.168.122/24 . I omitted the “0”. It should´ve been “0/24”.
It was running along quite happily but didn´t return anything. When I noticed my mistake I aborted the process with “CTRL + C”.
Just out of interest: What did my false command do, if anything
Thanks a lot in advance.
Many greetings from Rosika
Hi Rosika,
Looks like it just worked. nmap will not write on anything
but
there is a more serious question
the virtual machine on your virt-manager virtual network is supposed to be NAT
how is it that nmap could find the ip address of your guest VM?
that is not supposed to happen
Regards
Neville
I get it
Today is the feastday of the prophet Elijah, who performed many miracles.
Clearly he is still active.
$ nmap -sP 192.168.122/24
Starting Nmap 7.94 ( https://nmap.org ) at 2023-07-19 20:29 AEST
Nmap scan report for mymodem.modem (192.168.0.1)
Host is up (0.00089s latency).
Nmap scan report for 192.168.0.56
Host is up (0.00020s latency).
Nmap scan report for trinity.modem (192.168.0.57)
Host is up (0.00012s latency).
Nmap done: 256 IP addresses (3 hosts up) scanned in 2.51 seconds
It made a real mess of it , looked on the wrong network, and found the modem instead of the VM.
Now doing it properly
$ nmap -sP 192.168.122.0/24
Starting Nmap 7.94 ( https://nmap.org ) at 2023-07-19 20:23 AEST
Nmap scan report for 192.168.122.1
Host is up (0.00023s latency).
Nmap scan report for mxvm.colrose.com.au (192.168.122.45)
Host is up (0.00084s latency).
Nmap done: 256 IP addresses (2 hosts up) scanned in 3.01 seconds
It found it, just like yours. It did not find the other 2 guests that were not running, of course.
I thought NAT was supposed to stop one finding IP addresses ?
Can anyone explain?
Hi @Rosika
I found this
" A second characteristic or restriction with using the KVM default NAT-based networking is that interfaces associated to the NAT are not, by default, visible outside of the KVM host running the NAT. This mean that external systems and their networking components have no knowledge of or way to route network traffic directly to a KVM guest OS "
I think it means, you can get VM ip addresses from within the host, but not from beyond the host.
Neville
Hmm, . That´s a good point. I´ll have to investigate…
Thanks, Neville.
So the command I issued, nmap -sP 192.168.122/24 (omitting the “0” in the IP address), would have caused nmap to perform a host discovery scan on the IP range from 192.168.122.0 to 192.168.122.255, right?
However, since I didn’t specify the exact IP range correctly, the scan likely didn’t produce any meaningful results.
I get it… Thanks again.
So in this case, the nmap command would have attempted to send a ping to each IP address within the specified range to determine if the host is up or not (I found out the -sP flag is used for ping scanning).
However, because I didn’t provide a valid IP range, the command may not have found any active hosts to ping.
So I aborted with “CTRL + C”.
Right, that makes sense.
O.K., I red through the citation you provided.
You could deduce it from that? That´s great.
I thought after the fiasco with ChatGPT (regarding the timeshift topic) it might only be fair to give it another chance here…
Well, I asked it:
me:
The virtual machine on my virt-manager (which I used to power up the virtual machine) virtual network is supposed to be NAT. I checked and it is using NAT. How is it that nmap could find the ip address of your guest VM?
Is this supposed to happen?
ChatGPT:
If your virtual machine is configured with NAT (Network Address Translation), it means that the virtual machine’s IP address is private and not directly accessible from the external network (including the host system and other devices on the same network). NAT acts as a mediator between the virtual machine and the external network, allowing the virtual machine to communicate with external resources while appearing as if it’s using the host’s IP address.
Given this setup, it is unexpected for nmap -sP 192.168.122.0/24 to detect the IP address of the guest virtual machine, as the guest’s IP should remain hidden behind the NAT.
There are a few potential explanations for this:
Inaccurate Information: The IP address detected by nmap might not actually belong to the guest virtual machine. It’s possible that it’s detecting the host system itself or another device on the network that happens to respond to ICMP pings.
Port Forwarding: In some configurations, port forwarding rules or virtual networking settings might allow certain types of incoming traffic to reach the virtual machine directly, bypassing NAT. If port forwarding is enabled for the virtual machine’s IP and the chosen port(s), nmap might detect the IP as being up.
NAT Bypass: In some cases, the virtual machine’s network settings might be misconfigured, or the network driver being used might bypass NAT, leading to direct network visibility from the host system.
Bridge Connection: If the virtual machine is using a network bridge instead of NAT, it could have its own IP address on the local network, which nmap would detect.
To investigate further and understand why nmap detected the virtual machine’s IP address, you can try the following:
Check the IP address of your host system using ifconfig (on Linux) or ipconfig (on Windows). Ensure that the IP address belongs to the same network range as the one scanned by nmap. The host’s IP should be different from the one detected by nmap.
Verify the network settings of your virtual machine in the virtual machine manager (virt-manager). Make sure it’s indeed set to use NAT.
If your virtual machine is using NAT, try running nmap with the -sn flag instead of -sP. This flag disables port scanning and might give you more accurate information about host availability.
For example: nmap -sn 192.168.122.0/24
Should we try the command nmap -sn 192.168.122.0/24
So I cant ping or nmap anything on the virtual net. There is a guest running.
But I can ping the host
nevj@mary ~ $ nmap 192.168.32.6/24
Starting Nmap 7.94 ( https://nmap.org ) at 2023-07-20 17:38 AEST
Nmap scan report for trinity.colrose.com.au (192.168.32.6)
Host is up (0.00044s latency).
Not shown: 996 closed tcp ports (conn-refused)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
111/tcp open rpcbind
2049/tcp open nfs
Nmap scan report for mary.colrose.com.au (192.168.32.7)
Host is up (0.00018s latency).
Not shown: 999 closed tcp ports (conn-refused)
PORT STATE SERVICE
21/tcp open ftp
Nmap scan report for 192.168.32.98
Host is up (0.049s latency).
Not shown: 996 closed tcp ports (conn-refused)
PORT STATE SERVICE
21/tcp open ftp
23/tcp open telnet
515/tcp open printer
9100/tcp open jetdirect
Nmap done: 256 IP addresses (3 hosts up) scanned in 8.15 seconds
So it reaches into trinity, and itself (mary) , and the printer which is also on the local net, but not into the virtual network inside trinity host.
I think that is what NAT is all about.
Try it from your laptop, I bet it cant see into the virtual network.
nmap -sn 192.168.122.0/24
Starting Nmap 7.80 ( https://nmap.org ) at 2023-07-20 14:06 CEST
Nmap scan report for rosika-Lenovo-H520e (192.168.122.1)
Host is up (0.00061s latency).
Nmap scan report for 192.168.122.174
Host is up (0.00048s latency).
Nmap done: 256 IP addresses (2 hosts up) scanned in 2.69 seconds
Didn´t help much. The results are the same.
Thanks for trying it out, Neville.
Oh dear, I´m completely confused now… .
What exactly do you have in mind, Neville? What´s the senario?
Hi Rosika,
nmap will not see the virtual network from any computer connected to the host, but it will see it from the host.
so try nmap in your laptop, with the hotspot connected. It will not work. Neither will ping see the virtual network.
So NAT protects your virtual network from snooping outsiders.
Regards
Neville
I´ll connect my laptop to the PC´s hotspot and from the laptop I´ll try to ping (or use namp ) the virtual machine (Debian in my case), which is running on the PC.
The command I have to issue from within the laptop… should still be nmap -sP 192.168.122.0/24 , right?
I just have to install nmap on my laptop first.
At the moment I´m creating a timeshift snapshot on the laptop manually. So I´ll have to wait a few minutes more.
Here are the results. I adopted the scenario from above, i.e.:
Debian VM running in PC
laptop connected to PC via PC´s hotspot
the command issued from the laptop
rosika2@rosika2-E6222 ~> nmap -sP 192.168.122.0/24
Starting Nmap 7.80 ( https://nmap.org ) at 2023-07-20 15:02 CEST
Nmap scan report for rosika-Lenovo-H520e (192.168.122.1)
Host is up (0.0037s latency).
Nmap scan report for 192.168.122.174
Host is up (0.0033s latency).
Nmap done: 256 IP addresses (2 hosts up) scanned in 2.87 seconds
If I´m not completely mistaken the laptop can see the VM.
… and it can ping it:
rosika2@rosika2-E6222 ~> ping 192.168.122.174 -c 3
PING 192.168.122.174 (192.168.122.174) 56(84) bytes of data.
64 bytes from 192.168.122.174: icmp_seq=1 ttl=63 time=3.08 ms
64 bytes from 192.168.122.174: icmp_seq=2 ttl=63 time=3.31 ms
64 bytes from 192.168.122.174: icmp_seq=3 ttl=63 time=3.31 ms
--- 192.168.122.174 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 3.077/3.230/3.308/0.108 ms
Hi Rosika,
Hey that is different from what I got… see reply #8 … mine saw 0 hosts, yours saw 2
So what is different?
I have
Debian VM running in main PC
Small PC connected to main PC via ethernet
Small PC also connected to modem via WiFi
Main PC connected to modem via ethernet
command issued from small PC
So it is different. It could have routed the nmap packets directly via ethernet or indirectly via modem. If it went via modem , I could understand it being different to your result… the modem has its own security which might have stopped it.
I will have to disable the modem connection and try again. I forgot about the modem link.
All that aside… your result is alarming… NAT is not working for our VM setup.
NAT is like an office with one external phone number and a switchboard with extensions.
Everyone outside thinks they are dealing with the one phone number for both incoming and outgoing calls. There is no direct dialin to an extension.
Will try again tomorrow. Perhaps it would be easier to try with my laptop.
Regards
Neville
Hi Rosika,
You are right. There is nothing in any of my VM guests that anyone would want to see.
Will try again tomorrow
I tried from the laptop. Unfortunately 32 bit Void does not have nmap. I used ping.
# ip route add 192.168.122.0/24 via 192.168.32.5 dev enp2s3
# ip r
default via 192.168.0.1 dev wlp2s2 proto dhcp src 192.168.0.164 metric 3003
169.254.0.0/16 dev enp2s3 scope link src 169.254.149.41 metric 1002
192.168.0.0/24 dev wlp2s2 proto dhcp scope link src 192.168.0.164 metric 3003
192.168.32.0/24 dev enp2s3 proto kernel scope link src 192.168.32.5
192.168.122.0/24 via 192.168.32.5 dev enp2s3
#
[nevj@joseph ~]$ ping 192.168.122.1
PING 192.168.122.1 (192.168.122.1) 56(84) bytes of data.
64 bytes from 192.168.122.1: icmp_seq=1 ttl=64 time=0.777 ms
64 bytes from 192.168.122.1: icmp_seq=2 ttl=64 time=0.300 ms
64 bytes from 192.168.122.1: icmp_seq=3 ttl=64 time=0.293 ms
64 bytes from 192.168.122.1: icmp_seq=4 ttl=64 time=0.305 ms
^C
--- 192.168.122.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3052ms
rtt min/avg/max/mdev = 0.293/0.418/0.777/0.206 ms
[nevj@joseph ~]$ ping 192.168.122.145
PING 192.168.122.145 (192.168.122.145) 56(84) bytes of data.
From 192.168.32.5 icmp_seq=1 Destination Host Unreachable
From 192.168.32.5 icmp_seq=2 Destination Host Unreachable
From 192.168.32.5 icmp_seq=3 Destination Host Unreachable
From 192.168.32.5 icmp_seq=4 Destination Host Unreachable
From 192.168.32.5 icmp_seq=5 Destination Host Unreachable
From 192.168.32.5 icmp_seq=6 Destination Host Unreachable
^C
--- 192.168.122.145 ping statistics ---
8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7148ms
pipe 4
[nevj@joseph ~]$
You can see I added a route to tell it how to get to the VM network,
then found that I could ping the bridge (192.168.122.1) but not the guest (192.168.122.145).
So this result is different again, but it indicates NAT is stoppig access to guests.
So I think maybe GPT was right nmap is way too clever and may be detecting guest IP by devious methods.
I see. I didn´t know nmap was available as 64bit only.
That was clever.
I have to admit I didn´t know of the route add command.
I took a look at ip (in German though) and also at the man pages.
Well, I never had reason to deal with route, so that was new to me.
But it´s very interesting.
BTW: The command ip r you used… is it the same as ip route
… showing route entries?
Hmm… you´re right. This is different from my case. No idea why that is:
From my laptop I can ping both the bridge and the guest:
rosika2@rosika2-E6222 ~> ping 192.168.122.1 -c 3
PING 192.168.122.1 (192.168.122.1) 56(84) bytes of data.
64 bytes from 192.168.122.1: icmp_seq=1 ttl=64 time=3.10 ms
64 bytes from 192.168.122.1: icmp_seq=2 ttl=64 time=3.31 ms
64 bytes from 192.168.122.1: icmp_seq=3 ttl=64 time=3.27 ms
--- 192.168.122.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 3.104/3.229/3.313/0.090 ms
rosika2@rosika2-E6222 ~> ping 192.168.122.174 -c 3
PING 192.168.122.174 (192.168.122.174) 56(84) bytes of data.
64 bytes from 192.168.122.174: icmp_seq=1 ttl=63 time=3.25 ms
64 bytes from 192.168.122.174: icmp_seq=2 ttl=63 time=3.31 ms
64 bytes from 192.168.122.174: icmp_seq=3 ttl=63 time=3.33 ms
--- 192.168.122.174 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 3.245/3.296/3.332/0.037 ms
and from the PC as well, of course…
You´re right, Neville. But iwas still an interesting excursion.
Yes ip r is same as ip route… just like ip a is same as ip addr
What the route add does is ensure the ping packet goes via the local ethernet network, not via the modem.
Why yours is different from mine remains a puzzle.
Your laptop has only one connection , so it must be pinging via that wifi hotspot.
Your host thinks the ping packet came from within, and lets it proceed… but why?
. That´s a good point. I´ll have to investigate…
.
