ESXiArgs, all you need to know.

I’m not a cybersecurity expert, but I’ve been working for a CyberSec company for quite some time and after so many discussions with the Information Security folk a few things start sticking to you. This is the first post I will do focusing on security, but hopefully not the last.

Ransomware is not recent news, it’s been laying around for a couple of years.
Particularly WannaCry kept many colleagues up all night in 2017.
If anyone doesn’t know what Ransomware is yet, let’s explain it with this simple analogy:

Photo:  Westend61 / Daniel Simon

You leave your bike on the street and some thug comes in and instead of taking it home puts a lock and demands a payment (ransom) for the key.
Now, the bike is your data and the lock is an advanced encryption algorithm.

Now, as I mentioned in previous posts this blog primarily focuses on VMware products, and for many years the primary target for ransomware attacks was Windows and VMware was, fortunately, kept to a side.
With the evolution of the Ransomware industry, yes Cybercrime is an industry, Ransomware started affecting not only windows but other operating systems. And that’s where ESXiArgs comes into the picture.
Disclaimer: it’s not the first nor the last ransomware to affect ESXi, it’s just the latest one.

What is ESXiArgs?
ESXiArgs is a Ransomware campaign targeting publicly available ESXi hosts.
It is believed that it’s leveraging one of the following vulnerabilities
CVE-2022-31699, CVE-2021-21995, CVE-2021-21974, CVE-2020-3992, and CVE-2019-5544. But still, the final vulnerability is not yet confirmed.

For a deep dive into how the attack works:
https://www.trustedsec.com/blog/esxiargs-what-you-need-to-know-and-how-to-protect-your-data/

What is OpenSLP?
OpenSLP is an open-source framework for networking applications to discover the existence, location, and configuration of services in enterprise networks, which ESXi client applications use to resolve network addresses and hosts.


What ESXi versions are affected?
According to the official documentation:



Source: https://www.vmware.com/security/advisories/VMSA-2022-0030.html

It’s important to note that most of the affected hosts were reported to be outdated versions of ESXi 6.5 and 6.7.

Is there any workaround available?
Yes, you can disable the SLP service as shown in this KB
Please note, disabling SLP service doesn’t require a reboot but may affect how CIM interacts with your VMs and third-party monitoring solutions might be impacted.

Is there any way to recover?
The US Cybersecurity and Infrastructure Security Agency (CISA) has published this github script with detailed instructions on how to recover.

Remember: Paying for Ransomware is never an option.

Can I block the SLP port on the firewall?
Yes, you can, as a compensatory control.
That’s not a full mitigation.

Is there any official comment from VMware?
VMware Official ESXiArgs FAQ page
VMware Security Response Center has also made its official statement.

Closing comments:
While researching for this blog post I came across a few interesting factors:

1. A cloud provider in France reported having 2000 ESXi hosts affected by this vulnerability. All the hosts were publicly available on the internet.

2. All of the affected hosts are unpatched. And most of them are end-of-life.

How can this be improved?
Don’t expose your servers to the internet if it’s not required. vCenter and ESXi hosts are never required to be exposed to the internet.
But Nacho I need them to… No, you don’t.

  1. Keep the servers up to date:
    This doesn’t only apply to VMware, ESXi or vCenter. This is the most basic part of running IT operations to keep your organization secure.

    I think of the usual patching as going to the doctor:
    • Some people go to the doctor often and get checked. Even if they are feeling perfectly fine. These are the more mature organizations that have reached a level of proactiveness and automation that allows them to.
    • Some people go to the doctor when they have some pain, they get some medications and forget about their doctor.
    This is probably the vast major group of organizations, both big and small that for a variety of reasons don’t want, don’t know, or can’t afford the operational cost of patching.
    • There is also a third group of people that never go to the doctor, and when they visit the doctor is too late.
    These people are just wrong.
  2. Patching vSphere has never been easier, I’m patching my hosts as I write this, to be honest, vSphere Lifecycle Manager (a tool included in your vCenter license) makes it super easy to patch and upgrade your ESXi hosts.
  3. Scan your environment for vulnerabilities:
    Organizations that are mature in the cybersecurity field usually have a Vulnerability Scanning tool running regularly.
    These tools often give a report of the vulnerabilities in the system and even tell you what is the suggested version and how to mitigate them.
    There are many options both open-source and paid.
    Based on my experience I would recommend Tenable or Nessus.
    Another option would be to hire a company or consultant that provides Red Team services.
  4. Subscribe to VMware Security Advisories
    It’s a newsletter that sends you updates on new vulnerabilities, it’s usually a 2 minute read and from there you can notify your team and your organization to properly patch and update.

