You might be looking for the "ssh socks proxy" option (-D?).
this post was submitted on 02 Apr 2025
15 points (94.1% liked)
Linux
52771 readers
761 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
Wireguard might be what you want. You connect to your remote machine ( assume it is at home). You can setup what traffic goes over wireguard (some or all). On your home machine you can run port forward command and masquerading command once connected on home machine so that you have full lan access too. It is described in the wireguard setup docs.
You can but it kind of sucks and you would only normally do it on a very temporary hacky basis. Otherwise use OpenVPN or Wireguard or whatever. If you want to do it with ssh, see the VPN instructions on the man page. But I mean it's janky.
Wire guard + some nft tables or ip tables rules is a much better solution.
Ssh on itself can do the port forward part but for the routing you still need the above mentioned rules. In addition, ssh will not autoreconnect if anything happens and you need to add autossh or some other solution to keep it rolling.
I'm not sure if you can do it without authenticating on the remote. Have you seen sshuttle? Maybe you can run that on the remote to connect to the local machine. If the issue is that the remote "can't see" the local machine to ssh into it then you could try something like reverse tunnel the ssh port to the remote, and then use sshuttle to connect to the local port that is forwarding traffic.
- ssh to remote, forwarding some remote port to your local ssh port (-R)
- ssh from remote through the exposed port, starting socks proxy in the process (-D)
- use socks proxy explicitly or find some tool that can route the traffic into it
Similar approach can be used to establish VPN tunnel with no encryption (ssh already provides that), routing everything but your ssh connection through it.
- ssh to remote, reverse forwarding your VPN-over-tcp server’s listening port
- establish vpn connection on remote, route everything but your ssh connection through the newly established interface
It will be wasteful, but it will work.
Sshutle? It essentially makes traffic go through ssh from anywhere to anywhere. If you ssh into your machine, use sshuttle towards your local machine, I think you should be good
So in summary you have your device A and services running on B, you connect to a vpn service using A, and you want the services running on B to use the same vpn connection?
I encountered this problem with torrenting and private trackers.
I solved it the other way around, by having the remote connect to the vpn and routing traffic from my device through that remote.
- get a mullvad subscription because they do wireguard
- create wireguard-outbound container on server and connect to mullvad
- create wireguard-inbound container on server and attach it to the network stack of wireguard-outbound
- attach any other containers on the server you want using the vpn to the network stack of wireguard-outbound
- install wireguard on your various devices instead of connecting to mullvad directly just connect to your wireguard-inbound container
For bonus points you can create a squid (proxy service) container and attach that to wireguard-outbound, then create a firefox profile that connects to that proxy. That way your device isn't routing all traffic through the vpn, only the traffic from that firefox profile.
I've had this set up for several years now and for the most part it works very well. Occasionally I have to restart the containers but for the most part it's great.
I see that containers get lot of love, but really setting up wireguard is writing a text config file, why would you need containers for that?
One use for wireguard in a container is that if you're using other containers on the same host you can use container magic to route the traffic of specific containers through the wireguard tunnel, while other containers bypass the tunnel.
Well, you don't need containers for wireguard the same way you don't need containers for anything.
I personally prefer docker containers for everything that can be containerised because it provides a consistent abstraction layer. As in, I always know how to find configurations and paths and manage network infrastructure for anything that resides in a container.
In the case I outlined above with the wireguard containers, I'm more confident I'm not going to upset any other services on my server, and I understand the configuration.
Maybe it's a bit like using ufw to manage iptables rules, unnecessary but helpful.
Of course, I freely admit that my way is not necessarily the best way and if someone wants to run wireguard on the host then great.
Thanks for the clarification, it make sense indeed, specially if you don't come from a long term Unix background.
Today Linux world feels more and more unnecessarily complicated somehow. I am getting old.
Try googling something like "how to make a VPN server"
Wut. C'mon.
If I'm reading this right, you just need to learn about routing. SSH has nothing to do with this. This is basic networking at best.
IDK anything about "routing" but I don't think it can solve this problem without additional services.
If my laptop is A and I want all outbound connections to go through server B then B needs to be running some kind of service whether it's merely a NAT router or VPN or proxy.
In this case OP actually want's B's outbound connections to go through A but it's the same problem.
Love that you put it in quotes as if to be sarcastic. Hilarious.
This is basically how the entire Internet works, but you know that from your post. Surely you also know that traffic gets "routed" from place A to B all the time without SSH as well.
So if you want to "route" a remote instance back to another place, you:
- Set routing rules on the intended origin
- Set default route on the remote client
- Set restricted firewall rules so both the origin and client are allowed to talk to each other
- Traffic is routed
Another alternative is using Tailscale and setting an exit node on your network, which is essentially the same thing.
But you already knew that, and that's why you chimed in with your comment. Stupid me.
How fucking stupid must I look, huh?
Sure mate.
I've been playing around with networks for decades. I'll happily admit that my understanding is rudimentary at best, but configuring routing rules with IP tables or whatever so your device will act as a NAT seems a few levels beyond "basic networking".
that's why you chimed in with your comment. Stupid me.
The honest to god reason I chimed in was because your response seemed derisive, and I thought I might be able to soften a bit by either showing my own ineptitude or challenging your solution.