The VPN Ticket Categories and Their First Questions

Monday, 08:20, at Meridian Parts. Dana took over the desk of four a fortnight ago, and this morning there are eleven new tickets with the letters VPN in the subject line. She reads them in order. Four say "VPN not working". Two say the VPN is connected but the drawings folder will not open. One says the connection drops every twenty minutes. One, from the sales team, says everything has been slow "since the VPN". One has a screenshot of a warning about a certificate. Two say the code from the phone is "not accepted". Eleven tickets, one word in common, and her first instinct is to assign all of them to Raj, who does the VPN. Raj is in a lay-by with a flat tyre and will be in at ten.

A VPN (virtual private network) is a tunnel from a laptop, across the internet, into the office network. The laptop behaves as if it were plugged in at a desk in the building. The word covers four separate things that can each fail on their own. First is the internet connection underneath the tunnel. Second is the VPN client (the program on the laptop that builds the tunnel). Third is the gateway (the device at the office end that accepts tunnels). Fourth is the identity check, which is a password and usually a second factor. The VPN ticket categories are the six shapes a ticket takes depending on which of those failed and when. Each category has one question that sorts it from the others in about a minute. This article is part of our VPN & Remote Access Tickets series. It is the map the rest of the series is drawn on.

It covers why one word hides six problems, then the four moving parts. The six categories follow in turn, with the first question for each. These are cannot connect, connects then drops, connected but cannot reach something, slow over the tunnel, a certificate warning, and a credential or second-factor failure. Next come the share each took at a fictional desk over a month, then sorting at intake and again at close. A short war story and the category table to copy finish the article, in that order.

One Word, Six Problems

"VPN" is what the requester says because it is the icon they clicked, and the icon is the only part of remote access they can see. Think of the home router that lost its connection, the password that expired on Friday, or the phone that no longer has the authenticator app on it. Then there is the hotel network that blocks tunnels, or the internal site that has nothing to do with the tunnel at all. Every one of those arrives at the desk wearing the same word, because the symptom is always "I clicked the VPN and I cannot do my job". The desk's first job is to take the word off and look at what is underneath. Tickets, like coats, tell you very little until someone takes them off.

The reason the sort matters is that the six categories are owned by different people and fixed in different ways. A credential failure is a password ticket with a VPN subject line, and the password series in this library already owns the whole procedure. A certificate warning that two hundred people see at once is not a ticket at all but an incident. A "cannot reach the drawings folder" is a conversation about which things live on the tunnel and which do not, and no amount of reconnecting will change it. Assigning all eleven to Raj because they say VPN is a routing decision. It puts a password reset, an incident, and a networking explanation in the same queue behind the same person, who is currently changing a tyre.

The sort also matters for the count. A desk that logs everything remote as "VPN" will report, at the end of the month, that the VPN generates more tickets than anything except printing. Someone will propose replacing it. A desk that logs the six categories will report that the VPN gateway itself was the cause in a handful of tickets. It will report that passwords and second factors were the cause in a fifth of them. It will also report that the biggest single category was people whose home internet was down. Those are three different projects, and only one of them involves buying anything. The whole of Reducing VPN Tickets depends on the count being honest, and the count is only honest if the sort was.

Four moving parts, then, and the categories fall out of them. The internet connection underneath has to be up before anything else matters. The client has to be running, reasonably current, and able to see the gateway. The gateway has to be up, with a certificate the client still trusts, and accepting connections. The identity check has to pass, which means the password is current and the second factor arrives and is accepted. Only after all four is the tunnel up, and then a fifth thing can go wrong. The resource on the far side is not where the user expects it to be, or is not reachable through the tunnel at all. Each category below is one of those failing, and the first question is the one that tells you which.

Cannot Connect

The cannot connect ticket is the one where the client never reaches the connected state. The user clicks connect, something spins, and it either stops with a message or stops without one. It is the biggest category on most desks and the vaguest. "Not working" covers an internet outage at the house, a client that is not running, a wrong password, and a second factor that never arrived. It also covers a hotel network that blocks tunnels and a gateway that is down for everyone. The user cannot tell these apart and should not be expected to.

