Disclaimer: AI-assisted content. May contain errors or incorrect assumptions. Verify technical claims independently.

Most of us connect to college Wi-Fi without thinking about what happens behind the Connect button. I became curious about two things: what infrastructure powers our Wi-Fi, and how are websites such as YouTube restricted during academic hours?

I am not from a Cybersecurity background, so I used AI as an interactive tutor. I collected information normally visible to a connected device, asked AI to explain the technical output, and used additional harmless diagnostics to verify the conclusions.

No passwords were cracked, systems scanned, vulnerabilities exploited, or restrictions bypassed.

The Wi-Fi

The network advertises WPA2-Enterprise with IEEE 802.1X authentication, PEAP and AES/CCMP encryption.

In simpler terms:

• WPA2-Enterprise is designed for organizations rather than normal home Wi-Fi.
• 802.1X controls who is allowed onto the network.
• PEAP is the authentication method being used.
• AES/CCMP encrypts the wireless traffic.

Students have individual identities, although the password is shared within each batch.

The authentication process can therefore be simplified as:

Student identity + batch password ↓ 802.1X / PEAP ↓ WPA2-Enterprise ↓ Campus network 

The Wireless Infrastructure Is Cisco

Every Wi-Fi access point has a BSSID, usually based on its MAC address. The manufacturer can often be identified from the beginning of that address, called an OUI.

The access-point identifiers observed on the network belong to Cisco Systems.

The Wi-Fi management frames also advertised Cisco-specific information related to CCKM — Cisco Centralized Key Management, which helps devices roam efficiently between access points.

Together, these provide strong evidence that the college uses a centrally managed Cisco wireless network.

Both 2.4 GHz and 5 GHz access points were observed.

The network also broadcasts different SSIDs, including an enterprise-authenticated network and a PSK-based network. Enterprise access points can broadcast several logical Wi-Fi networks from the same hardware.

Evidence of a Cisco Wireless Controller

Another unusual clue appeared through DHCP.

DHCP is the protocol that automatically gives a device its IP address, gateway and DNS servers.

The DHCP information contained the address:

1.1.1.1 

Today that address is famous as Cloudflare DNS, but older Cisco Wireless LAN Controllers historically used 1.1.1.1 as a virtual controller address.

Combined with the other Cisco fingerprints, this strongly suggests a Cisco Wireless LAN Controller-style architecture.

The first network gateway also used Cisco-associated hardware.

That did not prove the firewall was Cisco, however. The firewall could be a completely different product farther upstream.

And that turned out to be exactly the interesting part.

How YouTube Is Restricted

The first clue came from DNS.

DNS translates names such as:

www.youtube.com 

into destinations computers can reach.

During the restricted period, one DNS path returned:

www.youtube.com ↓ restrict.youtube.com 

A CNAME DNS record was effectively redirecting YouTube toward Google's restricted YouTube infrastructure.

This provides strong evidence that DNS policy is one part of the restriction system.

Interestingly, even a query intended for a public DNS resolver produced the restricted YouTube result. This suggests additional DNS-policy enforcement somewhere in the network path, although the exact internal mechanism cannot be proven from a student device.

The Firewall Revealed Itself Through HTTPS

The strongest clue came from the HTTPS certificate presented when connecting to YouTube.

Instead of the normal public certificate chain, the certificate issuer contained:

Fortinet FortiGate CA 

That directly identifies Fortinet FortiGate infrastructure as being involved in web-security enforcement.

HTTPS normally uses TLS certificates to prove that a client is communicating with the intended website.

For an ordinary website:

Website ↓ normal public certificate ↓ encrypted connection 

For restricted YouTube traffic, the observed behavior was:

YouTube ↓ FortiGate security policy ↓ FortiGate-issued certificate ↓ restricted connection 

When the diagnostic client was told to accept the certificate temporarily, the network still returned:

HTTP 403 Forbidden 

So nothing was bypassed. The firewall policy remained active.

Other allowed websites presented their normal certificates, suggesting that this FortiGate handling is selective rather than being applied identically to every HTTPS website.

We cannot determine from the client side whether this represents full deep TLS inspection in every case or a more limited inspection/blocking mechanism.

Why Is It Blocked Only During Academic Hours?

YouTube is restricted during academic hours but becomes accessible later.

That behavior is strongly consistent with a scheduled network-security policy.

Conceptually:

Academic hours ↓ stricter student policy ↓ streaming / YouTube restrictions Outside academic hours ↓ less restrictive policy ↓ normal access 

Enterprise firewalls such as FortiGate support time-based policies, although the exact rule configuration cannot be seen from a student device.

What the Network Appears to Look Like

Putting the observations together:

Student device ↓ WPA2-Enterprise 802.1X / PEAP / AES-CCMP ↓ Cisco access points ↓ Cisco wireless controller ↓ Campus routing ↓ DNS policy + Fortinet FortiGate ↓ Internet 

The real infrastructure is undoubtedly more complex, but this represents what the available evidence supports.

What AI Changed

The most interesting part of this experiment was not simply discovering Cisco and Fortinet.

It was how quickly AI made an unfamiliar technical subject understandable.

Terms such as:

BSSID OUI 802.1X PEAP CCMP DHCP CNAME TLS CA HTTP 403 

initially looked like unrelated networking jargon.

AI helped turn each one into a learning step:

Observe something ↓ Ask AI what it means ↓ Understand the protocol ↓ Form a hypothesis ↓ Check it using another harmless observation ↓ Refine the conclusion 

AI was not the source of the evidence. The evidence came from the network protocols themselves.

AI helped interpret, connect and verify that evidence.

That distinction matters. For example, seeing a Cisco gateway did not justify claiming that the firewall was Cisco. The Fortinet conclusion only became strong when an independent TLS certificate explicitly identified a FortiGate CA.

Conclusion

What initially looked like:

College Wi-Fi → Internet 

turned out to involve:

WPA2-Enterprise ↓ 802.1X + PEAP ↓ AES/CCMP ↓ Cisco wireless infrastructure ↓ Campus routing and DNS policy ↓ Fortinet FortiGate web security ↓ Time-dependent Internet restrictions 

The larger lesson was how useful AI can be when learning outside your own field.

It did not replace technical evidence or verification. It made that evidence understandable.

What began as simple curiosity about college Wi-Fi became a practical introduction to wireless networking, authentication, DNS, routing, TLS and firewalls — with AI acting as the tutor connecting everything together.