I wanted to improve the security of a TV connecting to a server on a different LAN, and one approach I thought of is to use a RPi on the network to look after the secure connection.

So the pi could connect to the remove server through SSH, and forward the port locally. I thought this port could then be opened, and the TV can then be pointed at the pi on the local network.

Port forwarding to the pi works but I can’t connect to it from another device, even after setting firewall settings.

Basically the firewall rule is ufw allow from 192.168.1.0/24 port 1234

Does this idea work, or is there a better approach? Am I missing something in the setup?

  • habitualTartare@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    2 days ago

    Are you connecting from a public network or something? like a hotel wifi or other?

    The easiest solution would be to setup the pi as your router and use a VPN like wireguard (wg-easy) or tailscale.

    if it is a public network, you can double NAT. There’s dedicated boxes like the GL.inet travel routers that support wireguard/openVPN and beta for tailscale. they have some features that work well with captive portals.

    If it’s a home network, you can probably use your PI as a entry/exit node or VPN client instead of using ssh.

    • eyesaremosaics@lemmy.zipOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 days ago

      It’s for a home network, I managed to get it working using port forwarding through SSH thanks to suggestions. I’m not sure what the difference is with using the pi as an entry/exit node, that is what I was trying to do with the SSH forwarding. VPN is also possible but it it would also need to be set up to go through the pi

      • habitualTartare@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 day ago

        I’m not entirely sure about the technical differences but from my understanding VPN connections are preferred. From a security perspective, ssh has some more considerations since it’s easier to detect it’s open, and you should lock down root access and other privileged accounts. but SSH seems simpler to actually get working vs a VPN solution which would probably require a reverse proxy or something to get the TV working.

        For example, compromising a ssh service gives you access to the shell immediately vs wireguard or similar that historically (from my knowledge) has had fewer critical vulnerabilities that could lead to remote code injection or access. This is also why many corporate and best practices recommend layering ssh through a private VPN like IPsec, OpenVPN, wireguard, etc.

        in practice it’s most likely fine as long as

        • you don’t use root or an account with sudo to do the ssh forwarding
        • require a ssh key for all connections (at minimum any remote/internet connections)
        • update the system regularly. you can automate security updates with unattended upgrades on debian-based systems.