The first question is: "Can you open a public website right now, with the VPN off?" If the answer is no, the ticket is not a VPN ticket; it is a home internet ticket. The user needs their connection back before any tunnel can be built on it. If the answer is yes, the fault is somewhere in the client, the credentials, the second factor, the network they are on, or the gateway. Those are checked in order of cost in Can't Connect: The VPN Diagnostic Order, Cheapest First. Ask the first question before anything else, every time. About a quarter of this category at the fictional desk below turned out to be an internet connection that had quietly gone away. The VPN was blamed for a router. The router did not mind.

A second, quick question narrows the rest: "What does the message say, word for word?" A message about credentials or a certificate sends the ticket to that category. A message about the gateway not responding, from one user, is probably their network; from three users in five minutes, it is everyone's, and the ticket has stopped being a ticket. Write both answers in the first note, so that whoever picks the ticket up next, possibly Raj at ten, does not have to ask them again.

Connects, Then Drops

The connects then drops ticket is the one where the tunnel comes up and then goes away on its own. Sometimes this happens after a fixed interval and sometimes whenever the user does something in particular. The usual suspects include the laptop going to sleep or moving between wireless access points at home or in a building. Another is a home connection that drops for a few seconds every so often. Then there is the gateway's idle timeout (the period after which it closes a tunnel that has carried no traffic). There is also a venue network that tolerates a tunnel for a while and then stops. None of those is a broken VPN, and all of them look like one.

The first question is: "How long does it stay up, and what are you doing when it drops?" A drop at a regular interval, with the user doing nothing, is almost always a timeout or a sleeping laptop. A drop when they walk from the kitchen to the study is wireless roaming. A drop at random, with the home video call stuttering at the same moment, is the home connection. The article on the home network variable owns the honest conversation about what the desk can and cannot do about it. A drop that happens only in one building is the building. Ask for a count as well as a description: "three times yesterday, each after about twenty minutes" is a diagnosis; "it keeps dropping" is a mood.

Connected But Cannot Reach Something

The connected but cannot reach ticket is the one where the client says connected, in green, and the thing the user wanted still does not open. The tunnel is up. The problem is on the far side of it, or on the near side, and the user has no way to tell which. This category is almost entirely about split tunnelling and internal names that only exist inside the office. Split tunnelling is the client deciding, destination by destination, what goes through the tunnel and what goes straight out to the internet. Both split tunnelling and internal names are explained in plain words in Connected But Can't Reach It, which also carries the sheet of what works where that this category keeps asking for.

The first question is: "What exactly are you trying to open, and does anything else on the office network work?" The first half tells you whether the thing lives on the tunnel side or the other side. The tunnel side has the file share, the finance system and the intranet. The other side has a public site, the home printer and a cloud service. The second half tells you whether the tunnel is really carrying traffic or has merely turned green. A user who can open the intranet test page but not the drawings folder has a permissions problem, not a VPN problem. A user who can open nothing on the office network at all has a tunnel that is up in name only. The word "connected" on a VPN client is an opinion, and the test page is the fact.

This is also the category where "it worked yesterday" is most often true and least often useful. Yesterday the user was in the office, where everything is reachable without a tunnel. Today they are at home with a split tunnel and a bookmark that uses a short internal name. Nothing has broken; the ground has moved, and only the sheet of what works where stops the same person raising the same ticket next week about a different bookmark.

Slow Over the Tunnel

The slow over the tunnel ticket is the one where everything works and everything is worse. Files take minutes, the video call stutters, the finance system pauses between screens. The tunnel adds overhead to every byte that passes through it. On a full tunnel, where all traffic goes to the office and out again, it adds the office's internet connection to the path as well. So a video call from a house in one town to a house in the next now travels via the office. The call was never designed to commute.

