Whilst I see what you're doing, and indeed I do similar things, you're trying to route RFC1918 addresses, so it's not hugely surprising odd things happen.
On 01/10/2020 14:56, Mark Rogers wrote:
On Thu, 1 Oct 2020 at 13:05, mick mbm@rlogin.net wrote:
That muddies things. Worse it can muddy routing if your customer happens to use the same internal RFC1918 addresses as do you in your office.
True, although whilst my example used 192.168.0.100 we don't actually use such a common subnet and the issue of collision has yet to occur. It would be far more likely to occur if I had reason to connect to two different customers at the same time, but that isn't something I have needed to do nor can I see it happening.
(To some degree this is all because of COVID: Sitting in the office with a connection to a customer VPN is perfectly normal, but if I am having to work from home to carry out my normal work then connecting to two VPNs becomes an issue. But if I were in the office and connected to my customer VPN, I wouldn't want to lose access to resources in the office, which would happen if my DNS queries stopped using my office DNS and instead used the VPN DNS. There are plenty of good reasons to send DNS queries over a VPN, as there is for all sorts of Internet traffic, but I personally far more frequently have a reason not to.)
Sure, you should not trust a third party not to snoop your DNS queries (I care so much about that that I now actually encrypt all my DNS queries using DNS over TLS)
Encrypted queries are fine but don't stop the DNS provider logging them. I want to choose my DNS provider and not have it dictated by any VPN connection I may be using.
And whilst it is your choice I admit, personally I would be /very/ bothered if anyone connecting to my protected network were using a desktop which was also used to browse "bigandbusty-dot-com" (or any other such sites). The potential for them to be malware ridden is obvious. Don't your customers care?
If they're using such domains and have access to my VPN, it's unlikely that the issue is DNS related and I should assume that these things happen and limit the impact as far as possible at my office network end; malware on a client PC is an ever-present risk and I don't think logging the fact that someone has visited bigandbusty-dot-com adds much to the party. Indeed the majority of malware I've had to deal with in the past comes from infected legitimate sites, but that probably says more about the people I work with than its prevalence on adult sites.
My point is that if I am accepting the idea of individuals accessing the office VPN with their own devices I cannot expect to be privy to the sites they access on their device. If you don't like the example I gave, I'm sure you can come up with other DNS query examples that someone might make which you don't think I have any right to know about - you wouldn't be worried about the secrecy of your own DNS queries otherwise, of-course.
Since I'm not logging DNS queries anyway it's somewhat moot, but certainly I do not think that my own DNS queries should routinely be accessible to the administrator of any third party VPN I have reason to connect to.
Whatever, you seem to have solved your original problem with openwrt, so the discussion is now somewhat moot.
Moot, certainly, but interesting nevertheless (at least to me).