<div dir="ltr"><div dir="ltr">On Tue, May 20, 2025 at 12:00\u202fPM Khalid Baheyeldin <<a href="mailto:kb@2bits.com">kb@2bits.com</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:small">Thanks John for the details.</div><div style="font-size:small">It seems OpenVPN is quite doable then ... <br></div><div style="font-size:small"><br></div><div style="font-size:small">Regarding split tunnels, it is not something I have experience with.</div><div style="font-size:small">Rather it is something that needs to be set up, in order to prevent <br></div><div style="font-size:small">ALL data from going through the VPS. Say you are traveling, and</div><div style="font-size:small">only want the data to your home server to go through the VPN, <br></div><div style="font-size:small">but your streaming from Youtube (or whatever streaming service) </div><div style="font-size:small">should go to your local provider, and NOT to the VPN, to reduce data </div><div style="font-size:small">usage and improve performance.</div><div style="font-size:small"><br></div><div style="font-size:small">That is what I understand it to be. How to do it depends on the </div><div style="font-size:small">specific tunnel or VPN used.</div></div></blockquote><div><br></div><div>This is the confusion people must have with VPNs. All the ones you see advertised are for anonymising or changing one's geolocation. The original use of a VPN was to allow secure remote access through a firewall. This is what OpenVPN does. </div><div><br></div><div>In the old days (maybe still now) some corporate VPN administrators chose to force all data through the VPN. I suppose it helped to secure the corporate data and prevent someone from hopping through the client to access the corporate network. Someone could use the SSH method below to do just that.<br><br>It is the default behaviour of OpenVPN to only route traffic to the VPN host. You have to add additional routes in the OpenVPN configuration to allow access to the network behind a client. You would have to do additional work to route all Internet data through the VPN. So by default your Internet traffic will go around the VPN.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:small">As for SSH tunneling, it turned out to be quite simple for certain</div><div style="font-size:small">use cases, and for a single or a couple of ports.</div></div></blockquote><div><br></div><div>We used SSH tunnelling a lot to access hosts behind our clients' networks. We didn't want a full VPN to all our clients, but when we needed to access a server behind a firewall or access a web interface on a device remotely we'd use SSH tunnelling. <br><br>The main drawback with SSH tunneling is that you need an SSH login on a firewall that has a routable IP address. More ISPs are putting clients behind a NAT and handing their firewall a non-routable address (e.g. 10.x.x.x or 172.16-31.x.x, 192.168.x.x.) So if you don't have SSH on your firewall, or it doesn't have a routable IP address you can't use this.<br><br>If you can SSH, it's pretty handy and less complex to do manually than the example below. I think the example below is clever and useful for some cases. To do that with 100 clients you'd have to have 100 ports and remember the ports for each. But if you just wanted to access a web server at home while remote you could do it. We used dynamic DNS at our clients and if that failed, we'd have our clients send us an email which had their IP in the header. What could be a problem is if you have VirtualHosting on the server you want to access. Since you'll be webbing to <a href="HTTP://localhost:8080">HTTP://localhost:8080</a> the "localhost" name will be passed to the web server which may not lead to any VirtualHost name. You'd have to compensate by using a static /etc/hosts entry for that name on your laptop that points to 127.0.0.1 so that you can still use the correct host name.</div><div><br></div><div>For example, we used to do this to access a printer control panel at a client:<br><br>ssh -R 8080:printer_ip:80 <a href="mailto:user@clientname.dyndns.org">user@clientname.dyndns.org</a></div><div><br></div><div>Then web to localhost:8080 to access the printer web admin interface. That's not very complicated, but it does require that the client have an SSH-capable firewall with a routable IP address.</div><div><br></div><div>What the VPN does is make you a full participant in the network, at least at the IP layer (things using physical layer discovery or broadcasting won't work without special configuration.) So you can connect to NFS servers, browse using your network's DNS server names, print, etc. There are things you may want to do that aren't tied to a specific port, use UDP, ICMP, or multiple ports. OpenVPN allows all that, SSH does not.<br><br>A VPN uses separate network addresses for clients than the network you want to access. So if you have a 192.168.0.x network at home, a 1.2.3.4 VPS you might configure a 192.168.1.x network for VPN client addresses. Because this is a new address you may have to make changes to your home firewall to allow that, presuming your home firewall is also your VPN client, it doesn't have to be, but since it's the default gateway it makes it easier to access network hosts. Otherwise all your network hosts would need a route to 192.168.1.x to the VPN host.</div><div><br></div><div>If you only need access to one host, then you can configure OpenVPN on that host and have complete access pretty easily, without firewall or routing issues.</div><div><br></div><div>Here's the addressing example (The client and home firewall will also have routable IP addresses, but it doesn't matter in this example.)</div><div><br></div><div>(Client ) ---> ( VPS VPN Server ) ---> (Home Firewal/VPN client ) ---> ( Home Network)</div><div>(192.168.1.2 ) (1.2.3.4, 192.168.1.1) (192.168.0.1, 192.168.1.3 ) (1982.168.0.x )</div><div><br></div><div>I'm not sure how well versed you are on IP routing or firewall rules, but you'll have to know at least a little.<a class="gmail_plusreply"><br></a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:small">Assume you have a VPS with the domain name of YOUR-VPS.com</div><div style="font-size:small">(if you have a fixed IP address, then you can use that too, or a Dynamic </div><div style="font-size:small">DNS service). Also assume your shell user name on it is REMOTE_USERNAME.</div><div style="font-size:small">And on the machine that is behind a firewall where you can't open external ports,</div><div style="font-size:small">nor can you have a stable external facing IP address, the internal IP address is <br></div><div style="font-size:small">192.168.0.50, and the service you want to run is on port 8080.</div><div style="font-size:small"><br></div><div style="font-size:small">You create a systemd unit file, you do:</div><div style="font-size:small"><span style="font-family:monospace">User=USERNAME<br>ExecStart=/usr/bin/autossh -N \</span></div><div style="font-size:small"><span style="font-family:monospace"> -o StrictHostKeyChecking=no \</span></div><div style="font-size:small"><span style="font-family:monospace"> -o UserKnownHostsFile=/dev/null \</span></div><div style="font-size:small"><span style="font-family:monospace"> -o PubkeyAuthentication=yes \</span></div><div style="font-size:small"><span style="font-family:monospace"> -o PasswordAuthentication=no \</span></div><div style="font-size:small"><span style="font-family:monospace"> -o ServerAliveInterval=30 \</span></div><div style="font-size:small"><span style="font-family:monospace"> -o ServerAliveCountMax=3 \</span></div><div style="font-size:small"><span style="font-family:monospace"> -i /home/USERNAME/.ssh/id_ed25519 \</span></div><div style="font-size:small"><span style="font-family:monospace"> -R YOUR-VPS.com:18080:<a href="http://192.168.0.50:8080" target="_blank">192.168.0.50:8080</a> \</span></div><div style="font-size:small"><span style="font-family:monospace"> -p 22 REMOTE_USERNAME@YOUR-VPS.com</span></div><div style="font-size:small"><br></div><div style="font-size:small">The -R line is where the magic is. It starts with the name of the external VPS</div><div style="font-size:small"><br></div><div style="font-size:small">Then because this specific service is HTTP, you need an extra step, to <br></div><div style="font-size:small">proxy it in Nginx or Caddy. <br></div><div style="font-size:small"><br></div><div style="font-size:small">Since my VPS already has Nginx, I chose that route, with this file called</div><div style="font-size:small">my.conf, in the directory /etc/nginx/sites-enabled:</div><div style="font-size:small"><br></div><div><span style="font-family:monospace"><font size="1">server {<br> server_name <a href="http://subdomain1.YOUR-VPS.com" target="_blank">subdomain1.YOUR-VPS.com</a>;<br> listen 80;<br> access_log /var/log/nginx/access-$host.log;<br> location / {<br> proxy_pass <a href="http://127.0.0.1:18080" target="_blank">http://127.0.0.1:18080</a>; # This is the tunnel port<br> proxy_http_version 1.1;<br> proxy_set_header Host $host;<br> proxy_set_header Upgrade $http_upgrade;<br> proxy_set_header Connection 'upgrade';<br> proxy_set_header Host $host;<br> proxy_cache_bypass $http_upgrade;<br> proxy_read_timeout 90;<br> proxy_connect_timeout 90;<br> proxy_buffers 8 24k;<br> proxy_buffer_size 2k;<br> }<br>}</font></span></div><div style="font-size:small"><br></div><div style="font-size:small">If you browse to <a href="http://subdomain1.YOUR-VPS.com" target="_blank">http://subdomain1.YOUR-VPS.com</a>, the request will go to Nginx</div><div style="font-size:small">which will send it to the tunnel on the VPS, which then sends it to your machine</div><div style="font-size:small">behind the firewall, then back. </div><br><div style="font-size:small">You can go a step further and setup SSL on Nginx, and the service will be https, </div><div style="font-size:small">and not plain text http.</div><div style="font-size:small"><br></div><div style="font-size:small"><div style="font-size:small">It is all transparent, and your application never knows it is behind a tunnel.</div><div style="font-size:small"><br></div><div style="font-size:small">It gets complicated if you have more services, since you need to have one <br></div><div style="font-size:small">port (18080 in the above case) assigned to each tunnel.<br></div><div style="font-size:small"><br><br></div></div></div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>John Van Ostrand<br></div><div>At large on sabbatical<br></div><br></div></div></div>