Posted: Mon Nov 29, 2021 16:54 Post subject: Conflicting VPN setting [Win10] [R7000]
I am trying to merge 2 networks, so we get access to each other's files.
To that end I went with the simplest and most direct route - I enabled the PPTP VPN server on my R7000. All computers running windows 10.
The VPN clients have no trouble accessing my computer on the host network.
However there is a network setting on the clients that seems to lead to a functional conflict.
In the VPN connection properties -> Networking -> IPv4 properties -> Advanced there is a setting called Use default gateway on remote network
OFF = Prevents guest internet traffic from tunneling through the VPN (VPN performance is fairly low). Prevents host network from accessing guest machine over the network (cannot map drives).
ON = Tunnels guest internet traffic through VPN. Allows host network to access guest machine.
The problem is, I want both for guest internet traffic to not tunnel through the VPN (due to the low performance) and for the host network to be able to access the guest machine (the reason for doing this in the first place).
Is this possible?
(Some theory as to what's going on, so I learn some networking magic also appreciated.)
I assume your PPTP clients are running on Windows. IOW, this is NOT a case of a PPTP client on some remote dd-wrt router connected to your locally hosted PPTP server on dd-wrt.
If you examine the PPTP client on dd-wrt, you'll notice there are two fields to identify the Remote Subnet and Remote Subnet Mask (i.e., the IP network on which the PPTP server is running). Your PPTP clients need to have the same ability to identify the remote network if you choose NOT to use the PPTP server as a default gateway. I haven't used PPTP in years, even on dd-wrt, let alone Windows. So I don't recall if and where you can establish that information on the PPTP client config. But in the worst case, you could add the routing information directly from a command prompt once the PPTP client was established.
Here are the client routing tables with or without the default gateway being remote:
(I removed a bunch of 224.0.0.0 and above routes to make it smaller. And the 255.255.255.255 route with my public IP.)
(code blocks on this forum are not monospace font so I guess it's misaligned)
It makes no difference for the client machine routing, however a machine on the host network cannot access the client in the second instance (when the default gateway is not set to remote).
I suppose I will start looking into openVPN as well.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Thu Dec 02, 2021 8:36 Post subject:
@martixy
First I must apologize for this offtopic intrusion.
re >(code blocks on this forum are not monospace font so I guess it's misaligned)
Easy fix, first I have this working on my forums theme (on my signature) version 1.1.9
However I can also submit a patch for the forums that does this by default easy fix really.
Attaching shameless screenshot of theme for your snippet =)
As a networking noob I've had to learn as I go. I've gotten familiar the routing table and how to read netmasks. But it's not like I'm following a structured networking course, so I still don't know:
1. How metric is calculated. I know it's the "distance" - a lower metric means this route is preferred. And I also know its a combination of ...something - interface metric and ???
2. How routing actually works hop by hop.
3. What happens with the VPN - like do packets hop from the physical interface to the virtual?
But I am learning.
Even if I'm not a network engineer, I am a programmer, and I had one good and one bad system config, so you diff, and start figuring out which part of the diff makes or breaks your system.
Today I stared at the routing tables for a long, long time. After some experiments, and some failures, I finally figured out a solution.
I don't know why it's a solution, but it is:
Code:
route add 0.0.0.0 mask 0.0.0.0 0.0.0.0 if 44
(as in client->host(client PC to PC on host network) works without it, but host->client does not - it seems to catch some packets that arrive at the client but are dropped without it - I don't know which packets tho - packet-capturing a working host->client connection did not reveal any src/dst address apart from the two machines. if 44 is the VPN interface btw.)
I did come up with a funny way of working remotely without losing access if I mess up - a deadman switch.
