Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

VPN Required Login Block for React

A sign-in gate for a VPN-only console: a connection check that fails twice with different diagnoses and then passes, three numbered steps, a demo switch to pretend, and troubleshooting answers.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Tell people to connect first and let them check from the same page, with this VPN required login block for React with Base UI. It's the gate in front of Haulgate, a logistics admin console: a whole screen with the page's rails and one band across it, a centred column. A state band names where the connection stands, Not connected, Checking or Connected, as a word with a glyph and a Status dot, and one sentence that says why. The one Shine Button, Check connection, runs a scripted check of 800 milliseconds that fails with one diagnosis, fails with another and then passes, after which it reads Continue to Haulgate. A Switch marked as a demo control pretends the connection, and Start over puts the script back at its first attempt. Below sit three numbered steps (open an IKEv2 or WireGuard-compatible client, connect to the company profile, check here) and an Accordion of troubleshooting answers whose panels share one height, so opening one never moves the page. It's built from Status, Accordion, Switch, Button, Shine Button and Guides, with a CSS entrance only. For consoles, admin tools and anything that answers only on a company network.

FAQ

What stays in the page, and how do I wire it for real?

Everything, and nothing here detects a VPN. The three checks are a typed script (two failures with different diagnoses, then a pass) and the switch simply pretends. In a product the check is a request to a health endpoint that only answers on the VPN side of your network, or your gateway reports whether the session arrived through the tunnel; use the diagnosis it returns in place of the typed ones, and enforce the rule on your server, never in the page.

Why does the check fail twice before it passes?

To show two different, useful diagnoses: traffic leaving from a public network address, and a tunnel that is up with no route to the console. Each is a line in ATTEMPTS, so you can reorder them, add more or make the first one pass. Start over runs the script again from the first check.

Which VPN clients does it name?

None. It says "an IKEv2 or WireGuard-compatible client", because the page cannot know which one your company uses. Replace the three steps with your own, and name your client in them if you want to.

How does the troubleshooting list behave?

One answer is open at a time and it stays open, so every panel has the same height and the page never shifts. Tab moves between the question rows; arrow keys do not.

How is the state told apart without colour?

By the word (Not connected, Checking, Connected), a glyph (a Wi-Fi-off mark, a spinner, a tick), and the numbered steps filling in when the connection is made. The one status dot is only an extra mark on a failed state.

Is it usable with a keyboard and a screen reader?

Yes. The check is one button, its result is said in the page's single status line and takes focus, the switch is named and marked as a demo control, and each step says "Done" once the connection is made. The spinner stops moving under reduced motion.

  • Pro

    A network check for a sign-in: type an IPv4 address and real CIDR maths says which of three allowed ranges holds it, then either continues or asks for access with a reason.

  • Pro

    A sign-in that works only in set hours: a week grid of 24 hour cells for each day with a derived next window, a readout for any cell, and a request for off-hours access.

  • Pro

    A sign-in that runs four policy checks in order (device, network, identity, policy) on a vertical Steps rail with typed details, a demo control that makes the device fail, and an outcome with its fix.

  • Pro

    A sign-in that follows the browser's real online and offline events: offline it asks for an eight-character offline code and counts sessions, online it says no code is needed, in the same space.

  • Pro

    IP Address Blocked Error

    Blocked and limited

    A full-screen blocked-address page for a bot-protection layer: a review request form (organisation and reason) beside the evidence: the address with Copy, a five-part bar for 5 of 5 failed sign-ins in 10 minutes, the five attempts and when the block lifts.

  • Pro

    Account Locked Login

    Recovery and reset

    A locked-account page for a point-of-sale system that draws the lockout ladder, marks the rung the account is on with a fixed unlock time, and offers an unlock link by email or a password reset.