Port forwarding goes both ways.
I may, or may not, have used ssh forwarding and reversing forwarding to create a shadow IT tunnel(s) between my home and work when VPN was acting up.
Also, SOCKS proxy is very useful if you can puncture a hole home and your work requires a proxy to access the World Wide Web from the office location.
If you have the funds the Deep Packet Inspection is a big way to defeat attempts to tunnel through HTTPS, DNS, or the like.
Even then you haven’t really solved that particular issue as it’s a people problem not a tech problem. It’s like trying to stop an employee from robbing the bank by getting a thicker vault door in that it’s just not the right type of incentive/disincentive to make an impact.
DPI just makes it harder, so does terminating ssl earlier, or blocking outbound ports.
When measuring security by "number of boxes checked", yes. Unfortunately, these boxes are often overly generic, years too old, or both.
> If you have the funds the Deep Packet Inspection is a big way to defeat attempts to tunnel through HTTPS, DNS, or the like.
What's there to inspect (unless you are decrypting all TLS in a middlebox with a root CA trusted by all clients)? How would you distinguish a "normal" WebSocket connection (as used by many sites these days) from a tunneled SSH connection, for example?
If you generally want to allow your users to reach the broader public internet (or even just web), this approach seems completely futile.
Doing something like this from host B:
ssh -N -R 1080 user@A