Got openvpn working, but cannot make it work for one VLAN only
-
@newsboost said in Got openvpn working, but cannot make it work for one VLAN only:
Virtual Address: 10.107.0.90,
From a laptop on VLAN 1 (my main laptop), I can ping all these ip addresses. But pfsense didn't seem to be able to do it, since I had to pick "Disable Gateway Monitoring"? Why?This is your virtual IP of the VPN client.
To check out the gateway IP (servers virtual IP) go to Status > Gateways.
Then simply pick it and try to ping.Furthermore I discovered that http://10.107.0.90/ brings me to the webUI of pfsense...?
That's expected, since it's an virtual IP of pfSense as mentioned above.
Oh, how stupid of me - thanks a lot for bringing my attention to this issue! I've now fixed the issue (it was because I tried to allow everything, when things didn't work). Furthermore, I've now managed to add another default gateway firewall rule that enables me to access my whole private LAN-internet for some allowed devices - even on VLAN 10 - while external traffic is still routed through via the VPN (attaching a screenshot of this config below).
Yes, the rule looks well. Maybe you want to limit the access to a few destination ports only, but should work.
The other settings are okay as well now. -
@viragomann said in Got openvpn working, but cannot make it work for one VLAN only:
@newsboost said in Got openvpn working, but cannot make it work for one VLAN only:
Virtual Address: 10.107.0.90,
From a laptop on VLAN 1 (my main laptop), I can ping all these ip addresses. But pfsense didn't seem to be able to do it, since I had to pick "Disable Gateway Monitoring"? Why?This is your virtual IP of the VPN client.
To check out the gateway IP (servers virtual IP) go to Status > Gateways.
Then simply pick it and try to ping.Oh, damn. Yes, it's correct. That one I cannot ping. I guess I would be wasting my time if I wrote an email to the VPN-provider (expressVPN) and asked them if they could allow me to ping the gateway IP... Well, then I guess I can only do as I did with enabling "Disable Gateway Monitoring", right? At least now I know exactly why I need to do it this way, when the default method doesn't work and that's really great to know.
Yes, the rule looks well. Maybe you want to limit the access to a few destination ports only, but should work.
The other settings are okay as well now.- Yes agree, maybe I should limit it to a few ports - but I'll fine-tune such things later - the all access makes it easy for me to conduct experiments and providing me an "emergency exit", in case I accidentally lock myself out of the webUI (which happens from time to time)
- I'm really happy - I also think (and feel) it's working really great now and I think I can finetune this concept to however I want it, in the future.
Thanks a lot for the help and very valuable feedback!
-
@newsboost said in Got openvpn working, but cannot make it work for one VLAN only:
Well, then I guess I can only do as I did with enabling "Disable Gateway Monitoring", right?
I told you above that you can configure an alternative monitoring IP if it is desired.
You can edit the VPN gateway settings in System > Routing > Gateways. Enable monitoring again, then you can enter a custom IP below. You have to use a public IP which responses to pings, e.g. 8.8.8.8. But best to use one that is near to the VPN endpoint.
pfSense then routes this IP automatically over the VPN.However, consider that if the ping fails and the gateway goes offline, the upstream traffic from VLAN10 will go out to WAN, as long as you haven't configured kill-switch rules or at least as long as System > Advanced > Miscellaneous > Skip rules when gateway is down (Do not create rules when gateway is down) is unchecked. Simply checking this option prevents that an offline gateway is replaced by the default one.
-
@viragomann said in Got openvpn working, but cannot make it work for one VLAN only:
I told you above that you can configure an alternative monitoring IP if it is desired.
Oh, yes you did - sorry. I think I forgot it, because I didn't understand the reason for that option. But that you also explained pretty well, thanks and sorry I forgot it, this option makes perfect sense together with this:
However, consider that if the ping fails and the gateway goes offline, the upstream traffic from VLAN10 will go out to WAN, as long as you haven't configured kill-switch rules or at least as long as System > Advanced > Miscellaneous > Skip rules when gateway is down (Do not create rules when gateway is down) is unchecked. Simply checking this option prevents that an offline gateway is replaced by the default one.
That's a fantastic answer. Completely crystal-clear and understandable, even for me
The only things left which I don't fully understand yet is - and this is by no means really important at the moment but:
-
My devices obtain the VLAN-10 IP-number as they did before so the DHCP-server assigns a local ip-address, so it does have some firewall "allow"-rule access - UDP port 67 and 68 - although it is not directly or clearly seen in the firewall rules. Correct me if I'm wrong, but as I understand it pfsense firewalls has a default block-rule to the bottom of the list, i.e. the "Default deny rule IPv4 (1000000103)" in the "System Logs / Firewall" -log). I wouldn't be so confused, it there weren't such an implicit allowing of traffic to/from UDP ports 67 and 68...
-
When I check for DNS leak I can see it uses the same DNS (=cloudflare) that I've setup for everything else, i.e. the firewall must again allow UDP port 53 via another implicit firewall "allow"-rule. Is there a way to see such implicit rules anywhere (I know I could maybe do something tcpdump-stuff but at the moment it's too cumbersome - and it would be more intuitive if the rule showed up, explicitly, along with the other VLAN-firewall rules)?
-
Also, when I check for DNS leak, the online tests says "yes, my/your DNS is being leaked". This is however not currently a big issue, because I use cloudflare-dns.com (1.1.1.1 and 1.0.0.1) in System -> General Setup (the Gateway for these two DNS servers in the third column is "none", I realize this is probably where I could setup a specific one for the openvpn-gateway... Furthermore I think I use SSL/TLS - I value privacy high. Additionally in Services -> DNS Resolver -> General Settings I have "Enable DNS resolver" and on "Network Interfaces" I have on "all Network Interfaces except for the OpenVPN gateway" and on "Outgoing Network Interfaces" I have the same, i.e. also on "all Outgoing Network Interfaces except for the OpenVPN gateway". I thought that if I went into OpenVPN -> Clients -> Edit -> check "Pull DNS"/"Add server provided DNS" - and then visited dnsleaktest.com, it would show the DNS from the VPN-provider - but it doesn't... But this part is something I maybe should consider another time and create a new post for, another day (I'm guessing there could be many reasons, but if not I'm all ears )...
In any way, I'm extremely pleased with my pfSense setup now (running 24/7/365 on a HP t730 thin client, using around 25 W so the electricity bill from the power company doesn't kills me)
-
-
@newsboost
Hi again,
left this tab open in the browser to answer later.My devices obtain the VLAN-10 IP-number as they did before so the DHCP-server assigns a local ip-address, so it does have some firewall "allow"-rule access - UDP port 67 and 68 - although it is not directly or clearly seen in the firewall rules. Correct me if I'm wrong, but as I understand it pfsense firewalls has a default block-rule to the bottom of the list, i.e. the "Default deny rule IPv4 (1000000103)" in the "System Logs / Firewall" -log). I wouldn't be so confused, it there weren't such an implicit allowing of traffic to/from UDP ports 67 and 68...
Your assumption is correct. At the time you enable the DHCP server or DHCP relay on an interface, pfSense add an invisible rule to allow packets on UDP port 67 to itself.
There should not really be a need to show the rule or to enable to edit it at all. If you disable DHCP server and relay the port gets closed. But if you enable either you also want to allow the access at the same time.Also true, that there is an invisible default deny rule at the end of the rule set.
i.e. the firewall must again allow UDP port 53 via another implicit firewall "allow"-rule.
No, port 53 isn't allowed implicitly. You have to add a rule by yourself to pass DNS packets.
Only the default allow any to any rule on LAN includes DNS, but this one is visible and you can edit it.Is there a way to see such implicit rules anywhere
pfSense provides a file that includes all filter rules, also these ones not shown in the GUI: /tmp/rules.debug.
(I know I could maybe do something tcpdump-stuff but at the moment it's too cumbersome - and it would be more intuitive if the rule showed up, explicitly, along with the other VLAN-firewall rules)?
I don't really miss it. But yes, might be weird for beginners.
Also, when I check for DNS leak, the online tests says "yes, my/your DNS is being leaked". This is however not currently a big issue, because I use cloudflare-dns.com (1.1.1.1 and 1.0.0.1) in System -> General Setup (the Gateway for these two DNS servers in the third column is "none", I realize this is probably where I could setup a specific one for the openvpn-gateway... Furthermore I think I use SSL/TLS - I value privacy high. Additionally in Services -> DNS Resolver -> General Settings I have "Enable DNS resolver" and on "Network Interfaces" I have on "all Network Interfaces except for the OpenVPN gateway" and on "Outgoing Network Interfaces" I have the same, i.e. also on "all Outgoing Network Interfaces except for the OpenVPN gateway". I thought that if I went into OpenVPN -> Clients -> Edit -> check "Pull DNS"/"Add server provided DNS"
This setting on the OpenVPN client configuration tab only affects pfSense itself, since this is the VPN client.
There are several ways to prevent DNS leaks. And there might be other guys here, who knows better how to do than me. I did never worry about leaking DNS.
Anyway to avoid leaks, you have direct the DNS requests from the concerned devices over the VPN. You can simply do this by providing public DNS servers to the devices via DHCP. The policy routing rule which you already have on VLAN10 will route the request to the VPN server.
Alternatively or also additionally you can redirect DNS requests to a public server by adding a NAT port forwarding rule to VLAN10. Set the source to any and the destination to any, port 53 TCP/UDP and redirect it to 1.1.1.1 or what ever server you prefer. This redirecting rule should catch all DNS packets and the policy routing should route it to the VPN server.The gateway in the general settings as well es the Resolver settings impacts all internal subnets and possibly also pfSense and that might not be what you desire.
-
@viragomann said in Got openvpn working, but cannot make it work for one VLAN only:
No, port 53 isn't allowed implicitly. You have to add a rule by yourself to pass DNS packets.
Only the default allow any to any rule on LAN includes DNS, but this one is visible and you can edit it.Oh, I see - port 67 and 68 are implicit/invisible rules but 53 isn't... That's really good to hear, it's all beginning to make more sense to me, thanks!
pfSense provides a file that includes all filter rules, also these ones not shown in the GUI: /tmp/rules.debug.
Very, very useful, thanks! I just scp'ed this file, will examine it in more details after work today to better understand what's going on, thanks!
Also, when I check for DNS leak, the online tests says "yes, my/your DNS is being leaked". This is however not currently a big issue, because I use cloudflare-dns.com (1.1.1.1 and 1.0.0.1) in System -> General Setup (the Gateway for these two DNS servers in the third column is "none", I realize this is probably where I could setup a specific one for the openvpn-gateway... Furthermore I think I use SSL/TLS - I value privacy high. Additionally in Services -> DNS Resolver -> General Settings I have "Enable DNS resolver" and on "Network Interfaces" I have on "all Network Interfaces except for the OpenVPN gateway" and on "Outgoing Network Interfaces" I have the same, i.e. also on "all Outgoing Network Interfaces except for the OpenVPN gateway". I thought that if I went into OpenVPN -> Clients -> Edit -> check "Pull DNS"/"Add server provided DNS"
This setting on the OpenVPN client configuration tab only affects pfSense itself, since this is the VPN client.
There are several ways to prevent DNS leaks. And there might be other guys here, who knows better how to do than me. I did never worry about leaking DNS.I can add that one of my IOT-/"smart home"-devices 1-2 days ago stopped working properly: A "netatmo" thermostat which what on this "IOT"-VLAN which used VPN. From the app on my android phone it said: "unable to connect to the dns". I then checked the firewall block list and also temporarily disabled the VPN and discovered that this IOT- device really really wanted to use the google DNS 8.8.8.8 - and also some other DNS-servers I didn't use. After disabling the VPN and allowing this device to connect to anything, after 1/2 hour or so it began working properly and that's where I could see it used google DNS (and others). Then I turned the VPN back on for VLAN 10, removed the "allow"-rule - and it stilll works. But I think after 1-2 weeks it'll begin complaining again, so I'll have to look into a solution for this another day. But I think I'll experiment with it myself and maybe ask a more specific question in a whole new thread towards that topic, but thanks!
Anyway to avoid leaks, you have direct the DNS requests from the concerned devices over the VPN. You can simply do this by providing public DNS servers to the devices via DHCP. The policy routing rule which you already have on VLAN10 will route the request to the VPN server.
Alternatively or also additionally you can redirect DNS requests to a public server by adding a NAT port forwarding rule to VLAN10. Set the source to any and the destination to any, port 53 TCP/UDP and redirect it to 1.1.1.1 or what ever server you prefer. This redirecting rule should catch all DNS packets and the policy routing should route it to the VPN server.Yeah, but in my case I don't like the google DNS (because I don't think it's very private and I use so many other google-apps: gmail, calendar, maps and don't want them to be able to link it to my search history too). So I prefer to limit DNS-access and I prefer cloudflare DNS - but that I can see contradicts to me also wanting my IOT-devices to work properly. I think I understand your advice and will think about it: Another solution which might end up doing is to only allow e.g. my "netatmo" thermostat to use whatever DNS it wants and then restrict devices that works normally to use the pfsense-cloudflare DNS, which luckily works for most devices...
The gateway in the general settings as well es the Resolver settings impacts all internal subnets and possibly also pfSense and that might not be what you desire.
You're right. I think I need something more fine-grained... I have to experiment with this and look more into it for some hours or days until I finally figure out how exactly I want it configured - I might need to ask for advice later, but think I should start a whole new thread only for that, when/if needed...
For now I'm just extremely happy with having this policybased routing / openvpn for only a single VLAN working - it's been rock solid for the past week (since I found out I had to "Disable Gateway Monitoring") - thanks a lot for your kind help, I truly appreciate it, thanks!
-
@newsboost
Seems you don't understand the meaning of redirecting DNS by a NAT port-forwarding rule.
This is the DNS redirecting on my home pfSense as an example:
'Internal' is an interface group including some internal interfaces.
This rule redirects any DNS packet (send to any destination server) to my LAN IP, so that any DNS request goes to pfSense itself regardless which destination IP it was addressed.
This means, if a device sends its DNS request to e.g. 8.8.8.8, because it has the server hard-coded in its OS, the request is redirected to pfSense, the firewall resolves the FQDN and sends responses back to the device using 8.8.8.8 as source address in the packet.
Ergo the device doesn't notice that pfSense was resolving the request, it thinks the respond came from Google DNS and is happy. And so I am.So in your case you can add a port-forwarding rule like mine, but use 1.1.1.1 as redirect target, if you prefer Cloudflare, or any other public DNS service.
As already mentioned, when doing this on VLAN10, the policy routing rule will take the DNS request packet and route it to the VPN provider.
So you're requesting Cloudflare though, but the request is coming from the VPN provider, hence there is no DNS leaking anymore. And additionally you can use any DNS you like. -
@viragomann said in Got openvpn working, but cannot make it work for one VLAN only:
@newsboost
Seems you don't understand the meaning of redirecting DNS by a NAT port-forwarding rule.I have read about it and have a superficial understanding of it - and I know/knew I soon wanted/want to try it - but after I read your reply, I got the impression it's dead-simple so I really have to do it soon, just as you did... I've now prep'ed my 2 new rules:
NB: Unfortunately they're disabled now - they're only waiting to be enabled, the next time this "Netatmo" thermostat starts complaining. OpenVPN had been working for around a week before it started complaining - so I'm guessing that stupid software has a timer and if it cannot contact google/whatever DNS it begins complaining and refusing to function But I'll get my revenge - I just want to really see the difference, when I turn on these rules
This is the DNS redirecting on my home pfSense as an example:
'Internal' is an interface group including some internal interfaces.
This rule redirects any DNS packet (send to any destination server) to my LAN IP, so that any DNS request goes to pfSense itself regardless which destination IP it was addressed.
This means, if a device sends its DNS request to e.g. 8.8.8.8, because it has the server hard-coded in its OS, the request is redirected to pfSense, the firewall resolves the FQDN and sends responses back to the device using 8.8.8.8 as source address in the packet.
Ergo the device doesn't notice that pfSense was resolving the request, it thinks the respond came from Google DNS and is happy. And so I am.It's a great solution and thanks a lot for pointing it out. I had an idea that it would work like you just described, I was just confused about all this DNS over HTTPS and whatnot I've been messing around with, I was afraid things would be too complicated - but those 2 new rules I've added are really simple, so I cannot wait to try them, when the app begins complaining...
So in your case you can add a port-forwarding rule like mine, but use 1.1.1.1 as redirect target, if you prefer Cloudflare, or any other public DNS service.
I actually just did like here: redirecting DNS and blocking DNS - so I'm using 127.0.0.1 because I think I'm running a local DNS-server because I tried to experiment with some DNS over HTTPS so my ISP cannot spy on me... Because pure/normal DNS is unencrypted, as far as I know... I think I successfully did this DNS over HTTPS also by using guide(s) from the docs.netgate.com webpage...
As already mentioned, when doing this on VLAN10, the policy routing rule will take the DNS request packet and route it to the VPN provider.
So you're requesting Cloudflare though, but the request is coming from the VPN provider, hence there is no DNS leaking anymore. And additionally you can use any DNS you like.The "dns-leak-test" webpages still says I don't have a DNS leak now, because they say my only DNS server is cloudflare. hmmm. I'm not fully aware of what I've done to my DNS-setup at the moment - or why this app is the only device that causes problems... Anyway - I'm happy to hear about the NAT-port forwarding trick - that should definately help, but I need some hours where I can play with this, in order to learn how to get things right (it's mostly in the weekends I have several undisturbed hours on my own, I use for digging deeper into things like this)... I feel I'm on the right track, though - thanks (and I hope you agree to the 2 rules in the screenshot above)!
-
@newsboost said in Got openvpn working, but cannot make it work for one VLAN only:
so I'm using 127.0.0.1 because I think I'm running a local DNS-server because I tried to experiment with some DNS over HTTPS so my ISP cannot spy on me...
But this results in DNS leaks.
Yes, I'd should added, that you cannot redirect DNS over HTTP or TLS, since the client need to check the server SSL certificate. You can only block it, DoH can be blocked using pfBlockerNG.
But if a client has hard-coded DoH, you're lost. -
@viragomann said in Got openvpn working, but cannot make it work for one VLAN only:
so I'm using 127.0.0.1 because I think I'm running a local DNS-server because I tried to experiment with some DNS over HTTPS so my ISP cannot spy on me...
But this results in DNS leaks.
Oh damn... But why then?
Under "Services -> DNS Resolver -> General Settings" I have "Enable DNS resolver", then I also have "Enable Forwarding Mode" which supposedly should forward DNS queries "to the upstream DNS servers defined under System > General Setup" where I have defined that I wish to use 1.1.1.1 and 1.0.0.1 (both cloudflare dns). I don't think I understand how this can lead to DNS leak?
Yes, I'd should added, that you cannot redirect DNS over HTTP or TLS, since the client need to check the server SSL certificate. You can only block it, DoH can be blocked using pfBlockerNG.
But if a client has hard-coded DoH, you're lost.Interesting:
- Well, I gotta try enabling those 2 rules some day, preferably when my app starts complaining so I can see a difference between having the 2 rules there and not having them there... But this I think I understand: If IOT-devices are requesting sending secure DNS-queries, I don't have their private key to sign the message - so pfSense cannot make that work, that I get...
- But something is still a bit confusing. Maybe it's just me, but the setting I already have: "Enable Forwarding Mode", doesn't it sound completely similar to the NAT / DNS Redirect rule?
- Furthermore: I'm beginning to suspect that this "Netatmo" app might have hardcoded google DNS server: 8.8.8.8 - but I remember I saw in the firewall log that I queried several different DNS servers... In any case: I'm not so worried about a single device, I can always make a single exception (hardcoded by it's IP address). But understanding everything in pfSense - or at least finetuning everything so I feel I have the "perfect setup", is a long journey, which I'm probably only in the beginning of
It's great stuff I learn here, I'm very grateful for the help, thanks again.
-
@newsboost said in Got openvpn working, but cannot make it work for one VLAN only:
Oh damn... But why then?
Under "Services -> DNS Resolver -> General Settings" I have "Enable DNS resolver", then I also have "Enable Forwarding Mode" which supposedly should forward DNS queries "to the upstream DNS servers defined under System > General Setup" where I have defined that I wish to use 1.1.1.1 and 1.0.0.1 (both cloudflare dns).That's all correct.
However, DNS leak means, that you're requesting an IP for an host name from WAN, while the access to this IP comes from the VPN provider.
That's exactly what happens here.Your internal devices request the DNS Resolver of pfSense and the requests are forwarded to Cloudflare, but these go out on WAN, because the (forwarded) requests are coming from pfSense itself and obey only the routing table.
However, when your VLAN10 devices can send requests to public DNS servers directly, the requests are routed according to the policy routing rule on the interface rule tab.
-
@viragomann said in Got openvpn working, but cannot make it work for one VLAN only:
@newsboost said in Got openvpn working, but cannot make it work for one VLAN only:
Oh damn... But why then?
Under "Services -> DNS Resolver -> General Settings" I have "Enable DNS resolver", then I also have "Enable Forwarding Mode" which supposedly should forward DNS queries "to the upstream DNS servers defined under System > General Setup" where I have defined that I wish to use 1.1.1.1 and 1.0.0.1 (both cloudflare dns).That's all correct.
However, DNS leak means, that you're requesting an IP for an host name from WAN, while the access to this IP comes from the VPN provider.
That's exactly what happens here.Oh, yeah, I understand it now... On the other hand, I don't "fully" see it as a "real DNS leak" because I think I'm using cloudflare with DNS-over-HTTPS - so my ISP will have a hard time decrypting that HTTPS-stuff But if I didn't use DNS-over-HTTPS I fully agree and get it now...
Your internal devices request the DNS Resolver of pfSense and the requests are forwarded to Cloudflare, but these go out on WAN, because the (forwarded) requests are coming from pfSense itself and obey only the routing table.
However, when your VLAN10 devices can send requests to public DNS servers directly, the requests are routed according to the policy routing rule on the interface rule tab.
I don't think they send requests to public DNS servers directly. I think they send requests to pfSense, which either replies back directly - or asks Cloudflare upstream with DNS-over-HTTPS - which is also what I think I wanted in general - except maybe it would be nice to make an exception such that VPN-traffic on VLAN 10 also uses the DNS-servers from the VPN-provider. Creating this exception rule seems not so easy, at least I haven't succeeded yet. Here are my rules for VLAN 10:
Notice the rule in the top of the list, where the "Destination"-alias is the following:
But my phone doesn't want to connect to the wireless (VLAN 10) network anylonger with that/this rule (it says something like "Connected without internet" and then it quickly disconnects and tries to connect to another SSID). Here is a few lines from the firewall log:
which make pretty good sense. So the devices do not understand they should instead pick the DNS-server from the VPN-gateway, right?So I must have a setting enabled that prevents the behaviour you described, leading to no internet instead of using alternative DNS-servers. I tried different things incl. Services -> DNS Resolver -> General Settings:
(tried both enabling and disabling, no difference)Enabling this didn't have any noticeable effect:
And then in System -> General Setup I tried both enabling and disabling:
(the "DNS Resolution Behaviour" sounds just like you described)Well - although I've tried different stuff, still "dnsleaktest.com" tells I'm only using cloudflare - which is both a good and a bad thing (good because it doesn't use my ISP's DNS - bad because it doesn't use the DNS from my VPN-provider)...
Well, at least this is only a minor issue. I still have many months (or years, I think) to play around with pfSense and learn to use it better. There are many settings, I think also one day I should reset my whole configuration and try to restore it from factory defaults - then I'll learn which settings are really needed, to make my current configuration work - and which are just settings I tried to push/change and later forgot everything about... If you have any idea about why it doesn't just pick the DNS-servers provided by the VPN-provider/VPN-gateway, I would be happy to hear about it, thanks!
-
@newsboost said in Got openvpn working, but cannot make it work for one VLAN only:
I don't think they send requests to public DNS servers directly. I think they send requests to pfSense, which either replies back directly - or asks Cloudflare upstream with DNS-over-HTTPS - which is also what I think I wanted in general - except maybe it would be nice to make an exception such that VPN-traffic on VLAN 10 also uses the DNS-servers from the VPN-provider. Creating this exception rule seems not so easy, at least I haven't succeeded yet. Here are my rules for VLAN 10:
Again, all you have to do for enabling this is adding a port-forwarding rule for DNS requests to a public server. Might be the VPN providers DNS or Cloudflare or whatever.
I tried to explain this several time above and posted my NAT rule as an example. So read again, please.
There is no exception needed and no further special rules. -
@viragomann said in Got openvpn working, but cannot make it work for one VLAN only:
@newsboost said in Got openvpn working, but cannot make it work for one VLAN only:
I don't think they send requests to public DNS servers directly. I think they send requests to pfSense, which either replies back directly - or asks Cloudflare upstream with DNS-over-HTTPS - which is also what I think I wanted in general - except maybe it would be nice to make an exception such that VPN-traffic on VLAN 10 also uses the DNS-servers from the VPN-provider. Creating this exception rule seems not so easy, at least I haven't succeeded yet. Here are my rules for VLAN 10:
Again, all you have to do for enabling this is adding a port-forwarding rule for DNS requests to a public server. Might be the VPN providers DNS or Cloudflare or whatever.
Okay I did as you described - but with one exception (and I also screwed this up the first time by letting "interface" be the OpenVPN-interface, instead it should just be VLAN-10). This is what I ended up with:
This will accomplish what I want: Use secure Cloudflare DNS, except when using VPN - then use DNS through the VPN tunnel. But something weird happened. First, what I hoped to achieve was that I shouldn't hardcode the DNS-server, for OpenVPN it should use the DNS servers provided by the VPN-provider, that's why I checked "Pull DNS" in the OpenVPN-client config, please see (the bottom checkbox):
I tried to explain this several time above and posted my NAT rule as an example. So read again, please.
There is no exception needed and no further special rules.Thank you, I read it again. As I understand it, you use plain unencrypted DNS and the same for all interfaces, meaning your ISP can spy on your DNS-requests.
The reason I've been slow at doing what you propose is because I wanted (want) an exception such that everything going through the VPN tunnel uses DNS from the VPN provider. Since the tunnel is encrypted, so will DNS-requests be, at least from the point of view of my ISP - on the VPN-side DNS will be unencrypted, but non-personal because many users will share the same VPN-server and unless you're a (or I am a) top wanted criminal, I'll have privacy and anonymity via VPN. So I wanted/want an exception: Cloudfare by default, but whatever DNS comes with the VPN on the other side of the tunnel. I think actually I've accomplished that using the NAT / Port forward I showed a screenshot of in the top of this reply/post. But I wasn't expecting what I see: As you see, I entered the Google DNS: 8.8.8.8 - so I expected that when I ran the online DNS-leak-tests, they would show Google. But that's not what happens.... With the setup above (NAT / Port forward in the top screenshot for interface VLAN10_UK_VPN) DNS leak tests show that my DNS servers are:
- 1 "UK Dedicated Servers Ltd" IP address + a few "Cogent Communications" IP addresses - (they're all London, UK)
I then ran a test: On my normal network (not via VPN) I ran the "ExpressVPN"-app and then ran the DNS leak tests. They revealed my DNS servers were:
- 1 "Heficed" IP address + a few "Clouvider Limited" IP addresses (also either London or geographically close to London)
I also wouldn't have liked to use Google DNS in the first place. I checked the firewall log for 8.8.8.8 (since it didn't show up in the DNS leak tests) - but that hasn't been blocked. I have a theory that instead it might've been redirected - or I'm just dumb and stupid. But then I thought about the great neat trick you learned me with /tmp/rules.debug - I downloaded it and filtered all lines with port 53 in it, it looks like this:
It's great that on VLAN 10, it now picks up other DNS-servers than cloudflare - so I guess I've accomplished what I want. I just don't understand why it's not using google (not that I dislike it, would just be nice to understand it ). But as I've mentioned earlier: I'm already extremely happy with my setup so I can live with not understanding it all. Thanks again for your patience, I know I'm a bit slow at learning/understanding sometimes, I'm grateful for having learned a lot already