Bridged Networking Malfunctioning

[Id1010terror]

Host OS: Debian 9.3 (Linux) Hypervisor: Virtualbox 5.2.4 Guest OS: Security Onion (Elastic) Beta 3, Kali 2017.3, and I feel confident in assuming all OS's would have the same issue and I can test others if needed.

Situation: This week I upgraded my home lab from older versions of the above software, all previously worked on my hardware without issue, but Bridge Mode Networking is now failing to connect to SOME online resource and has dropped packets when it does connect. However NAT Mode Networking allows access to all online resources without issue.

Guest Configuration: My SecurityOnion Guest VM has a Bridged Adapter connection on Network Adapter 1, giving it internal vm network and external network access / Network Adapter 2 is listening in promiscuous mode on my switch's Mirrored Port.

Upon installing the guest OS (SecOnion) I began having issues pulling updates from the ubuntu.com software repositories. This was odd because on my host machine Speedtest.net was saying I had a 60+mbps connection to my ISP and furthermore my host machine was able to access ubuntu.com and pull down the same repositories without issue, this is what led me to verifying that I can use NAT but not Bridged Mode. NAT does allow me to access all resources (and update the systme), but I need to use Bridge Mode for my lab.

What's REALLY odd is that even with Bridge mode in its limited capacity, it IS able to pull down Google.com, Wikipedia.com, even Reddit.com with little issue (It does seem like it doesn't fully resolve any of the webpages though -spinning tabs and whatnot). But it completely fails to access Ubuntu.com, Fedora.com, Amazon.com... It's just VERY odd behavior... and it only happens in the VM when using Bridged Mode.

This behavior is repeatable (unable to access ubuntu.com and others) and happens every time I've tried to build a VM on this newer software.

Please let me know if there is any additional information I can provide.

-J

[Valery Ushakov]

#17375

As I said in that bug you have reopened: "please don't re-open unless you can provide specific technical details". You reopened it without providing any and filed a new bug for good measure. This is not helpful.

We need to see the network configuration of the guest and packet captures that demonstrate the problem. Not to mention that the bug submission guidelines explicitly asked for a log file for the VM.

[Id1010terror]

1. Apologies for my lack of proper "bug reporting etiquette" this is the first one I've posted a bug report and as far as I could tell on the main bug tracker page I found: https://www.virtualbox.org/wiki/Bugtracker there didn’t seem to be anything that specified any “bug submission guidelines” or what information is required, furthermore what I provided was additional technical configurations of my setup which clearly show the issue is with Virtualbox itself, specifically in Bridge Mode. Also please direct me to any special "posting procedure" documents I should read before posting in the future and I will try to post in that manner.

2. There were multiple differences which compelled me to open a new ticket.
   1. I'm using Virtualbox Version 5.2.4 and ticket #17375 was using 5.1.30
   2. My host is Debian 9.3 and ticket #17375 was using Windows 7.1
   3. My guest VM is Kali 2017.3 and SecurityOnion Beta 3 (debian based) and ticket #17375 was Fedora (redhat based)

That said if you still believe this to be a duplication I will migrate my information over to ticket #17375.

3. I've included the following information for the VM Guest (Kali 2017.3 - Live amd64 Bootmode)
   1. VBOX.LOG
   2. /etc/network/interfaces
   3. NATDUMP.PCAP (SUCCESSFUL NAT)
   4. Ip addr output in NAT mode
   5. BRIDGEDUMP.PCAP (FAILED BRIDGE)
   6. Ip addr output in Bridge mode

---

a. VBOX.LOG

​http://termbin.com/xgb5

---

b. /etc/network/interfaces:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

---

c. NATDUMP.PCAP (SUCCESSFUL NAT)

Description: Accessing ubuntu.com using wget with system in NAT Mode ​https://drive.google.com/open?id=1TM69sy11XVJmdPSkQXwo1W7oeUv0gOkg

d. Ip addr output in NAT mode:

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 pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:15:91:5a brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic eth0
       valid_lft 86352sec preferred_lft 86352sec
    inet6 fe80::6ceb:9d8f:296a:46aa/64 scope link 
       valid_lft forever preferred_lft forever

---

e. BRIDGEDUMP.PCAP (FAILED BRIDGE)

Description: Accessing ubuntu.com using wget with system in Bridge Mode ​https://drive.google.com/open?id=1DmK2Ly-r40zA2IwFHkDAxGFh1dpMQwKY

f. Ip addr output of Bridge mode:

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 pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:15:91:5a brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.154/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2601:100:4100:c770:f3b1:7b96:9b4a:424b/64 scope global noprefixroute dynamic 
       valid_lft 201576sec preferred_lft 201576sec
    inet6 fe80::6ceb:9d8f:296a:46aa/64 scope link 
       valid_lft forever preferred_lft forever

---

Technical Summary of PCAP data

As you can see from the BridgeDump.PCAP, the issue starts around packet 11 with a "Previous Segment not captured" when performing the TLS key exchange for the HTTPS traffic, which is then followed by a series of failed re-transmissions. This behavior only happens in Bridge mode as seen when comparing it to the NAT PCAP where the TLS key exchange works fine.

---

That said, if you want to test this highly repeatable behavior yourself it will happen even with a default “live (amd64) boot mode” instance of Kali 2017.3 so no additional configurations need to be made for you to replicate the issue in Virtualbox's Bridge Mode.

Lastly, while I know it’s much less work to close and disregard us annoying/ignorant ticket submitters than work on the bugs, I hope you will consider what I’ve said here and let me know if there is any additional information I can provide instead of closing it. I hope this was more helpful than my previous post. Thanks for all our hard work! I truly appreciate the work you guys put into this awesome hyper-visor.

-J

[Id1010terror]

Update:

Upon reverting back to the Virtualbox version 5.1.30 from Debian Stretch-Backports, this issue no longer exists. The issue is specific to version 5.2.4 and therefore is NOT a duplicate of ticket #17375

[Aleksey Ilyushin]

I can access ubuntu.com, fedora.com and amazon.com without any issues from live Kali 2017.3 guest bridged to Ubuntu 16.04 host running 4.14 Linux kernel. Can you try pcnet or virtio adapters in your guest? Btw, did you capture the packets with tcpdump running inside the guest? If yes, can you try VirtualBox internal capture as described here? The reason I am asking all the above is that there are irregularities in bridgedump.pcap that suggest the problem is related to segmentation offloading: captured Ethernet frames are 2 bytes shorter than they should be (as suggested by IP header).

[russetrob]

I have seen something similar with bridged connections. It seems to affects *some* TLS connections, and possibly others. What I have seen is an extra byte at the end of the packets when captured on host machine, vs. the virtualbox capture (captured as suggested by aleksey). I'm assuming that some servers are strictly interpreting packet size, and so rejecting packets that are too large by one. If you want the pcap files, could you suggest preferred location for upload.