The first question is: "Is it slow with the VPN off too?" If the public site, or the cloud service, or the video call is just as slow with the tunnel down, the tunnel is innocent. The ticket belongs to the slow-internet series. That series owns the isolation of user, device, network or expectation and the measurements to collect before anybody touches anything. If it is fast with the VPN off and slow with it on, the tunnel is the variable. The next question is whether the slow thing needed to be on the tunnel at all. A video call on a full tunnel is slow by design. A file share on any tunnel is slower than in the office by design. The finance system pausing for thirty seconds between screens is not by design, and that one goes to the gateway owner with numbers attached. The expectation half is real too. A user who has moved from a desk in the office to a kitchen table is comparing the tunnel with a cable, and the cable will win. Ask the first question, write down the two measurements, and resist the urge to reconnect the tunnel as if that were a fix.

A Certificate Warning

The certificate warning ticket is the one with a screenshot of a dialog saying the connection cannot be trusted. Or it says that the certificate has expired, or that the identity of the gateway could not be verified. A certificate, in plain words, is the signed document the gateway shows to prove it is the office and not something pretending to be the office. It has an expiry date. When it passes, every client refuses to connect, correctly and at once, and that morning is the subject of Certificates, Expiry and the Morning Everyone Fails at Once.

The first question is: "What does the warning say, word for word, and is anyone else seeing it?" One user with a certificate warning is usually that user's laptop. It might be a client too old to trust the renewed certificate, or a laptop whose clock is wrong by a year. Or it might be a device that has been in a drawer since before the last renewal. Everyone with the same warning in the same ten minutes is the gateway. The desk should stop answering tickets one at a time and start treating it as an incident, with the first notice out in five minutes. The screenshot matters more here than in any other category, because the exact wording tells the gateway owner which of three or four things has happened. "A security thing popped up" tells them nothing.

Tell users never to click past the warning, and say why in one sentence. The warning is the laptop refusing to trust something, and the fix is to make the something trustworthy again, not to teach the laptop to stop asking. This is one of the few places where a help desk article gets to be unambiguous about security, so enjoy it.

A Credential or Second-Factor Failure

The credential or second-factor failure ticket is the one where the client reaches the gateway, asks for a password and a second factor, and one or both are refused. The password half is a password ticket in disguise. The password expired, or the user changed it on Friday and the client saved the old one. Or the account is locked after too many tries, or disabled because the contractor's end date passed. The second-factor half is a device problem in disguise. The phone is new and the authenticator app was never moved across, or the phone is lost. Or the code is being typed from an app whose clock has drifted, or the prompt is going to a device that is in a different room.

The first question is in two parts: "Does the same password work for webmail, and did the prompt or code arrive on your phone?" A password that fails everywhere is a password ticket. The verification standard, the reset and the lockout investigation all live in the Password & Lockout Tickets series, which this category links rather than repeats. A password that works for webmail and fails for the VPN is the client holding a stale copy, and the fix is to make it forget. A prompt that never arrives, or a code that is always refused, is a second-factor ticket. The article Second-Factor Problems owns the new phone, the lost device, the backup codes and the re-enrolment that must verify a person first.

This category carries the most security weight of the six. A second-factor re-enrolment done without verifying who is asking hands an attacker the one thing the second factor exists to deny them. The desk needs to treat "I have a new phone, can you reset my authenticator" with exactly the care it gives "I have forgotten my password". It needs the runbook that says what that care looks like.

The Share Each Takes at a Fictional Desk

Here is a month at Meridian Parts, a parts distributor with about a hundred and forty people who work remotely at least some of the week and a desk of four. Dana sorted every ticket with VPN in the subject into the six categories at close. This was after the cause was known rather than at intake when it was guessed. The counts below are what she got. They are one desk's month, stated as a worked example, and your mix will differ; the point is the shape, not the figures. The hours are her estimate of technician time per category, rounded to the nearest hour. That way, the desk could see where the month went as well as where the tickets came from.