vSphere with Tanzu – .local DNS issues.

Yes, I know, It’s been a while since I’ve last posted here, yeah, getting used to a new country is not an easy thing. Well, the idea is to keep up with the blog and try to pay more attention to it.

Now, let’s get to business, shall we?

Seth Eliot ☕ on Twitter: "What does one not simply deploy?  https://t.co/qq8imG0MbX" / Twitter
Murphy’s Law states: “Anything that can go wrong will go wrong.”


I am a firm believer in properly planning, thinking, and designing, thinking every possible outcome, but when you are deploying new technology there is always a showstopper. Sometimes it can be easily solved and sometimes it takes a bit more time.

Lately, I’ve been working on vSphere with Tanzu and I came across an interesting issue with a Client.
My client which for confidentiality reasons I’ll name Contoso had an Active Directory domain that also served as a primary DNS zone contoso.local. as part of a deployment that has been going around for quite some time and a scenario that as consultants we can face often (A legacy environment that has hundreds or even thousands of servers coming from many years ago).

We designed a simple yet functional solution of vSphere with Tanzu leveraging vDS and using NSX ALB.
The initial deployment worked like a charm, we were able to set up our NSX ALB cluster, the service engine, set up the supervisor cluster, the TKG Cluster, and the Harbor repo all in less than a day.

The problem came when performing the first pull of an image. The worker nodes were not resolving internal DNS.

Thanks Tom Warren for the illustration



We logged in to the TKG Cluster nodes (for reference you can see here )
and we tested that the proper servers were configured.
additionally, the communication was working correctly.

Seems easy, doesn’t it? Hang in there.
Well, after some googling we came across this KB article that states:

Symptoms:

Dig and nslookup fails from the supervisor control plane nodes to hostnames ending in .local 

Cause

This is not unique to vSphere with Tanzu. This is expected behavior from the systemd-resolved service.

https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
 

  • Multi-label names with the domain suffix “.local” are resolved using MulticastDNS on all local interfaces where MulticastDNS is enabled. As with LLMNR, IPv4 address lookups are sent via IPv4 and IPv6 address lookups are sent via IPv6.
  • Queries for multi-label names are routed via unicast DNS on local interfaces that have a DNS server configured, plus the globally configured DNS servers if there are any. Which interfaces are used is determined by the routing logic based on search and route-only domains, described below. Note that by default, lookups for domains with the “.local” suffix are not routed to DNS servers unless the domain is specified explicitly as routing or search domain for the DNS server and interface. This means that on networks where the “.local” domain is defined in a site-specific DNS server, explicit search or routing domains need to be configured to make lookups work within this DNS domain. Note that these days, it’s generally recommended to avoid defining “.local” in a DNS server, as RFC6762 reserves this domain for exclusive MulticastDNS use.

The KB also lists a workaround intended only to use on POC environments and NOT on production.

Basically, the problem is that PhotonOS (the OS for TKG nodes) uses the systemd-resolver service.
Systemd-resolver it’s a widely used MulticastDNS resolver, and RFC6762 defines that any domain with the .local suffix should be used only for internal use.  (In other words, it’s the equivalent of naming your DNS domain localhost).

On top of that, we found another problem,  as per the KB article:
The .local hostname is reserved for use in mDNS per RFC6762  therefore trying to resolve it against a DNS server violates RFC6762. As such VMware does not recommend any deployment which uses .local for any components. (this includes vCenter, ESXi, nsx manager, nsx edge nodes, and any endpoint TKGS uses like harbor).

The .local DNS suffix might be reserved in other products which we want to deploy in this environment, and funny enough. It does not only apply to VMware, Microsoft (who was the main promoter for the .local domains in the early days, is now requesting people to change it).


Lastly, since 2014 you are not able to get a public certificate with the .local suffix for the SAN. Cool.

So we can conclude, this is not a Tanzu issue, it’s a tech debt issue and should be addressed

What shall we do next?

We discussed a couple of options in the table.

