vpn.drew.edu / vpn.uu.edu / vpn.valpo.edu (SonicWall)

DimitriPapadopoulos commented 2 years ago

Gateway vpn.drew.eduis not detected:

$ what-vpn -v -K vpn.drew.edu

Sniffing vpn.drew.edu ...
  Is it AnyConnect/OpenConnect? connection error
  Is it Juniper/Pulse? no match
  Is it PAN GlobalProtect? no match
  Is it Barracuda? no match
  Is it Check Point? timeout
  Is it SSTP? connection error
  Is it OpenVPN? no match
  Is it Fortinet? no match
  Is it Array Networks? no match
  Is it F5 BigIP? no match
  Is it SonicWall NX? no match
  Is it Aruba VIA? no match
  => timeout
$

It is clearly a SonicWall VPN:

DimitriPapadopoulos commented 2 years ago

The timeout originates here: https://github.com/dlenski/what-vpn/blob/d76f7aa83df4e5b4376efc3d31c499262585b17f/what_vpn/sniffers.py#L106

We shouldn't need to pass the -K option, it should be on by default.

DimitriPapadopoulos commented 2 years ago

Is it expected that path /sslvpnclient?launchplatform=mac&neProto=3&supportipv6=yes returns a 404?

404

DimitriPapadopoulos commented 2 years ago

Gateway vpn.valpo.edu is not detected either:

$ what-vpn -v vpn.valpo.edu

Sniffing vpn.valpo.edu ...
  Is it AnyConnect/OpenConnect? no match
  Is it Juniper/Pulse? no match
  Is it PAN GlobalProtect? no match
  Is it Barracuda? no match
  Is it Check Point? no match
  Is it SSTP? no match
  Is it OpenVPN? no match
  Is it Fortinet? no match
  Is it Array Networks? no match
  Is it F5 BigIP? no match
  Is it SonicWall NX? no match
  Is it Aruba VIA? no match
  => no match
$

Yet it is SonicWall according to the HTML code of https://vpn.valpo.edu/spog/welcome:

<!DOCTYPE html><html><head><meta charset=utf-8><meta name=viewport content="width=device-width,initial-scale=1"><meta name=brandName content="SonicWall"><meta name=modelNameShort content="SMA">

dlenski commented 2 years ago

We shouldn't need to pass the -K option, it should be on by default.

The use case for this option is to do what-vpn hundreds or thousands of potential servers as in the "surveys" described in the README.

If you get timeouts/SSL errors/DNS errors, you don't want to waste time re-trying TLS/HTTPS connections to such servers, in order to speed up the overall run.

In "normal" usage I don't think this behavior is desirable, since some servers have flaky behavior that will (for example) abruptly disconnect TLS sockets when they get HTTPS requests that they don't understand. This monstrosity is a chief offender.

DimitriPapadopoulos commented 2 years ago

Same with vpn.uu.edu:

$ what-vpn -K -v vpn.uu.edu

Sniffing vpn.uu.edu ...
  Is it AnyConnect/OpenConnect? connection error
  Is it Juniper/Pulse? no match
  Is it PAN GlobalProtect? no match
  Is it Barracuda? no match
  Is it Check Point? timeout
  Is it SSTP? connection error
  Is it OpenVPN? no match
  Is it Fortinet? no match
  Is it Array Networks? no match
  Is it F5 BigIP? no match
  Is it SonicWall NX? connection error
  Is it Aruba VIA? no match
  => timeout
$

Again a SonicWall:

vpn uu edu

DimitriPapadopoulos commented 2 years ago

About -K I am unable to understand the rationale for not making it the default.

For example, even if SonicWall detection was updated, the script would still fail with a timeout in Check Point detection before even making it to SonicWall detection:

$ what-vpn -v vpn.uu.edu

Sniffing vpn.uu.edu ...
  Is it AnyConnect/OpenConnect? connection error
  Is it Juniper/Pulse? no match
  Is it PAN GlobalProtect? no match
  Is it Barracuda? no match
  Is it Check Point? timeout
  => timeout (tried 5/12 sniffers)
$


$ what-vpn -K -v vpn.uu.edu

Sniffing vpn.uu.edu ...
  Is it AnyConnect/OpenConnect? connection error
  Is it Juniper/Pulse? no match
  Is it PAN GlobalProtect? no match
  Is it Barracuda? no match
  Is it Check Point? timeout
  Is it SSTP? connection error
  Is it OpenVPN? no match
  Is it Fortinet? no match
  Is it Array Networks? no match
  Is it F5 BigIP? no match
  Is it SonicWall NX? connection error
  Is it Aruba VIA? no match
  => timeout
$

dlenski commented 2 years ago

About -K I am unable to understand the rationale for not making it the default.

So you'd prefer to have the --keep-going-after-exception behavior as the default, but with a flag to the the opposite?

Perhaps --stop-after-exception to keep the current default behavior?

DimitriPapadopoulos commented 2 years ago

I may be missing something, but it looks like failure on timeout in a sniffer may result in skipping all the following sniffers. That's not something we want. If so, yes, the default should be -K.

Actually, we should probably handle SSL exceptions and timeouts differently:

An SSL error in a sniffer will probably be followed by the same exception in the next sniffer. It doesn't make much sense to retry upon an SSL failure.
A timeout in the CheckPoint sniffer doesn't imply a timeout in the next sniffer, so we should try the next sniffer upon a timeout.

In short:

We should always try all sniffers in case of a timeout. I don't even see the need for an option to disable that, as it may result in false-negatives.
We shouldn't keep testing other sniffers in case of an SSL error. I don't see the need for an option to disable that.

dlenski commented 2 years ago

Actually, we should probably handle SSL exceptions and timeouts differently:

Agreed, but based on the practical experience of running this I think the default behavior should actually be reversed…

An SSL error in a sniffer will probably be followed by the same exception in the next sniffer. It doesn't make much sense to retry upon an SSL failure.

Many VPN servers are buggy and they don't really speak HTTP(S) in a general-purpose way. Some of them abruptly terminate TLS sockets or mis-encode their output, when they get HTTP requests that they don't understand… because they're aimed at different VPN protocols. (There's one related-ish case where we explicitly check for, and ignore, such misbehavior.)

If we give up after an SSL failure, we'll get some false negatives.

A timeout in the CheckPoint sniffer doesn't imply a timeout in the next sniffer, so we should try the next sniffer upon a timeout.

When doing a large "survey" run, the most common cause of a timeout is that the DNS name exists… but it isn't listening on the given port. That's going to repeat over and over.

Perhaps what we really need here are separate flags to --{give-up,keep-going}-after-timeout, `--{give-up,keep-going}-after-ssl-errors, and then we can argue about the sensible defaults :)

dlenski / what-vpn

vpn.drew.edu / vpn.uu.edu / vpn.valpo.edu (SonicWall) #14