4 ms·

SSH tunnels are my favorite tool for NAT-busting. I always have to look up the cryptic syntax, but with one strategically placed Raspberry Pi, you can basically

by ohazi 6y ago

SSH tunnels are my favorite tool for NAT-busting. I always have to look up the cryptic syntax, but with one strategically placed Raspberry Pi, you can basically get from anywhere to anywhere. And it works just as well on a locked down corporate network as it does on a home network. Why people put up with garbage VPN software is beyond me.

lxgr 6y ago
SSH isn’t a replacement for VPNs. I’d argue that they complement each other. For example, SSH port forwarding is TCP only, so if you need UDP, you‘ll need a VPN.
- xioxox 6y ago
  [note I am wrong here - it doesn't support UDP - see below] The ssh SOCKS proxy supports UDP. I use Firefox with a SOCKS proxy via ssh (e.g. ssh -D 2222 hostname) to get around geoblocking and accessing papers via an institutional account. The tsocks program can also let you use a SOCKS proxy for an arbitrary command in linux. I find it much more convenient than a VPN, as it can be easily applied to single programs.
  - cryo 6y ago
    Are you about this? Last time I've checked SSH SOCKS5 only supports TCP traffic, UDP isn't supported and needs extra steps through tools like socat to wrap UDP in TCP. http://lists.mindrot.org/pipermail/openssh-unix-dev/2017-January/035662.html http://lists.mindrot.org/pipermail/openssh-unix-dev/2017-Jan...
    - xioxox 6y ago
      It looks like I was wrong about UDP being supported by ssh. Sorry about misleading everyone. I've verified with nc that it doesn't actually forward UDP. I'm amazed that streaming media over this seems to work fine on most sites, though.
      - lxgr 6y ago
        Many applications these days can fall back to TCP because UDP is often blocked (almost never for good reasons, but that's another discussion). For real-time applications, that fallback usually comes with a loss in quality/interactivity, though. Alternatively, you might be unknowingly using un-proxied UDP: Many AV systems only enforce IP restrictions on the signalling protocol (which is often TCP); the actual media can then take whatever path it wants. By the way, it seems like you can forward UDP over sshuttle [1] when used with tproxy (which seems to be a Linux-only feature)! [1] https://sshuttle.readthedocs.io/en/stable/tproxy.html https://sshuttle.readthedocs.io/en/stable/tproxy.html
  - lxgr 6y ago
    For single applications that are able to "cooperate" with being proxied, a proxy server can make much more sense than a VPN, yes. The less cooperative your applications are (even though cooperation can be somewhat enforced using tsocks, as you mention, which can be further made to apply system-wide using sshuttle [1]), the more a VPN will start to make sense. [1] https://github.com/sshuttle/sshuttle https://github.com/sshuttle/sshuttle
  - throw0101a 6y ago
    Note that the default port for SOCKS(5) is 1080, and the de facto standard for (forward) web proxies (e.g., Squid) is 3128, so one may want to make of habit of using one of those ports.
    - iso1210 6y ago
      3128 is a common http/s proxy sure, but so is 8080, and I've seen 80 a few times too. 1080 is often default for socks, but I've also seen places where it's 1085 (for socks5 -- 1084 for socks4) Ultimately it can be whatever you want.
- codetrotter 6y ago
  Indeed. For VPN, use Wireguard. It’s open source, easy to configure, and works excellently. https://www.wireguard.com/ https://www.wireguard.com/
- beermonster 6y ago
  Actually, OpenSSH has built-in TUN/TAP support using -w<local-tun-number>:<remote-tun-number>. You can create a layer 3/point-to-point/ TUN tunnel or layer 2/ethernet/TAP tunnel. I used to run a site-to-site VPN between two sites a couple of decades ago with a simple script doing just this. These days we'd use OpenVPN or strongSwan for such use-cases but despite the 'hackiness' of the former approach, it worked reliably for years.
  - lxgr 6y ago
    OpenSSH VPNs suffer from TCP-over-TCP [1]. I'd only use them as a last resort. Sometimes I actually wish SSH would offer UDP support for precisely this use case, but arguably, TCP VPN support is already a stretch in terms of scope for SSH. [1] http://sites.inka.de/sites/bigred/devel/tcp-tcp.html http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
accrual 6y ago
One can further tunnel SSH inside of TLS with Stunnel [0] to get through firewalls that block SSH but permit arbitrary TLS connections. Loading a website through this requires three layers of TCP but assuming the connection is good this should be okay. A couple reasons for a regular VPN: they can be made automatic and persistent so the tunnel is always ready for use, they can tunnel other protocols besides TCP, they can tunnel entire networks, and using UDP as the tunnel protocol helps avoid the TCP-in-TCP congestion issues. [0] https://en.wikipedia.org/wiki/Stunnel https://en.wikipedia.org/wiki/Stunnel
- 0x0 6y ago
  Stunnel and ssh tunnels don't put TCP inside TCP so it shouldn't risk any TCP-in-TCP congestion issues?
  - labawi 6y ago
    Yes, and piecewise TCP is often even faster than point-to-point TCP, especially on flaky connections, or when the transient connections are on hosts with lower RTTs (outgoing gateway closer to destination). It will likely be faster than a UDP VPN. It still does have overhead, so lower bandwidth. Also, TCP, SSH and/or TLS forwarding of UDP, IP or Ethernet can have issues with delays, re-transmits etc (TCP-in-TCP).
  - efreak 6y ago
    SSH is a TCP connecting though, isn't it? How do you avoid TCP inside TCP when both are TCP? Oram I missing something?
    - 0x0 6y ago
      It just relays the packet payload (i.e the actual data bytes inside the TCP stream are read out from the source, then sent along to the destination inside a different TCP stream. TCP/IP headers aren't included or replayed).

by ohazi 6y ago

lxgr 6y ago

SSH isn’t a replacement for VPNs. I’d argue that they complement each other. For example, SSH port forwarding is TCP only, so if you need UDP, you‘ll need a VPN.

xioxox 6y ago
[note I am wrong here - it doesn't support UDP - see below] The ssh SOCKS proxy supports UDP. I use Firefox with a SOCKS proxy via ssh (e.g. ssh -D 2222 hostname) to get around geoblocking and accessing papers via an institutional account. The tsocks program can also let you use a SOCKS proxy for an arbitrary command in linux. I find it much more convenient than a VPN, as it can be easily applied to single programs.
- cryo 6y ago
  Are you about this? Last time I've checked SSH SOCKS5 only supports TCP traffic, UDP isn't supported and needs extra steps through tools like socat to wrap UDP in TCP. http://lists.mindrot.org/pipermail/openssh-unix-dev/2017-January/035662.html http://lists.mindrot.org/pipermail/openssh-unix-dev/2017-Jan...
  - xioxox 6y ago
    It looks like I was wrong about UDP being supported by ssh. Sorry about misleading everyone. I've verified with nc that it doesn't actually forward UDP. I'm amazed that streaming media over this seems to work fine on most sites, though.
    - lxgr 6y ago
      Many applications these days can fall back to TCP because UDP is often blocked (almost never for good reasons, but that's another discussion). For real-time applications, that fallback usually comes with a loss in quality/interactivity, though. Alternatively, you might be unknowingly using un-proxied UDP: Many AV systems only enforce IP restrictions on the signalling protocol (which is often TCP); the actual media can then take whatever path it wants. By the way, it seems like you can forward UDP over sshuttle [1] when used with tproxy (which seems to be a Linux-only feature)! [1] https://sshuttle.readthedocs.io/en/stable/tproxy.html https://sshuttle.readthedocs.io/en/stable/tproxy.html
- lxgr 6y ago
  For single applications that are able to "cooperate" with being proxied, a proxy server can make much more sense than a VPN, yes. The less cooperative your applications are (even though cooperation can be somewhat enforced using tsocks, as you mention, which can be further made to apply system-wide using sshuttle [1]), the more a VPN will start to make sense. [1] https://github.com/sshuttle/sshuttle https://github.com/sshuttle/sshuttle
- throw0101a 6y ago
  Note that the default port for SOCKS(5) is 1080, and the de facto standard for (forward) web proxies (e.g., Squid) is 3128, so one may want to make of habit of using one of those ports.
  - iso1210 6y ago
    3128 is a common http/s proxy sure, but so is 8080, and I've seen 80 a few times too. 1080 is often default for socks, but I've also seen places where it's 1085 (for socks5 -- 1084 for socks4) Ultimately it can be whatever you want.
codetrotter 6y ago
Indeed. For VPN, use Wireguard. It’s open source, easy to configure, and works excellently. https://www.wireguard.com/ https://www.wireguard.com/
beermonster 6y ago
Actually, OpenSSH has built-in TUN/TAP support using -w<local-tun-number>:<remote-tun-number>. You can create a layer 3/point-to-point/ TUN tunnel or layer 2/ethernet/TAP tunnel. I used to run a site-to-site VPN between two sites a couple of decades ago with a simple script doing just this. These days we'd use OpenVPN or strongSwan for such use-cases but despite the 'hackiness' of the former approach, it worked reliably for years.
- lxgr 6y ago
  OpenSSH VPNs suffer from TCP-over-TCP [1]. I'd only use them as a last resort. Sometimes I actually wish SSH would offer UDP support for precisely this use case, but arguably, TCP VPN support is already a stretch in terms of scope for SSH. [1] http://sites.inka.de/sites/bigred/devel/tcp-tcp.html http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

accrual 6y ago

One can further tunnel SSH inside of TLS with Stunnel [0] to get through firewalls that block SSH but permit arbitrary TLS connections. Loading a website through this requires three layers of TCP but assuming the connection is good this should be okay. A couple reasons for a regular VPN: they can be made automatic and persistent so the tunnel is always ready for use, they can tunnel other protocols besides TCP, they can tunnel entire networks, and using UDP as the tunnel protocol helps avoid the TCP-in-TCP congestion issues. [0] https://en.wikipedia.org/wiki/Stunnel https://en.wikipedia.org/wiki/Stunnel

0x0 6y ago
Stunnel and ssh tunnels don't put TCP inside TCP so it shouldn't risk any TCP-in-TCP congestion issues?
- labawi 6y ago
  Yes, and piecewise TCP is often even faster than point-to-point TCP, especially on flaky connections, or when the transient connections are on hosts with lower RTTs (outgoing gateway closer to destination). It will likely be faster than a UDP VPN. It still does have overhead, so lower bandwidth. Also, TCP, SSH and/or TLS forwarding of UDP, IP or Ethernet can have issues with delays, re-transmits etc (TCP-in-TCP).
- efreak 6y ago
  SSH is a TCP connecting though, isn't it? How do you avoid TCP inside TCP when both are TCP? Oram I missing something?
  - 0x0 6y ago
    It just relays the packet payload (i.e the actual data bytes inside the TCP stream are read out from the source, then sent along to the destination inside a different TCP stream. TCP/IP headers aren't included or replayed).