The first option was to proceed with the workaround specified in the KB article, even though it’s production.
VMware said they would support us, but the problem is that each time you need to perform any lifecycle activity (such as an Upgrade, cluster provisioning or redeploy) you should re-apply manually the workaround.

Pros: It would work, other than that I don’t really see any.
Cons: Requires a LOT of manual effort. The KB said it was not supported for production but GSS said it was.

The second option is the rebuild the contoso.local domain and rename it to something supported and future-proof (contoso.tech for example). Particularly, I preferred this approach since it’s the only way to fix this issue and avoid any further issues.

Pros: It’s a permanent solution
Cons: Takes a LOT of effort, design, planning, and execution would take hundreds of man hours and it has quite a risk associated.

Third option: VMware to the rescue. Thanks to the GSS team for their support and their ideas, we were able to sort out this issue, at least for the short term.
The solution, only applied to Tanzu, was to re-design the Tanzu deployment but using Tanzu Kubernetes Grid Multicloud (TKGm) instead of using vSphere With Tanzu.
Once deployed at the moment of provisioning the TKGm you can run the steps described in KB 83623 and it quotes:

“To workaround this issue you will need to deploy your management and workload clusters with a modified plan that will update the name resolution parameters on the TKG nodes as they are deployed.
 

Nameservers on vSphere provides the instructions needed for using custom DNS servers on your TKG nodes. These instructions only need one modification to allow for domain names ending in “.local” to be resolved. A “searchDomains” line needs to be added to the end of the vsphere-overlay-dns-control-plane.yaml and vsphere-overlay-dns-workers.yaml files. Once modified, the end of these files should look like the following:

nameservers: [“8.8.8.8”]
searchDomains: [“corp.local”] “


Final thoughts:

You know I’m a big fan of VMware, and most of this blog speaks about my experience with VMware products. I have contact with some people inside VMware and I’ve escalated this particular topic, but after months of reading documentation, taking training, and assisting webinars I never saw a single mention of this limitation of using the .local DNS suffix. It would be nice to have that included in the documentation.

Additionally following on the domain migration topic, I like to explain the situation with this analogy.
My house in Argentina was built 60 years ago, it’s a nice house but a couple of years back we had to upgrade the pipes because it had copper pipes and they were getting rusty, the electrical cabling was designed 60 years ago, where a normal household didn’t have the same amount of appliances or devices that it has today, not even bringing Electrical Vehicles in the picture.

When this contoso.local domain it was built for a purpose, over the course of time the purpose shifted and it expanded, and now would be a good time to revisit the house’s electrical system to make it ready to withstand whatever the future brings our way.

Un Argentino en Emiratos Arabes Unidos

Por lo general en este blog hablo de tecnología, productos de VMware, troubleshooting o cosas similares.
Hace un par de meses se me está complicando bastante sentarme a escribir y en las siguientes líneas me gustaría contar un poco por qué:

Durante 2020 en medio de la Pandemia y encerrado en mi casa me propuse empezar el blog y empezar a transmitir conocimiento y compartir algo de lo poco que sé. También me propuse actualizar mis certificaciones y empezar a aprender de nuevos productos.  No obstante la situación en Argentina cada dia estaba peor, pagar la subscripción de AWS para mantener el blog cada dia me salia mas caro y adquirir un homelab decente para hacer demos y generar material me salia igual que un auto. Siempre tuve ganas de hacer la experiencia de vivir en el exterior, primero en EEUU, después por Europa. Tanto como un desafío a nivel personal como para poder ver cómo se vive en países desarrollados donde tu sueldo alcanza para algo.

La oferta

En septiembre del año pasado después de que no pude comprar dólares por 3 meses por pagarme una certificación decidí que era el momento de buscar oportunidades en el exterior.
Tengo amigos viviendo acá en Emiratos Árabes Unidos y les pedí si me conseguían una entrevista, a lo que accedieron de muy buena fé (Gracias Nico y Lean).
En Octubre del mismo año se me acercaron de otra empresa, con una oferta más tentadora, además de un sueldo super competente, me asistían con la reubicación.
Completé los dos procesos de selección y termine decidiendome por la segunda oferta.
El proceso de selección fue un poco largo, el background check tardó casi dos meses, y para cuando firme el contrato ya era marzo de 2021, desde ese día solamente puedo pensar en el viaje.