Three things fall out of the table that the word "VPN" had been hiding. The gateway itself was the cause of a handful of tickets and one morning, which is a maintenance calendar problem, not a product problem. About a third of the month was passwords, second factors and home internet, none of which the VPN team can fix. All of these can be reduced by the password series, the second-factor article and the home-network article. And a fifth of the month was people who needed a sheet saying what works where, which costs an afternoon to write and nothing to publish. Dana had been about to ask for budget. She asked for an afternoon.

The hours column is the one to show upward, because it converts a count into a cost a manager can weigh. The format in The Monthly Report They Will Actually Read is where it goes. Thirty-six to forty-seven hours in a month is most of one technician. The biggest slice went on tickets where the first question, asked at intake, would have sent them somewhere cheaper.

Sorting at Intake and Again at Close

Sort the ticket twice: once at intake, from the first question, and once at close, from what it turned out to be. The intake sort decides who gets the ticket and what the first reply says. The close sort is the one the monthly count is built from. That is because the intake guess is wrong about one time in four on a VPN ticket and the close is not. The discipline of correcting the label when the cause is known, rather than leaving the first guess on the record, is argued in full in Categorize at Close, Not Just at Open. VPN tickets are the clearest case for it in the library. A "cannot connect" that was an expired password is a password ticket at close, and counting it as a VPN ticket forever is how the replace-the-VPN project gets funded.

At intake, the first note on the ticket carries the answer to the first question in the requester's words. It carries the exact message or a description of the screenshot. It says where the user is (home, hotel, a client's office, the office itself). It also says whether anyone else has reported the same thing in the last hour. Four lines. Whoever takes the ticket next starts from those four lines instead of from "VPN not working". That includes the user's future self when the same thing happens in a month. The habit of writing the note for the next reader is the whole subject of the ticket-notes series, and the four lines are its VPN edition.

At close, the category is corrected and the resolution note says what it was and what fixed it, in one sentence a colleague could act on. If the desk runs QuerySolv, a requester's reply to a resolved ticket reopens it. A wrong sort therefore comes back as a reopen on the same ticket rather than as a fresh ticket nobody connects to the first one. The reopen count by category becomes the honest score for how well the desk is sorting. The count is the thing to watch; a category with many reopens is a category where the first question is being skipped.

A Short War Story: One Word at Tollgate Foods

Ben ran the desk at Tollgate Foods, a food distributor with sixty remote sales staff. For a year every remote-access ticket had been logged under a single label that said VPN. When the operations director saw the label at the top of the monthly chart for the fourth month running, she asked Ben to evaluate a replacement. Ben spent six weeks on it. There were three product demonstrations, a vendor's day on site, a trial on five laptops, and a quote that made the finance director go quiet. Before the paper went to the board, Ben recategorised one month of the tickets by hand, which took about six hours. He found that over half had been passwords and second factors. A quarter had been sales staff whose hotel or home internet was down. The gateway itself had been the cause in fewer than one in ten. The replacement project was cancelled, the six weeks were gone, and the vendor still sends him a card. The lesson he wrote on the whiteboard was that a category called VPN measures nothing except how often people click the icon.

The Category Table

The table below is the one to put on the desk's internal page and in front of every new technician. It is joke-free and short enough to read while the user is still talking. The columns start with the category as it is logged, then what the requester usually says so a technician can match the ticket's words to a row. Next comes the first question asked before anything is touched. Then come the most common cause at a small desk (a guide, not a diagnosis), and who owns the fix once the first question has been answered. Fill in the last column for your own desk with the team or person who owns each.

Dana sorted the eleven Monday tickets against the table in about nine minutes. Four went to the password queue. Two became one note pointing at a sheet that did not yet exist. One was a laptop that slept. One went to the slow-internet process with two measurements. One was a laptop with an old client. Two were new phones that needed verification before anything else. None of them went to Raj. He came in at ten, read the notes, and wrote the sheet.

Frequently Asked Questions