ProtonVPN for VLAN

Installing and Using OpenWrt
1

Hi,

Looking for some guidance with setting up Proton VPN for use by only 1 VLAN
All other VLANs should continue to use the ISPs gateway (I already have several other VLANs set up and working)

Can this be done without PBR/mwan3? i.e. using routes/rules?

If I have interfaces ProtonVPN and ProtonLAN, how do I force clients of ProtonLAN (192.168.30.1/24) to use the ProtonVPN gateway while all other clients use the ISP gateway?
It would seem that just setting IPv4 gateway on ProtonLAN to 10.2.0.2, should be enough, but this doesn't work.

Thanks and Seasons Greetings :smiley:

config partials

/etc/config/network

config bridge-vlan
	option device 'br-lan'
	option vlan '5'
	list ports 'lan1:t'
	list ports 'lan2:t'

config interface ProtonVPN
	option proto 'wireguard'
	option private_key '0987654321mnbvcxzlkjhgdfdsapoiuytrewq'
	list addresses '10.2.0.2/32'
	list dns '10.2.0.1'
	option list_port '51815'

config wireguard_ProtonVPN
	option description 'Imported peer configuration'
	option public_key'qwertyuiopasdfghjklzxcvbnm1234567890'
	list allowed_ips '0.0.0.0/0'
	option endpoint_host '149.xx.xx.xxx'
	option endpoint_port '51820'
	option persistent_keepalive '25'

config interface 'ProtonLAN'
	option proto 'static'
	option device 'br-lan.5'
	option ipaddr '192.168.30.1'
	option netmask '255.255.255.0'
	list dns '10.2.0.1'
	option default route '0'

/etc/config/firewall

option rule 'Allow-Wireguard-51815'
	list proto 'udp'
	option src 'wan'
	option dest_port '51815'
	option target 'ACCEPT'

config zone
	option name 'protonvpn'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	list network 'ProtonVPN'

config zone
	option name 'protonlan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'ProtonLAN'

config forwarding
	option src 'protonlan'
	option dest 'protonvpn'
2 
#/etc/config/network
...
config rule
        option in 'ProtonLAN'
        option src '192.168.30.0/24'
        option lookup '100'

config route
        option target '0.0.0.0/0'
        option interface 'ProtonVPN'
        option table '100'

This rule is not needed.

Remove this from the ProtonLAN interface section.

3

Hi Pavel,

Thanks for the reply.

Do you mean list dns '10.2.0.1' or 'option default route '0' (or both)?
The DNS clause is as the Proton config specifies, to prevent DNS leaks. See the conf file downloaded from Proton below:

# Key for OpenWRT
# Bouncing = 6
# NetShield = 1
# Moderate NAT = off
# NAT-PMP (Port Forwarding) = off
# VPN Accelerator = on
PrivateKey = 1234567890qwertyuiopasdfghjklzxcvbnm
Address = 10.2.0.2/32
DNS = 10.2.0.1

[Peer]
# UK#211
PublicKey = mnbvcxzlkjhgfdsapoiuytrewq0987654321
AllowedIPs = 0.0.0.0/0
Endpoint = 149.xx.xx.xxx:51820

I just tried adding the rule and route using table 100 as you suggested and it's working, although dnsleaktest.com thinks I'm in the US now which I wasn't expecting, as the Proton config is for a UK VPN server.

4

Both.

Option default route '0' is used if the protocol of the interface is set to dhcp and you want to ignore the default gateway advertised by the DHCP server (which is not the case).

The DNS server should be set on the interface from which it is directly accessible (as you set it on the ProtonVPN interface). However, this does not mean that this DNS server will be used every time the ProtonVPN interface is used. It will just be added to the list of available upstream DNS servers and you can search the web how dnsmasq behaves in such cases.

