= Can peer on LAN to VPS/cloud server tunnel all input from two other LAN systems? =
Can I do this?
Dedicated WG box on LAN tunnels to VPS/cloud WG server. This local WG box has multiple ethernet interfaces. Can it take untunneled input from two other LAN boxes and forward it through the WG tunnel to the VPS/cloud server? Plus, can one of these other LAN boxes SSH to the WG box with another ethernet connection?
Summary of wired interfaces of LAN WG box:
1: to LAN side of router, for WAN access and for SSH with a Mac;
2. the Mac via the router, for to-be-tunneled traffic;
3. the other LAN box, for to-be-tunneled traffic.
The Mac would output its to-be-tunneled traffic to interface 2, and SSH traffic on interface 1; both of those interfaces connect to the router. Interface 3 connects directly to the other LAN box. All LAN addresses are on the same subnet and are static addresses.
Issues I see so far: I think the WG box has to NAT the traffic its tunneling (in addition to the VPS serverit again); if so, any problem there? And how can the SSH traffic be isolated from the tunnel?
All LAN addresses are on the same subnet and are static addresses.
Having multiple LANs with the same subnet is a bad idea. Each LAN should use its own subnet. And the WG box shouldn't have multiple interfaces connected to the same subnet.
You shouldn't need to use NAT on the WG box, instead you should configure the LAN subnets in allowed-ips on the cloud WG server.
Edit: superceded by my next reply
OK, here's my thinking now that you've lit the multi-subnets lightbulb Right now there's only one subnet, 192.16816. There are many boxes/hosts/devices on it -- phones, thermostats, computers, home theater components, etc. -- in addition to the three mentioned in my OP (which I'll now refer to as 1_LAN_WG_box, 2_ Mac, and 3_other_LAN_box).
Let's say 2_Mac will become 172.16.0.6 and 3_other_LAN_box will be 172.17.0.7. The LAN WG box's ETH1 connector remains on 192.16816. Its ETH2 connector becomes 172.16.0.2 (2_Mac's subnet), and its ETH3 connector becomes 172.17.0.1 (gateway on 3_other_LAN_box's subnet). That removes the local-NAT issue.
I don't want the Mac on the VPN all the time but only occasionally as a web client. I was planning to turn on the proxy server browser feature, with the LAN WG box as the proxy, only when I want to use the VPN. I think I haven't mentioned yet that the LAN WG box is headless; I want to use the Mac to control and configure it via SSH. The same applies to 3_other_LAN_box.
The Mac, 172.16.0.6, will SSH to the LAN WG box at the latter's 192.16816 address. I'll give the main router a static route for that. The Mac browser, when I want it to use the VPN, will use the LAN WG box's ETH2 172.16.0.2 address as a browser proxy.
3_other_LAN_has only one RJ45 connector. It will use the LAN WG box as a gateway. If 3_other_LAN_box connects to a switch, then the Mac could SSH to the 3_other_LAN_box through a main router static route.
I guess this is my first network design! A remaining issue is isolating the LAN WG box SSH traffic from the tunnel. I have some thoughts on that, but if the answer to my overall question, "Can this work?" is yes, I'll leave that issue for another post. Also for another post will be the WG conf files content accommodating this LAN design -- unless it all works on my first attempt!
(I've tried to make this comment clear but I understand that it contains a lot of detail. I appreciate your help!)
There are some aspects of my previous reply of 13 hr. ago that I think likely not to work, so I'm starting over. You can ignore that reply if you like.
Big picture: I have a headless Ubuntu box ("WGbox") I want to use to connect two local devices, a Mac and a headless data server ("DS") to the local end of a WG tunnel to a WG server on a cloud VPS. DS will be tunneled 24/7, but the Mac only occasionally. Both the WGbox and DS, being headless, need SSH access from the Mac.
WGbox has four RJ45 connectors. Right now I have one LAN subnet, 192.168.1.0/24. Because of WG's virtual routing needs, I'll need at least one additional subnet in order to tunnel two devices (Mac and DS).
Considering the Mac first I want to occasionally tunnel browser web traffic via WGbox, and be able to SSH to WGbox when I'm not tunneling web traffic. Currently the WGBox's only wired interface in use is assigned 198.168.1.10 and I SSH to it from the Mac which is 198.168.1.200.
How about I add a subnet for the Mac, with gateway such as 172.16.0.1/24 and assign that to a second wired interface on the WGbox. When I want to tunnel the Mac, I change the Mac's IP/gateway to 172.16.0.1/172.16.0.1. Since the main router is on the 192.168 subnet, normally I'd have to put a bridge into its iptables to route to a 172.16.0.1. But since the Mac and the WGbox are connected to the same switch, I think I can avoid the bridge.
Do you think this works? If so I'll move on to tunneling and SSH access for the DS device. If not, please let me know any thoughts about how to fix.
"the WG box shouldn't have multiple interfaces connected to the same subnet." Why? I'm not arguing, just whining, as I think violating that rule would simplify my task and I'd like to know the reason behind it.
I might be misreading this (long day), but what prevents you from:
- using the WGbox as LAN gateway for all the devices that you want permanently routed through the tunnel (you would need to set this up on the respective devices and either give up or complicate your DHCP setup from the default LAN gateway)?
- setting up a proxy on the WGbox which you can turn on and off as you please, on the devices that you
*don't want* permanently routed?
No need (IMHO and on a quick read) to mess around with different subnets, multiple network connections etc. Unless I am missing something. Unrelated to this, I would warmly suggest you to separate the "IoT" devices (at least) into a different network.
An issue with having all the devices on the same subnet is the requirement for the WGbox to NAT the tunnel traffic. I suppose that is not necessarily fatal, but it seems wasteful in light of the cloud VPS end of the tunnel having to NAT also. It also complicates WGbox configuration. But it avoids complication from setting up the additional subnets and bonding them in my main router.
As for turning tunneling on/off at will for web browsing from my Mac, I had thought of setting up one of the WGbox interfaces as proxy in my web browser (is that what you mean?) In brief self-education by internet searching I find that for HTTPS the browser issues a CONNECT to the proxy server to establish a tunnel to the target web server. I'm not sure what the WGbox will do with the CONNECT. More generally I think there would be some firewall configuration required to avoid WGbox dropping or rejecting the Mac's web traffic before WireGuard. Or maybe AllowedIPs 0.0.0.0/0 for the Peer sections would auto-configure permissive access control.
Turns out there's only one device (so far), the headless data server, that I'd like tunneled for its core function. I say "core function" because, being headless, I need SSH access to it from a Mac. That, not DHCP (which I can handle easily), is what complicates setting WGbox to be its gateway. Also, during SSH sessions, it needs preferably un-tunneled WAN access for OS updates, etc.
== ÃÂÃÂber diese Community ==
Mitglieder
Online
Reddit
