TLDR: visit an unsecured website like
http://example.com/ so captive portals work as intended.
---
For captive portals, I just visit
http://example.com/. Captive portals typically work well when the protocol is plain HTTP. It's usually not the "distro" that makes captive portals harder. It's the browser you're using that typically is making the issue harder for captive portals (i.e. you'll have the same problem on Windows).
For instance, modern versions of Firefox and Google Chrome implement extra security for HTTPS connections such as:
Popular sites like Facebook, Google, Twitter, etc. implement HSTS which breaks captive portals ability to intercept secure communications for those sites. This only works when both the server and client (browser) support HSTS but as I said popular modern browsers and sites already do.
Therefore, if you think you're on a wifi access point that has a captive portal then visit
http://example.com/ as your first site. They tend to "play nicer" when on a site without encryption.
---
To answer your question about VMs directly accessing wifi. It can only be done in VBox if you have a wireless USB dongle and configure the dongle to be directly connected to the virtual machine. As far as I'm aware (even after web searching) there's no way to exclusively connect built-in wireless to a VM. You could use other tricks such as bridged networking.
---
Fun experiment to determine if a website supports HSTS! Open the terminal and use curl to get the headers of the web server and search for the Strict-Transport-Security header.
Code:
$ curl -sILk https://twitter.com/ | grep -i strict
strict-transport-security: max-age=631138519
$ curl -sILk https://www.google.com/ | grep -i strict
$ curl -sILk https://www.facebook.com/ | grep -i strict
Strict-Transport-Security: max-age=15552000; preload
Based on our experiment it looks like both Twitter and Facebook support HSTS but Google does not. However, browsers still tend to use Certificate Pinning for those popular websites.