In this lesson,
we're going to discuss captive portals
and some issues you may experience when you're using them.
First, what is a captive portal?
Well, a captive portal is a webpage
that's accessed from your web browser,
and it's going to be displayed to newly connected users
of a wireless network before they're granted broader access
to network resources.
Captive portals are commonly going to be used
to present a landing page or a login page,
which is going to require authentication, payment,
or acceptance of an end user license agreement
or something like acceptable use policies,
survey completion, or some other kind of information
we're trying to collect from you before we allow you
to get onto our network and our resources.
Now, these captive portals are commonly used
at places like hotels, restaurants, airports,
and other places that give you free
or paid wireless networks for you to connect to and use.
In general, captive portals are implemented
by using an HTTP redirect, an ICMP redirect,
or a DNS redirect.
We're going to talk about all three of those in this lesson.
Now, when a user attempts to log into a wireless network
and the captive portal doesn't redirect them properly,
it can be a really frustrating experience.
I personally had this happen to me a lot,
but luckily, I know how to troubleshoot and fix this issue,
and after this video, you will too.
Now, for example, I was flying home recently
on a Delta flight, and they use a captive portal system.
When you connect to the Delta Wi-Fi network on the plane,
it's supposed to redirect you
to the captive portal's login page
so you can enter your account information
so you can access the internet if you're a SkyMiles member.
Now, this didn't work on my MacBook Pro, though,
so I had to begin troubleshooting this issue
and figure out what was causing the problem.
It could have been any of the three redirect methods,
'cause I didn't know which one they were using.
So let's say first I went and tried to see
if they used an HTTP redirect.
With an HTTP redirect, all traffic is redirected
to a web server that they control,
and then this web server redirects the clients
to the captive portal using an HTTP status code of 302.
In the case of this in-flight Wi-Fi,
that is not what they were using,
and so I moved on in my troubleshooting efforts.
Second, I looked to see if they were using ICMP packets
to redirect me to a captive portal.
Now, ICMP is a network protocol
that's used to send error messages
and operational information indicating the success
or failure of communicating with another IP address.
With an ICMP redirect, it's not a very common way
to do captive portals these days, at least in my experience,
and again, I found that they were not using that
inside of the in-flight Wi-Fi,
and so I moved on to step three.
Step three is probably your most common type,
and this is what's known as a DNS redirection.
Now, when the client joins the in-flight Wi-Fi
onboard the aircraft, the client gets an IP address,
a subnet mask, a gateway,
and a DNS server IP from the network.
Now, this is all handed out to you
from the onboard DHCP server
when you connect to the network.
Now, when the client opens up a web browser
to connect to a website, like diontrain.com or google.com,
the client is going to be redirected to the onboard DNS server
and then redirected to that captive portal page.
This is exactly what the in-flight Wi-Fi
is attempting to use,
but it wasn't working on my MacBook Pro.
Now, why is that?
Well, the issue was my client was already configured
to use DNS from a static server that I assigned
and not the onboard Wi-Fi's DNS server.
Instead, I always use my DNS server as 8.8.8.8,
which is Google's DNS server, because I trust that one.
So I was configured to use Google's DNS server,
not the onboard DNS server, and therefore,
it couldn't redirect me to their captive portal.
So I quickly disconnected from Wi-Fi,
I cleared out my saved DNS setting of 8.8.8.8,
and I set to automatically be configured over DHCP,
then I reconnected to the onboard Wi-Fi.
Immediately, I was forwarded to the captive portal,
and I was able to get online and surf the web
at 36,000 feet over the Atlantic Ocean.
Isn't modern technology just wonderful?
So what are some other common captive portal issues
that you might experience?
Well, if you're dealing with a smartphone,
like an Apple or an Android device,
especially with Apple devices,
sometimes these things don't automatically load up
the captive page upon connecting to the wireless network.
If this occurs, you should first open up a web browser
and try to go to any site, like google.com or facebook.com,
something you know should always be up and available.
This should cause the captive portal's HTTP
or DNS redirects to take over
and then present you with a captive portal login page.
Now, if this doesn't work,
then you're going to need to check your IP configuration
of your smartphone and determine what the default gateway is
for that wireless network you're connected to.
Then you could type that IP address into your web browser.
This will force load the captive portal
in most cases as well.
Now, the same thing can happen on your laptops as well,
and if it does, I tend to follow the same
three-step troubleshooting process.
First, I open up a web browser and I try
to go to any website, like google.com or facebook.com.
Second, if that doesn't work,
I determine what the default gateway
for the wireless network is and I enter http://
and the IP address for that default gateway.
Then I hit enter.
Third, if that doesn't work, I verify my DNS server IPs
and I make sure that it's not set
to something like 8.8.8.8 manually,
and instead, I turn on DHCP for it to allow me
to auto-configure my DNS on my laptop
to connect to their wireless network.
Then I re-attempt step number one
by opening up a web browser and going to any website again.
Usually, these three steps
will solve most of the issues you're going to come across
with captive portals.