Basic question about LAN ip address recognition

[brec]

traffic into its ethernet port is routed over the VPN

I'd be pleased to be persuaded that I'm making this unnecessarily complicated! I'll experiment with the single-interface approach and see if/where I get into trouble.

How is SSH traffic handled? Both my WGbox and one of the client boxes are headless.

 

[eibgrad]

I'd be pleased to be persuaded that I'm making this unnecessarily complicated! I'll experiment with the single-interface approach and see if/where I get into trouble.

How is SSH traffic handled? Both my WGbox and one of the client boxes are headless.

I ssh to the desktop PC managing my OpenVPN client like another other device. It's running an ssh server which I access over the default private network. Whether it is or isn't headless is irrelevant.

 

[brec]

I ssh to the desktop PC managing my OpenVPN client like another other device. It's running an ssh server which I access over the default private network. Whether it is or isn't headless is irrelevant.

If all traffic into the VPN/router is tunneled out, what prevents SSH traffic into the VPN/router from being tunneled out and therefore not handled by its SSH server?

 

[eibgrad]

If all traffic into the VPN/router is tunneled out, what prevents SSH traffic into the VPN/router from being tunneled out and therefore not handled by its SSH server?

Only traffic intended for the internet is tunneled out over the VPN. Any local reference remains local. It's no different than how any router (including the primary router) handles traffic across its switch.

 

[brec]

Only traffic intended for the internet is tunneled out over the VPN. Any local reference remains local. It's no different than how any router (including the primary router) handles traffic across its switch.

Yes, but how is that intention implemented? How, e.g., does any router know that SSH traffic is local and not to be forwarded?

Edit: AFAIK I have to write the relevant routing rules myself -- WireGuard is leaner in that respect than OpenVPN.

 

[eibgrad]

Yes, but how is that intention implemented? How, e.g., does any router know that SSH traffic is local and not to be forwarded?

By examining its local routing table. If the incoming packet has a destination IP of the router itself (e.g., 192.168.1.1), then the router *knows* the packet is intended for some internal process, such as its SSH server, or GUI. But if it receives an incoming packet that is NOT a destination IP hosted by the router, then it assumes the client wants it routed through some other network interface (i.e., gateway), typically a WAN that leads to the internet. But the router could also be hosting a *virtual* network interface for internet access as well (e.g., OpenVPN or WireGuard). Routing policy rules can be configured to determine what should use the WAN vs VPN. But again, if the destination IP is hosted by the router, no routing takes place. It's like any other communications between devices on the same local IP network.

 

[eibgrad]

P.S. IOW, the router *knows* the difference between packets intended for itself vs. a request for routing based on the destination IP. OTOH, if you send a packet to a device for routing purposes that is NOT configured as a router, it just ignores it.

 

[brec]

P.S. IOW, the router *knows* the difference between packets intended for itself vs. a request for routing based on the destination IP. OTOH, if you send a packet to a device for routing purposes that is NOT configured as a router, it just ignores it.

Here's my attempt at emulating the router logic you've outlined and the failure report. I thought it too WireGuard-specific for this thread, but you're more than welcome to take a look at my SuperUser post.

 

[eibgrad]

Here's my attempt at emulating the router logic you've outlined and the failure report. I thought it too WireGuard-specific for this thread, but you're more than welcome to take a look at my SuperUser post.

All you've done w/ that post is describe your WG client configuration, which is beside the point.

I don't care if the Ubuntu device is hosting a WG client, OpenVPN client, or no VPN client at all. The point I'm trying to make is that the Ubuntu device should be configured like any other device on the primary local network, w/ a default gateway and DNS servers. Then you also configure the Ubuntu device as a *router* (i.e., enable IP forwarding). At that point, for any device you want routed via the Ubuntu device, you simply change its default gateway to point to the local IP of the Ubuntu device. If there is NO VPN active, those clients will be routed through the Ubuntu device and up to the WAN of the primary router (admittedly, not particularly useful, but I'm trying to make a point about what's happening w/ this configuration). However, if you *do* have an active VPN client on the Ubuntu device, those clients can instead be routed through the VPN.

It's just that simple. The Ubuntu device is being configured like any other router, including the primary router. There is no difference. There's no need for additional local IP networks w/ the Ubuntu device. Clients that need to be routed through the VPN client simply make the Ubuntu server their default gateway. Those that don't will continue to be routed directly through the primary router.

Perhaps you're getting confused by the fact the Ubuntu device manages access to its local IP network, the WAN, and VPN via one and only one ethernet port, specifically the LAN port for 192.168.50.x (the other two ethernet ports are useless, at least for these purposes).

 

[brec]

I'm trying to implement what you describe. IP forwarding is enabled. I have only one LAN subnet. The only means of "instead be routed through the VPN" is to bring the WireGuard virtual tunnel interface up. The only way to do that is by SSH to the VPN client box, or as a boot-time process. Even if it were brought up during boot, there would have to be a way to change its config file from time to time, or do Ubuntu updates, etc. If all traffic is tunneled, that includes SSH traffic. So there has to be a means of discriminating what should be tunneled. That is what my WG client configuration is, as yet unsuccessfully, trying to do, including, as is common, some firewall and routing commands that I include in it that WG executes on my behalf.

 

[eibgrad]

Once the WG client is established, you need to reconfigure the routing table on the Ubuntu device to make the WG network interface the default gateway. When using OpenVPN, you do that by including the following directive in the OpenVPN client config file.

redirect-gateway def1

I don't use WG, so I don't know if it has a similar directive/option, or whether perhaps you need to do this manually using route commands.

At that point, there should be NO ISSUE in accessing the SSH server of the Ubuntu device since the destination IP will be that of the device (e.g., 192.168.50.100). That IP is hosted locally on the Ubuntu device, so it's NOT going to be routed over the VPN! The VPN is only going to be used if the destination IP is *unknown*, since the VPN is now the default gateway.

IOW, if configured properly, you are NOT routing everything over the VPN. The VPN is only acting as a default gateway for those destination IPs unknown to the Ubuntu device.