Better make the ProtonLAN clients use 10.2.0.1 as DNS server directly using DHCP option 6 (which won't work for devices with hardcoded DNS settings).

Finally, I don't care about DNS leaks so I'm not an expert on the subject, but (if I'm not mistaken) I believe @egc could help.

5

Better use /24 so make it 10.2.0.2/24

You will have a dnsleak as you cannot have 10.2.0.1 as only dns server as that is only available after the tunnel is up. So you need to also specify a publicly available dns server on the wan.

You can run a script to set 10.2.0.1 as your only dns server, but in that case all your non vpn lan clients will have a dns leak as they are using the tunnel dns.

So you need split dns.
In your case option 6 for your protonlan is a good solution just as @pavelgl wrote :slight_smile:

See for some background:

6

The 10.2.0.2/32 is as provided by the Proton conf file I downloaded from Proton.
Presumably that's because it wants to force only that address?

I am not concerned about other (V)LAN clients, because they get their DNS from Pi-Holes which in turn are using root DNS. Those other LAN clients are already getting DNS from DHCP option 6. (I believe this means my ISP could still snoop my DNS requests as they're not encrypted, but I don't imagine most ISPs bother with this?)

My ProtonLAN VLAN (192.168.30.0/24) is configured to give 10.2.0.1 as DNS for clients on that VLAN using option 6, so anything connected to that VLAN is covered as intended. So I will remove the entries suggested by Pavel.

So what about that Proton conf file? Is it incorrect with 10.2.0.2/32

7

It is better to use /24 as then you will have a route to that subnet so you also have a route to the dns server in that subnet.
Not that it matters in your case as you are using option 6

1 Like
8

OK, thanks.

I'm trying to make my way through your Github page :slight_smile:

I think I need to invest some time in PBR at some point, especially as it's now fw4/nft compatible. I would like to make use of both PBR and adblock-fast.

9

No problem, I use PBR and Adblock but DNS needs attention.
If you use option 6 or other DNS redirect you are not using the routers dnsmasq and thus no adblock.

In that case you can either use a script to set the VPN DNS server as sole DNS server, but that could give DNS problems to clients which are using the WAN.

Or use an IP blocking package for IP blocking e.g. BanIP

10

In your opinion, could you rate these DNS options in order of preference?

pi-hole (configured to ask upstream root DNS)
adblock-fast (using upstream root or DoH?)
Proton DNS
DoH

I have a lot of options right now and I can't decide :smiley:
I am paying for Proton, so there's that.

11

These are all different an non comparable things.

Regarding adblocking with DNS you can do it locally on the router with different packages: https://openwrt.org/docs/guide-user/services/ad-blocking

These packages are more or less an add on for DNSMasq to stop resolving a large number of domains with adds.

Instead of adblocking on the router you can use upstream DNS servers which do the adblocking for you , I do not know if Proton has DNS servers which do adblocking but if so that could be a good alternative.
One of the more popular are AdGuard, NextDNs, Cloudfare, Quad 9 etc.

DNSMasq itself does not make use of secure/encrypted DNS, for that I use HTTPS-DNS proxy: https://openwrt.org/packages/pkgdata/https-dns-proxy
this is an upstream resolver for DNSMasq, but there are other options available (SmartDNS, stubby, unbound etc.)

The PiHole replaces DNSMasq as DNS server and needs basically the same kind of setup (e.g. DNSmasq, adblocking secure DNS etc)

1 Like
12

Sorry, I should be clearer.
I wish to prevent anyone in the UK from seeing my DNS queries full stop (other than maybe Proton).

I currently have pi-holes set up to do DNS (and ad blocking) from my DHCP clients. The pi-hole is configured recursive as per the following guide:
https://docs.pi-hole.net/guides/dns/unbound/
This means the pi-holes use root DNS servers to resolve external addresses, correct? However, these aren't encrypted, but at least take the ISP, Google, Quad9 etc. out of the equation.

I recently decided I would like to use the Proton VPN, which comes with its own DNS. Proton offer No filter, Block malware only or Block malware, ads and trackers, when it comes to configuring the VPN. As far as I can tell, it's the private key that determines which. This solution is obviously encrypted, as it is through Proton's tunnel.

If I configure DoH to say Quad9 or Cloudflare etc., then they have the ability to see my DNS resolutions. Maybe that's not an issue.

I realise my adding adblock-fast didn't make much sense, as it doesn't deal with DNS directly :slight_smile:

Maybe configuring the pi-holes to use the Proton DNS for upstream resolution is the answer. That way, DNS requests are encrypted and the pi-holes cache the results and perform ad-blocking.
If I wanted the same using only OpenWrt, I could use adblock-fast on the router and send all DNS requests upstream via the Proton tunnel.

I read yesterday, that Chrome, Firefox etc. are hard-coded to use DOH (perhaps not in the UK, yet, anyway), so presumably that circumvents my efforts at the router? Is this what hijacking proposes to solve?
If I understand correctly, I block 53 and 5353 from reaching the internet and use a local resolver on these ports?

13

Correct, if you are using unbound then the DNS query is encrypted, but the root server will always see it as it decrypts the traffic to resolve it.
So whether you use Proton or another DNS server they will now what you are looking for

So as said you can use the pi-hole as you are now doing and either do the add-blocking locally on the pihole or use an add blocking DNS server e.g. from your Proton subscription.

If you use a pihole you probably are sending the pihole as DNS server to your clients and/or you can use a redirect rule to route all 53, 853 (for DoH which actually is more or less a blocking rule) and 5353 port queries to the pihole

That could be on by default but is configurable on the browser itself.
To make sure you redirect port 853 see above and add a canary domain to your DNS resolver (the pihole or DNSMasq): address=/use-application-dns.net/mask.icloud.com/mask-h2.icloud.com/
the first is the mozillla canary domain, the others for apple icloud

14

Thanks for the clarification :+1:t2:

Can you explain the canary domain a little more, please?
I take it those are the DoH resolvers for Firefox and Safari, respectively?
What does the address directive do?

15

You add a special domain to your DNS resolver (e.g. DNSmasq or you pihole ) which resolves to NXDOMAIN (= nothing).

The browser e.g. firefox of Safari will check if this domain resolves to NXDOMAIN and then will not use DoT (port 853).
So Firefox when started will search for the domain use-application-dns.net and if that resolves to NXDOMAIN then it will not use DoH.

16

Ah, great, thanks!

I just read the page for banip, that looks very useful and has DoH blocklist.
Does banip use the firewall, rather than DNS?

17

Indeed it blocks by IP address so DNS is not involved and is the only way to effectively block DoH (port 443).

Of course there are always ways to get around it e.g. using a VPN on the Client.
There is no way to stop a tech savy person which has full control over their PC visiting anything they want by using a VPN/Proxy.

18

For sure, and as it should be.
All my efforts are to make basic security simple for other users :slight_smile:

So if banip uses the firewall, that's great, I can have OpenWrt doing that and DNS elsewhere.
Or perhaps it's time I invested in a more capable device for OpenWrt so I can run more services. But on the other hand, maybe it's best to keep the doorway as simple as possible and run the other services behind?

I am interested in the proposed device from https://www.youtube.com/@tomazzaman

We're building a high-end router. Here's the update for October 2024

he also mentions OpenWrt, so hopefully it will be supported.

19

If you want a capable device to do it all then an x86 mini PC is the way to go.

I actually run Adblocking and HTTPS-DNS proxy on my R7800 which runs fine with my 600 Mb/s ISP connection.

I am looking into replacing it next year, I already have a Dynalink-WRX36 which is more powerful and can do 1 Gb/s, but I might buy a GL.iNet Flint2 (GL-MT6000)

20

I have an EliteDesk 800 G4 running in the background that I'm building around Debian. That draws 20W at idle, so I think I'll probably end up using that for most services and keep the router minimal.
Maybe when we get FTTP here, I'll pass-through a NIC to OpenWrt in an Incus VM so I have one less device to power, but that has it's own drawbacks.

I'm waiting for Trixie, because it has support for Incus 6.3 which in turn has support for OCI (Docker) containers. So many services are built for Docker which I don't really like, whereas I do like Incus. Having OCI support means I can run the odd Docker container if there's no real alternative without all the rest of the Docker cruft. I tried to use Docker in OpenWrt, but it wasn't pleasant. Maybe that's because of my hardware, but even the configuration wasn't friendly.

Anyway, a bit off-topic :smiley:

Thanks for your advice. I will refer to your Github page for sure.

Happy Holidays!

1 Like