[Errno 14] PYCURL ERROR 7 on yum update in centos 6 and 7

[Pjaiswal]

Hi,

I am using virtual box 5.2.2 on Windows 7. I have install centos 5, 6, 7 VM and network type in bridge mode I have disabled IPv6 I have disabled Selinux I have disabled Ipv6Iptables I have put google DNS 8.8.8.8 I have checked the repos and put

but when I do Yum Udate i get error every time i have tried many thing which were available on net but no luck if any one can provide me a solution for it. The error is below

[root@localhost yum.repos.d]# yum clean all; yum update
Loaded plugins: fastestmirror
Cleaning repos: base extras osdial osdial-updates updates
Cleaning up Everything
Cleaning up list of fastest mirrors
Loaded plugins: fastestmirror
Determining fastest mirrors
http://vault.centos.org/6.0/os/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 7 - "Failed to connect to 2001:19f0:0:2a:225:90ff:fe08:f840: Network is unreachable"
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: base. Please verify its path and try again

[Valery Ushakov]

Guest configuration problem.

[Pjaiswal]

Yum Works in Nat network

[Pjaiswal]

Replying to vushakov:

Guest configuration problem.

Hi can you please tell me what can be the problem or wrong config i have install centos 5 to centos 7 on all install i am getting same when i am trying to do yum update but if i do it by nat network yum update works so can you please tell me what i am doing wrong in Bridge network

[Valery Ushakov]

Sorry, but you provide no evidence at all that this is related to VirtualBox.

What other mirrors did yum try to contact, why it couldn't. Could the host contact the same servers that the guest tried to contact. What is the routing table in the guest. What is the difference in guest network config between bridged and natnet attachments, etc, etc.

We cannot provide you support with any of the above, you should ask on CentOS support forums/mailing-lists/...

Please don't re-open unless you can provide specific technical details that implicate VirtualBox.

[Id1010terror]

This looks like a similar issue I'm having with a Security Onion guest machine. The issue is definitely with virtual box because the host is able to reach the repository without issue and by extension when running the guest OS with NAT network settings the problem is resolved. This issue only seems to exist in Bridge Mode as the OP stated. I'm running

Hypervisor: Virtualbox 5.2.4 Host OS:Debian 9.3

What makes this even more odd is that the bug only affects certain sites. For instance the guest vm can pull Google pages and even Reddit pages while in Bridge mode, But it cant pull pages from Ubuntu.com where my updates are hosted, but it CAN when in NAT mode.

[Id1010terror]

1. Differences between my issue and original post.
   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)

2. 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.

-J

Replying to vushakov:

Sorry, but you provide no evidence at all that this is related to VirtualBox.

What other mirrors did yum try to contact, why it couldn't. Could the host contact the same servers that the guest tried to contact. What is the routing table in the guest. What is the difference in guest network config between bridged and natnet attachments, etc, etc.

We cannot provide you support with any of the above, you should ask on CentOS support forums/mailing-lists/...

Please don't re-open unless you can provide specific technical details that implicate VirtualBox.

[Id1010terror]

Update:

After reverting back to Virtualbox Version 5.1.30 from debian stretch-backports contrib, the issue no longer persists for me.

[Valery Ushakov]

The follow up discussion seems to have migrated over to #17405, so close this one instead.