El viaje

El 3 de Abril, partí hacia Ezeiza, con mis valijas listas y todo preparado para emprender esta aventura, que seguramente sea de un enriquecimiento cultural y un crecimiento enorme con destino final Dubai.
El viaje Ezeiza-Frankfurt fue bastante malo en mi opinión, básicamente porque tuve un bebé llorando y pateando mi asiento durante 14 horas.
Cuando llegué a Frankfurt, mi primera vez en “suelo” europeo,  estaba maravillado con el tamaño del aeropuerto y lo desarrollado que estaba.Después de unas dos horas de escala hicimos el tramo final Frankfurt-Dubai.
Este vuelo fue mucho más tranquilo, sin bebés llorando.
Algo muy genial es que llegando a dubai, sobrevolando el golfo pérsico pude ver los pozos de petróleo de noche y es algo digno de ver. 

Mis primeras palabras cuando llegue a Dubai fueron WOW seguido de unas risas incontenibles al no poder creer que había llegado a tierras emiratis. El chofer que me vino a buscar manejaba un Lexus, UN LEXUS!

Llegué al hotel más o menos a la medianoche, dejé mis valijas y fui a comprar comida.
Lo primero que quise comer fue comida Arabe.

Viajar en Pandemia

Para ingresar a Dubai es necesario tener un PCR 72 hs antes de volar emitido por el hospital alemán. Si haces escala en Alemania tiene que ser 48hs antes.
En el avión es necesario mantener el tapabocas en todo momento, salvo para las comidas y o bebidas.
Otra cosa importante es que voy a estar 21 días en Dubai y después me mudo a Abu Dhabi, donde voy a trabajar, ya que Dubai está abierto al turismo y de esa forma puedo hacer los papeles de la residencia acá.

Primera Semana

Desde que llegué al hotel ya tenía la notebook y el teléfono del trabajo.
La primera semana transcurrió bastante rápido, durante la mañana hacia trámites y reuniones de trabajo. Por la tarde hacia los entrenamientos propios de cualquier trabajo nuevo y cuando se pone el sol salgo a pasear y recorrer lo que dubai tiene para ofrecer.

Los trámites para la residencia y la cuenta bancaria los termine en menos de una semana y no me llevaron mas de media hora cada cosa (Estudios médicos, control de biometricos, elegir el banco y abrir la cuenta).

En cuanto a pasear, voy a dejar algunas fotos, pero todo es grande, todo está limpio, todo es ordenado (Las puertas tienen un camino de entrada y otro de salida), la gente cumple las normas (donde no se puede fumar, nadie fuma).

El Burj Khalifa es el edificio más alto del mundo. Tiene 3 observatorios en los pisos 124, 125 y 148 entrar sale unos 300 AED.
Ir a ver el edificio, el mall, y las fuentes es completamente gratis.
El Burj Al Arab es el único hotel de 7 estrellas del mundo. Para entrar a verlo hay que tener reservación.
Esta foto la saque desde el Souk Madinat Joumeirah que es un centro comercial con varios restaurants.
Esta foto se la saqué a un comerciante en el Souk del Oro.
Esta zona esta llena de comercios orientales de todo tipo, principalmente de Oro, especias, tela y utencillos.
Vengan con paciencia porque les van a querer vender de todo y no se olviden de regatear.
El safari del desierto, aunque completamente diseñado para turistas, es una experiencia muy divertida y algo digno de hacer.
Si bien me dio mucha pena el estado del camello hay muchas otras opciones.

Algo que me sorprende muchísimo es que si vas a cruzar la calle no hay semáforos peatonales, los autos simplemente frenan y te dejan pasar, una maravilla.
Ni hablar del lujo que manejan los autos, creo que vi mas ferraris y lamborghinis que en toda mi vida. (De hecho por primera vez pude andar en un descapotable)

Acá las cosas son distintas en todo sentido, te puede gustar o no, pero yo soy un visitante en una cultura completamente distinta a la mía y es mi obligación contemplarla.

Voy a seguir escribiendo sobre como es vivir acá y cuales son mis impresiones, también aprovecho para contar que en mi instagram @porelmondo voy a estar subiendo fotos y videos de Dubai y Abu Dhabi y aprovecho para pedir disculpas que no estoy subiendo contenido técnico, sinceramente en estos momentos mi cabeza está en acomodarme por estos pagos. Una vez me acostumbre, tenga un departamento fijo ya volveré a escribir con regularidad.

