1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER

  • VPN over TLS (was: site-to-site VPN with credential prompts?)

    From Stefan Monnier@21:1/5 to All on Wed Mar 26 15:20:01 2025
    I was once sitting at a $(DAYJOB) where they blocked everything but
    443 (and 80). I tunneled ssh over socat (with TLS, so that the handshake didn't look suspect, in case their firewall sniffed that).

    Reminds me: I have an OpenVPN running on port 443, specifically to
    minimize the chances that it's blocked by a firewall.

    Yet, sometimes it *is* blocked (e.g. at the public wifi in the
    hospital), presumably because it's not actually using TLS.
    [ Funnily enough I can still use SSH from that hospital. ]

    I know there's a fair amount of "work" trying to recognize VPNs to block
    them for censorship purposes, but I don't expect the local hospital to
    be part of such games. Any idea why OpenVPN-on-TCP/443 would be blocked
    while other HTTPS connections work just fine?


    Stefan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From tomas@tuxteam.de@21:1/5 to Stefan Monnier on Wed Mar 26 15:30:01 2025
    On Wed, Mar 26, 2025 at 10:16:19AM -0400, Stefan Monnier wrote:
    I was once sitting at a $(DAYJOB) where they blocked everything but
    443 (and 80). I tunneled ssh over socat (with TLS, so that the handshake didn't look suspect, in case their firewall sniffed that).

    Reminds me: I have an OpenVPN running on port 443, specifically to
    minimize the chances that it's blocked by a firewall.

    Yet, sometimes it *is* blocked (e.g. at the public wifi in the
    hospital), presumably because it's not actually using TLS.
    [ Funnily enough I can still use SSH from that hospital. ]

    I know there's a fair amount of "work" trying to recognize VPNs to block
    them for censorship purposes, but I don't expect the local hospital to
    be part of such games. Any idea why OpenVPN-on-TCP/443 would be blocked while other HTTPS connections work just fine?

    No idea. But knowing enough about those "security" departments, the folks
    doing the job usually don't get a chance to learn but get some firewall "product" shoved down their throats whose buy decision has fallen two
    (or more) layers up their hierarchy based on some golf course evaluation.

    But you sure can check TLS connectivity with curl or similar. Or,
    perhaps they have a target address whitelist (I've seen *that*, too).

    Or something.

    Call me cynic, if you want ;-)

    Cheers
    --
    t

    -----BEGIN PGP SIGNATURE-----

    iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ+QPJwAKCRAFyCz1etHa Rpr3AJ0cENqKZ/JY5qP3H+zhg185jGSXfACfb5FbidCXBDA24D5kY2hqXxdA6hw=
    =0WCa
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Claeys@21:1/5 to Stefan Monnier on Wed Mar 26 16:10:01 2025
    On Wed, 2025-03-26 at 10:16 -0400, Stefan Monnier wrote:
    Reminds me: I have an OpenVPN running on port 443, specifically to
    minimize the chances that it's blocked by a firewall.

    Yet, sometimes it *is* blocked (e.g. at the public wifi in the
    hospital), presumably because it's not actually using TLS.
    [ Funnily enough I can still use SSH from that hospital.  ]

    They probably only block ports 80 & 443, and use a “captive portal”
    where you have to agree to a ToS, and possibly log in using a
    username/password (in some cases after paying for it), to unblock those
    for your device.


    --
    Jan Claeys

    (please don't CC me when replying to the list)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)