That way I, at home, would be able to connect to RPI connected to client network. Then from RPI connect to a device on their internal network? Or could my PC, at home, be able to connect to a device on their internal network directly?
There are multiple clients + on-the-road team that I’m supporting so I would need multiple licences for Win and the software I’m using + cost of x64 machines + it needs to be portable and possibly battery powered.
Your pi AllowedIPs config is too open in my opinion. People on the remote subnets should not be able to route all their traffic through your server or by just modifying their client routing. Unless that’s by design, of course.
Personally I’d set that to just the WireGuard subnet, 172.29.251.101/24. Even if you have firewalls or ACLs performing such restrictions at the server side, it’s still good practice to just have WireGuard refuse to route the packets.
Wireguard can do what you want.
on my network, I have a wireguard peer.
my phone is a “client” peer connected to that peer.
I set AllowedIPs to 192.168.1.0/24, my network’s subnet.
This means that normal traffic goes through my phones standard internet connection, but 192.168.1.0 goes through the VPN tunnel, and I can access that network as if I was directly connected to it.
In order to communicate with each other inside tunnel, you may need to connect your windows to vpn too or setup vpn tunnel on your home router (if it supports).
If the Wireguard server is in the cloud then port forward is not needed. Check my second edit.
I suppose you could find a way to join the networks through the pi and make it act as some kind of router, I thought you could just ssh in the Pi and go from there, I don’t know enough about networking to make it as if the pi isn’t there and connect “directly” to the PLCs
The way I was thinking was that you would see the Pi as if it was a local device and you would use it as a hop to the final host but it appears it wouldn’t work… unless you could make your Pi appear as a PLC to your PC
I’d go with jumping to the remote device, and from there to the target. That way the target doesn’t need to know how it can reach your home net, it just sees the connection originating from the “device”
You can do some tricks with port forwarding through ssh, which let you connect from your PC to the target.
Routing traffic through the tunnel in both directions is more hassle with routing tables on both ends than it’s worth.
I’d go with jumping to the remote device, and from there to the target.
Unfortunately I cannot because I have some tools that are windows only and need a connection to their local network. I need to be able to ping from my PC to a device on client network,
Do you specifically need ping i.e. an ICMP Echo-request and -reply? Do you know which ports your windows-only tools use? As long as it’s TCP, you should be able to get away with forwarding all ports via ssh and connecting to the machine running the ssh client.
Can you share more about what kind of target you’re trying to connect to?
Off the top of my head primarily TCP/UDP 8442, ICMP, TCP 22/2222/2022, 80/8080/8443, 9000 if I’m lucky and everything is standard.