Abrazo grande
Nacho

¿Qué es VMware vExpert? ¿Cómo aplicar?

El jueves pasado anunciaron a los ganadores del VMware vExpert 2021, este año puedo estar entre los homenajeados.
Pero este post no es para hablar sobre mí, no. En este post te voy a contar todo sobre vExpert. ¿Qué es? ¿Cómo llegar a ser vExpert? ¿Por qué ser vExpert?

¿Qué es vExpert?

vExpert es un reconocimiento que da VMware a profesionales que participan en las distintas comunidades (VMUG, VMTN, etc) y mejoran VMware día a día de forma desinteresada. A modo de agradecimiento por compartir sus conocimientos y fomentar el intercambio en las comunidades.
El programa vExpert empezó en 2009.
Algunos programas similares son Microsoft MVP, Cisco Champions o Veeam Vanguard

¿Qué no es vExpert?

NO es una certificación, es un reconocimiento, no requiere preparación técnica alguna.

¿Cómo llegar a ser vExpert?

Existen varios caminos, dependiendo cual sea tu condición por ejemplo: no es el mismo camino si sos empleado de VMware, trabajas para un partner o si sos cliente.

Los paths son:
– Customer:
Este path está pensado para, como es mi caso, clientes de VMware, gente que genera artículos, participa activamente en VMTN y en los VMUG y se muestra activa en las diversas comunidades (LinkedIn, Twitter, etc)

– Partner:
Este path está pensado para empleados de partners de VMware.
Se valoran los eventos que dan a conocer productos técnicos, VMTN, artículos de blogs y colaboración con VMware.

– VMware employee:
Este path es para empleados de VMware exclusivamente, se valoran artículos técnicos, la participación en VMTN y otras comunidades, KB’s, entre otros.

– Evangelist:
Cualquiera puede aplicar a este path las personas que quieran aplicar tienen que: Escribir blogs, libros, dar conferencias en público y ser apasionados por compartir conocimiento.

Una vez decidido el path hay que ir a vexpert.vmware.com y completar nuestros datos y un formulario de inscripción en el que, básicamente, tenemos que contar ¿Por qué queremos ser vExperts?
Algo importante, las inscripciones para vExpert abren dos veces al año, una vez a principio de año y otra a mediados de año.

vExpert PRO

Son personas que tienen varios años como vExperts y decidieron empezar a mentorear a otras personas para que puedan ser vExperts.
Está muy bueno contactarlos antes de aplicar y pedir un poco de feedback.
Gracias Rolo y Ariel!

¿Por qué ser vExpert?

Acá dejo una lista de los principales beneficios del programa:
– Networking con casi 2000 profesionales.
– Invitación al canal privado de Slack
– Oportunidad de aplicar a los subprogramas de vExpert
– Certificado de vExpert firmado por Pat Gelsinger (Creo que fueron los últimos, no?)
– Permiso para usar el logo de vExpert en tus tarjetas, sitio web y demás
– Vas a aparecer en el Directorio de vExperts
– Licencias de VMware y de varios otros productos(Licencias por un año o NFR)
– Webinars privados de VMware y partners.
– Briefings pre lanzamiento y pre VMworld.
– Programa de Early Access para Bloggers
– Fiesta privada e identificación en el VMworld

Y como si todo esto fuera poco.
– Regalos exclusivos de VMware y algunos partners. ¿A quien no le gusta el marchandising corporativo?
– Un año gratis de Pluralsight.
– Reconocimiento de la comunidad. (No es una certificación, pero abre muchísimas puertas).

Conclusión

Quería agradecer, una vez más, a VMware por el reconocimiento y a todos los que me ayudaron en este camino.
Esto recién empieza.

Error “The vSphere Distributed Switch configuration on some hosts differs from that on the vCenter server” – VCF 3.9

