Score:0

How to trace NAT traffic (port-forwarding) from guest VM back to host

cn flag

I have a host and guest Virtual-Machine (VirtualBox) with NAT Networking with the following network interfaces.
How to trace traffic from local IP 10.0.2.15 i.e. guest's IP back to Host ?

Host
Ubuntu

ip route show
default via 192.168.68.1 dev wlp0s20f3 proto dhcp metric 600 
169.254.0.0/16 dev docker0 scope link metric 1000 linkdown 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
192.168.56.0/24 dev vboxnet0 proto kernel scope link src 192.168.56.1
192.168.68.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.68.104 metric 600 

Here 192.168.56.0/24 is the interface for VirtualBox

Guest
Also Ubuntu via VirtualBox VM

vagrant@master:~$ ip route show
default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 100 
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 
10.0.2.2 dev enp0s3 proto dhcp scope link src 10.0.2.15 metric 100 
192.168.56.0/24 dev enp0s8 proto kernel scope link src 192.168.56.10 

vagrant@master:~$ ifconfig
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.2.15  netmask 255.255.255.0  broadcast 10.0.2.255
        inet6 fe80::cf:fdff:feba:3806  prefixlen 64  scopeid 0x20<link>
        ether 02:cf:fd:ba:38:06  txqueuelen 1000  (Ethernet)
        RX packets 53179  bytes 67713452 (67.7 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11030  bytes 941487 (941.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.56.10  netmask 255.255.255.0  broadcast 192.168.56.255
        inet6 fe80::a00:27ff:fecd:ad09  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:cd:ad:09  txqueuelen 1000  (Ethernet)
        RX packets 79  bytes 9158 (9.1 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 83  bytes 7254 (7.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 352  bytes 22658 (22.6 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 352  bytes 22658 (22.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Virtualbox redirects SSH Traffic from 2222 on Host to ssh port 22 on guest via NAT networking of VirtualBox.

The ssh traffic via tshark shows on 10.0.2.15 from 10.0.2.2 once a new ssh connection is started via

vagrant ssh master

tshark output:-

 vagrant@master:~$ sudo tshark  -i enp0s3 -E header=y
    Running as user "root" and group "root". This could be dangerous.
    Capturing on 'enp0s3'
        1 0.000000000     10.0.2.2 → 10.0.2.15    SSH 90 Client: Encrypted packet (len=36)
        2 0.000717886    10.0.2.15 → 10.0.2.2     SSH 90 Server: Encrypted packet (len=36)
        3 0.000972600     10.0.2.2 → 10.0.2.15    TCP 60 37672 → 22 [ACK] Seq=37 Ack=37 Win=65535 Len=0
        4 0.263247999    10.0.2.15 → 10.0.2.2     SSH 178 Server: Encrypted packet (len=124)
        5 0.263826882     10.0.2.2 → 10.0.2.15    TCP 60 56982 → 22 [ACK] Seq=1 Ack=125 Win=65535 Len=0
        6 0.733596788     10.0.2.2 → 10.0.2.15    SSH 90 Client: Encrypted packet (len=36)
        7 0.733862097    10.0.2.15 → 10.0.2.2     SSH 106 Server: Encrypted packet (len=52)
        8 0.734013429     10.0.2.2 → 10.0.2.15    TCP 60 37672 → 22 [ACK] Seq=73 Ack=89 Win=65535 Len=0

I want to be able to see this network packets on host and how this routing is happening.

Score:2
in flag

I assume that 192.168.68.104:2222 is opened by VirtualBox process (you may verify that with lsof -i TCP -Pn | grep LISTEN).

To strictly answer your question - you may take a list of ports opened by VirtualBox (the incantation above) and sniff packets on them, however this only shows traffic initiated by the remote party.

A better approach would be to add another IP to your wlp0s20f3 interface and do one-to-one NAT to a dedicated VM IP (192.168.56.10) on its interface (vboxnet0). This way a VM gets its own IP address on host:

# HOST
# enable routing if it is not enabled already
sysctl net.ipv4.ip_forward=1

# add another IP to your external-facing interface; make sure this IP is not used
ip addr add 192.168.68.99/24 dev wlp0s20f3

# enable NATting for incoming traffic
iptables -t nat -A PREROUTING -d 192.168.68.99 -j DNAT --to 192.168.56.10

# enable NATting for outgoing traffic
iptables -t nat -A POSTROUTING -s 192.168.56.10 -j SNAT --to 192.168.68.99


# GUEST
# disable the interface we won't need
ip link set enp0s3 down

# use host IP as default gateway
ip route add default via 192.168.56.1

Even better approach would be to use bridging (this would allow more transparent layer 2 networking), but because you use wireless interface (I assume so judging by the interface name) it cannot be done without ebtables tinkering.

PS: Please don't use ifconfig, it is obsolete. use ip addr instead.

HumayunM avatar
cn flag
Thanks for your response. I will upvote it for your helpful suggestions but I will wait for an answer. Thanks again.
user999441 avatar
in flag
You cannot filter traffic by PID under Linux, it is only available on `tcpdump` for MacOS AFAIK. There is also a possibility to use a dedicated network namespace, but that's way more complicated than the solution described above. You can however use `iptables`' UID matcher and LOG target, but that shows only a summary of packet, not the traffic itself.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.