4 ms·

> Reverse-tunnel mode, where devices without public IPs (or a vpn) can connect to your bastion server. This may be a ridiculous question, but what's wrong with

> Reverse-tunnel mode, where devices without public IPs (or a vpn) can connect to your bastion server. This may be a ridiculous question, but what's wrong with a VPN in this scenario? Or even a SOCKS proxy, which is already widely deployed and supported? You say "without needing additional VPN or port forwarding", but I'm curious what advantages it offers over using a VPN.

mcpherrinm 6y ago
Just extra pieces to manage. With a VPN, now you need to start worrying about firewall rules (do you isolate clients? What internal resources do they get access to?), IP assignment (now you need to run a DHCP server, or handle static IP allocations). What subnets do you use for your VPN, and what happens if they conflict with the network at some of your locations? Or maybe buy a VPN appliance to do that for you. Then you need to handle VPN authentication... Lots of that is largely un-needed effort. If you just want to be able to SSH into computers, it's simpler to just have your ssh server connect back. At small scale, where an ops team can keep track of all the computers individually? yeah, VPN is probably fine, especially if you've already got one. But I think these days, a lot of people are looking at avoiding VPNs outright.
- jon-wood 6y ago
  These complications are particularly relevant if you're managing a fleet of devices on networks you don't control, such as on-prem versions of SaaS systems, or consumer IoT devices. In that situation you definitely don't want the device to be sitting around with a back door into your network, and subnet conflicts are often impossible to resolve.
acdha 6y ago
VPNs are a huge security risk: you’re installing a lot of complex code and configuration into a secure context listening on an open network port, and you almost certainly open more traffic than just SSH so an attacker who compromises a VPN client can attack those services, too. They have advantages, too, but it’s not a simple decision. A reverse tunnel where the server has an agent which opens an outbound connection to receive requests over cuts a bunch of risks out of your environment and it’s less work to operate, too.

mcpherrinm 6y ago

Just extra pieces to manage. With a VPN, now you need to start worrying about firewall rules (do you isolate clients? What internal resources do they get access to?), IP assignment (now you need to run a DHCP server, or handle static IP allocations). What subnets do you use for your VPN, and what happens if they conflict with the network at some of your locations? Or maybe buy a VPN appliance to do that for you. Then you need to handle VPN authentication... Lots of that is largely un-needed effort. If you just want to be able to SSH into computers, it's simpler to just have your ssh server connect back. At small scale, where an ops team can keep track of all the computers individually? yeah, VPN is probably fine, especially if you've already got one. But I think these days, a lot of people are looking at avoiding VPNs outright.

jon-wood 6y ago
These complications are particularly relevant if you're managing a fleet of devices on networks you don't control, such as on-prem versions of SaaS systems, or consumer IoT devices. In that situation you definitely don't want the device to be sitting around with a back door into your network, and subnet conflicts are often impossible to resolve.

acdha 6y ago

VPNs are a huge security risk: you’re installing a lot of complex code and configuration into a secure context listening on an open network port, and you almost certainly open more traffic than just SSH so an attacker who compromises a VPN client can attack those services, too. They have advantages, too, but it’s not a simple decision. A reverse tunnel where the server has an agent which opens an outbound connection to receive requests over cuts a bunch of risks out of your environment and it’s less work to operate, too.