On 2019-02-25, Frank Beuth <[email protected]> wrote: > On Sun, Feb 24, 2019 at 03:12:31PM +0000, Stuart Henderson wrote: >>Basically I'm trying to say, if you wanted to do it the other way round >>(pass by default, block certain traffic) you wouldn't be able to block >>everything. >> >>If you're trying to stop all possible paths something on the system >>might use to exfiltrate information then this is important (for example >>if ping(1) is available and you're not blocking ICMP, this could be used >>even as non-root with ping -p). > > I see. "If you're in a situtation that requires blocking everything, then you > should block by default" seems logical enough. > > Not sure if there's any situation where you want to block by default but > allow > ICMP, that might be a bigger issue. > >>> I had no idea there was such a thing as SSH tun forwarding, thanks for >>> telling me about it! :) >> >>A useful addition to the toolkit :) > > Do you know how (or how well!) it handles the performance issues associated > with TCP-over-TCP? e.g > http://sites.inka.de/bigred/devel/tcp-tcp.html > https://unix.stackexchange.com/questions/34499/are-there-disadvantages-in-ssh-tunneling > > apropos: > https://github.com/sshuttle/sshuttle
I've not done much with ssh tun forwarding, but I have previously had to run openvpn over TCP and didn't find that it really get in the way in practice, even with connections over wifi. It would depend on connection characteristics though. The sshuttle documentation mostly talks about lack of feedback into TCP's congestion control mechanism; that could be mitigated by "regenerating" the TCP sessions on the tunnel endpoint, I think it maybe possible to bodge this together using relayd's "forward to destination". But I would only mess about with that if I had tried it and was seeing things working poorly, rather than just for the sake of maybe making things faster.