Las últimas semanas del año pasado encontramos un error raro en nuestros vSphere Distributed Switches, aparecían alertados con el error “The vSphere Distributed Switch configuration on some hosts differs from that on the vCenter server”. Comúnmente cuando  haces click en el botón rectify se resuelve.
Acá no pasaba nada.
Actualmente estamos usando VCF 3.9 (vSphere 6.7 + NSX 6.4.6 + vSAN 6.7)
Los pasos a seguir para resolver este problema son estos:

  1. Poner el host en Maintenance Mode:
    Es importante seleccionar la opción “Evacuate all data”, ya que vamos a sacar el host del cluster).  Esto va a tardar un rato ya que tiene que Evacuar todos los objetos de vSAN.
  2. Poner DRS en Manual:
    Hosts and clusters → Click sobre el cluster → Configure → vSphere DRS → Edit  → Automation level: Manual.
  3. Sacar una vNIC del vDS:
    Hosts and clusters Click sobre el host → Configure → Networking → Virtual Switches → Manage Physical Adapters → Seleccionamos un Uplink y hacemos click en la X →Ok.
  4. Crear un vSphere Standard Switch (vSS):
    Hosts and clusters → Click sobre el host → Configure → Networking → Virtual Switches → Add Networking → Virtual Machine portgroup for a standard switch → New Standard Switch → Asignamos los uplinks el uplink del punto anterior.  → Creamos un portgroup (Por Defecto: VM Network) → Finish.
  5. Migrar los VMkernels del host (Management, vMotion y vSAN):
    Hosts and clusters → Click sobre el host → Configure → Networking → Virtual Switches → Click sobre el vSS (vSwitch0 en mi caso) → Click sobre los tres puntos … → Migrate VMkernel Adapter → Seleccionamos el VMkernel de Management y hacemos click en next y finish.
    (Repetimos con los VMkernel de vMotion y vSAN).
  6. Sacar la otra vNIC del vDS:
    Hosts and clusters → Click sobre el host → Configure → Networking → Virtual Switches → Manage Phyisical Adapters → Seleccionamos un Uplink y hacemos click en la X → Ok.
    (Vamos a tener que repetir por cada NIC que tenga el host, es decir si el vDS tiene 6 nics, hay que sacar las 6.)
  7. Agregar la segunda vNIC al vSS. (opcional):
    Hosts and clusters → Click sobre el host → Configure → Networking → Virtual Switches → Manage Phyisical Adapters → Hacemos click en el + verde y agregamos el uplink libre como activo o standby.  (Según corresponda).
  8. Sacar el host del cluster:
    Esto lo haces arrastrando el host fuera del cluster (al objeto DC por ejemplo).
    Es importante esperar a que terminen las tareas de reconfigure vSAN y Uninstall (NSX VIB).
  9. Desconectar el host:
    Hosts and clusters → Click  derecho sobre el host → Connection → Disconnect
    Este paso lo hacemos para que no de errores de objetos en uso y nos deje remover el host sin problemas. (Por ejemplo esta KB)
  10. Sacamos el host del vDS:
    Hosts and clusters → Click  derecho sobre el host → Remove from inventory.
  11. Agregar el host al inventario:
    Hosts and clusters → Seleccionamos el objeto Datacenter → Add host.
    Es importante no hacer esto sobre el objeto cluster, porque va a configurar vSAN y NSX antes de tiempo.
  12. Agregar el host al vDS y Migrar los VMkernels:
    Networking → Click derecho sobre el vDS → Add hosts → + New hosts… → En la parte de Manage Physical adapters seleccionamos el uno de los uplinks para el vDS → En la parte de Manage VMkernel Adapters Migramos los portgroups de Management, vSAN y vMotion (podemos hacer todo en un solo click) → En la parte de Migrate VM Networking no hacemos nada → Finish.
  13. Agregar uplinks adicionales:
    Si el host tenía 2 o más uplinks tenemos que dejarlo como estaba antes.
    Hosts and clusters → Click sobre el host → Configure → Networking → Virtual Switches → Manage Physical Adapters → Hacemos click en el + verde y agregamos el uplink libre como activo o standby (según corresponda).
  14. Agregar el host al cluster:
    Simplemente arrastrar el host al cluster en el que estaba.
    Esperar que terminen las tareas de configure vSAN e Install (NSX VIB).
  15. Verificar vSAN:
    Verificar desde el vSAN rvc console que el host sea miembro del cluster.
  16. Verificar NSX:
    Verificar desde el NSX manager que el host esté instalado y no haya problemas de comunicación.
    Cómo se está instalando la VIB puede tardar unos 10 minutos en refrescarse.