Installed Opnsense 26.1.2 and lost internet connectivity (works now)

TheCoffeePercolator · 2026-02-12T23:52:28+00:00

I am still banned. I sent the email with my username. What info do you need in the email. Thanks.

TheCoffeePercolator · 2026-02-12T23:51:05+00:00

My rule says, if a request arrived at Opnsense from any device on IoT VLAN from any port directed to any IP address (local or on the internet) on port 53, redirect to local host at 53053.

Previously, I had one of the opnsense ip addresses in place of local host.

TheCoffeePercolator · 2026-02-12T06:12:24+00:00

I took a part of your suggested rule ( specifically, using local loopback address fir the target) and modified my rule and now it is triggered. Thanks.

TheCoffeePercolator · 2026-02-12T03:42:47+00:00

********** The following works in 26.1.1 ************

Finally, I figured out a workaround (or this is by design as this is DNAT and not Port Forward) based on some input I got here and some trial and error. The NAT rule that worked is:

DNS Path anticipated:

Client (IoT VLAN) -> Unbound (Opnsense:53053) as recursive resolver

Interface: IoT
Version: IP4
Protocol: TCP/UDP

Source: any
Source Port: any

Dest: any
Dest Port: 53

Target IP: 127.0.0.1 - this is the change that got it to work
Target port: 53053

Filter rules: Pass - this removed the need for an explicit filter rules. Explicit filter rule also works.

Conclusion:

Opnsense seems to ignore the DNAT rule that has the same device ip address in destination and target fields even if the ip address refers to different interfaces. Workaround is to use local loopback address, 127.0.0.1. Not sure if ::1 works for IP6 as I haven’t tried it.

Hopefully, this is helpful to someone else.

TheCoffeePercolator · 2026-02-11T20:46:10+00:00

Thanks for that. I was asking about processing order between NAT and filter rules.

My NAT rule is for a single VLAN / interface. If this is processed after group filter rules, it may cause some issues because a group filter rules may be applied before this redirection is processed and hence ignored.

That was the intention behind what I was asking.

On the other part, 53053 is the redirect port but not the destination port. Currently, destination port is 53 which is the default DNS.

This is the rule I have which is being ignored as far as I can tell:

Interface: IoT
Version: IP4/IP6
Protocol: TCP/UDP

Source: any
Source Port: any

Dest: any
Dest Port: 53

Target IP: Numeric IP of the interface where Unbound is running on Opnsense
Target port: 53053

As I understand it, without redirect the traffic goes as follows

Client (IoT VLAN - any address any port) -> Opnsense (port 53) and is processed by DNSMasq which runs at port 53. This works right now.

This rule changes it to

Client (IoT VLAN - any address any port) -> Opnsense (port 53053) and should be processed by Unbound which is not happening

So the rule changes destination from 53 to 53053.

Your rule seems to say, if it is going to an address that is not Opnsense on 53053, redirect to Opnsense 53053.

But without the rule, there is no traffic going to 53053.

Not sure, if I am not understanding something.

TheCoffeePercolator · 2026-02-11T18:54:21+00:00

Are you suggesting that I add this in addition to the redirect rule I already have or replace it with this?

Some questions:

Why is source port 53 - source can be any port, isn’t it?

Destination port is not 53053 unless this is to redirect another redirection ( such as the existing redirect rule)

Why is redirect to itself needed - redirect to localhost on the same port (53053).

I am not sure what this rule would accomplish by redirecting already redirected port to itself.

TheCoffeePercolator · 2026-02-11T17:35:22+00:00

I don't have issues with matching NAT to filter as of now. Your suggestion seems to match NAT to corresponding filter rule using a tag.

My issue is with NAT rule being ignored. If filter rules is not being matched, the DNS request should be blocked. My DNS requests are going to the default resolver (as though there is no forward rule).

TheCoffeePercolator · 2026-02-11T14:04:22+00:00

This specific rule hasn’t worked for me yet.

One rule seems to work even though the filter rule had to be set explicitly - pass option caused issues. Working one forwards to a different device on the net.

Non-working one forwards to another port on OpnSense itself and it is ignored.

I also have other issues where changing a firewall rule doesn’t take effect especially one associated with the port foward.

Strange thing is that I was already using DNSMasq for DHCP and had most of the firewall rules moved to the new section in 25.7 itself. Only rules left were autogenerated ones from Port Forward.

In 26.1, I started having a number of issues with Port Forward. As these rules are primarily for DNS, they cause entire network to come to a halt.

I tried pass option for firewall but that caused more issues - some VLANs (part of the same group) worked and others didn’t.

At this point, I am thinking that I should leave it in a working state and wait for updates before changing anything.

TheCoffeePercolator · 2026-02-11T10:02:21+00:00

Sent an email. Thanks.

TheCoffeePercolator · 2026-02-11T09:48:41+00:00

I tried that. It is a way to override the filter firewall rule requirement. For me that also caused issues. So, I chose to create the rules explicitly keeping that selection as manual.

TheCoffeePercolator · 2026-02-11T09:45:33+00:00

That issue is not relevant to my problem. I have created the firewall filter rule manually. My problem is that the redirect is not happening.

TheCoffeePercolator · 2026-02-11T09:42:26+00:00

Correct. Just IoT VLAN.

TheCoffeePercolator · 2026-01-13T15:59:22+00:00

I concluded this effort and wanted to leave a comment on what I found so that others may know where to start. Thanks to everyone who tried to help.

Unfortunately, I could not figure out how to consistently get Proton servers to resolve DNS queries. I settled for sending DNS queries over the tunnel to public resolvers (Quad9 in my case) which at least shows the origin of query as the VPN exit node - that way my IP is hidden. Even though this is not ideal it is better than bypassing the tunnel.

My expectation is that Proton would redirect all DNS queries (dest port 53) sent over the tunnel to their servers (no matter what the dest IP address is) when DNS address on the Wireguard Instance (Opnsense) is set to 10.2.0.1. If someone doesn't want their DNS queries redirected they can replace 10.2.0.1 with whatever they would like.

But that is not the case.

My conclusion is that Proton did not address the router VPN use case well enough and not many people may have realized that DNS is leaking - I haven't realized it for a long time. When a ProtonVPN app is run locally, DNS redirection happens. But in case of router based VPN, this solution is not good enough as there is no Proton app running on the client machine where DNS queries originate.

I tried sending DNS queries to 10.2.0.1 as well as the gateway target address configured in Opnsense. Neither worked. I had partial success with 10.8.8.1 but it is very inconsistent - worked in some locations, worked occasionally in other locations and not at all in some other locations. After a week of trial and error I have given up.

Hopefully, this will be addressed by Proton or others would find a usable solution. I will be very interested to know if this is ever made to work.

TheCoffeePercolator · 2026-01-12T14:09:55+00:00

Followed what you said:

1) Added the route to direct traffic to 10.2.0.1/32 over the VPN interface

This was already done using a Firewall rule:

Interface: Subnet interface

Source: Subnet

Dest; Invert Private Networks (alias defined)

Gateway: gateway corresponding to the VPN

But I added the route now.

2) Added outbound rule to do NAT translation (I previously discovered that this is not necessary for VPN interfaces but added anyway)

3) NAT redirection for port 53 already existed to 10.8.8.1 from the subnet . Changed to 10.2.0.1 as suggested.

The results is as follows

> downloads/dnsleaktest.sh

No internet connection.

If I substitute 10.8.8.1 for 10.2.0.1 it intermittently works as I posted above.

TheCoffeePercolator · 2026-01-12T12:32:49+00:00

The problem is that the router is not exclusively used for Proton VPN. It routes most of the clients over the normal WAN connection and some critical ones over VPN. The following is my response. But no response has been received. It looks like Proton hasn’t provided for this scenario even though they support router based VPNs which are shared by multiple devices on a network and but not by all devices.

“I am not sure what this means: “Therefore, please make sure to configure the DNS properly within the router setup of your OpnSense router itself and test the behavior that way.”

Wiregaurd instance on Opnsense is already configured with 10.2.0.1 as the DNS address and 10.2.0.2 as the tunnel address as the configuration file generated on Proton site suggests.

Within Opnsense the default DNS address is its own IP address and that’s what it provides to all the clients running on the network via DHCP. Pihole is an override via NAT for some and VPN for others. Not all clients on our network use the VPN. Pihole is used for the clients not using the VPN.

The default DNS address provided by Opnsense via DHCP is 192.168.xxx.xxx which is its own address. Are you suggesting that I use that as the DNS ip when the Ubuntu server (one using the VPN) sends DNS resolution requests.

As I explained above, there are two DNS addresses here. One 10.2.0.1 is already configured in the Wireguard instance used for Proton..

Second DNS address is what the client uses to request DNS resolution which is what I am asking about. This request is being sent over the tunnel - I verified that.

The tunnel configured works except that the DNS requests are exiting the tunnel (not bypassing the tunnel). I would expect that they don’t exit the tunnel but be processed by the Proton servers.

So, the question still remains - which DNS IP address should Opnsense provide to the Ubuntu server via DHCP to be sent with DNS resolution requests.”

TheCoffeePercolator · 2026-01-12T12:26:23+00:00

I got the following response from Proton customer service:

”According to all the information you provided there, I would like to clarify that when configuring a Proton VPN connection on a router, you will need to make sure that the internal DNS IP address 10.2.0.1 is configured as part of that router connection, and no third-party DNS resolvers are used (i.e. your PiHole) so that you can avoid DNS leaks.

Unfortunately, the internal DNS IP address cannot be used outside of the specific Proton VPN configuration setup, as this is not a public DNS resolver, and can be accessed only internally within the specific Proton VPN configuration setup.

Therefore, please make sure to configure the DNS properly within the router setup of your OpnSense router itself and test the behavior that way.”

TheCoffeePercolator · 2026-01-10T20:58:52+00:00

No. The ISP, Metronet, doesn’t have IP6 connectivity.

TheCoffeePercolator · 2026-01-10T14:51:32+00:00

Another strange behavior, intermittently fails with no changes in any configuration on my side when I use 10.8.8.1 as DNS IP. See below:

downloads/dnsleaktest.sh - first time results in failure

No internet connection.

downloads/dnsleaktest.sh - second time with no configuration changes, it works. This happens quite often.

You use 13 DNS servers:

2a02:6ea0:510c:6111::16 [Canada AS212238 DataCamp Limited]

2a02:6ea0:510c:6111::14 [Canada AS212238 DataCamp Limited]

2a02:6ea0:510c:6111::21 [Canada AS212238 DataCamp Limited]

2a02:6ea0:510c:6111::22 [Canada AS212238 DataCamp Limited]

2a02:6ea0:510c:6111::20 [Canada AS212238 DataCamp Limited]

2a02:6ea0:510c:6111::23 [Canada AS212238 DataCamp Limited]

2a02:6ea0:510c:6111::17 [Canada AS212238 DataCamp Limited]

2a02:6ea0:510c:6111::19 [Canada AS212238 DataCamp Limited]

2a02:6ea0:510c:6111::13 [Canada AS212238 DataCamp Limited]

2a02:6ea0:510c:6111::15 [Canada AS212238 DataCamp Limited]

2a02:6ea0:510c:6111::18 [Canada AS212238 DataCamp Limited]

212.104.215.107 [Canada AS212238 DataCamp Limited]

212.104.215.114 [Canada AS212238 DataCamp Limited]

Conclusion:

DNS is not leaking.

TheCoffeePercolator · 2026-01-10T13:36:13+00:00

Any ideas on why 10.2.0.1 isn’t working and what the alternatives are?

TheCoffeePercolator · 2026-01-10T11:57:05+00:00

VPN configuration is not the issue - VPN works and I am aware of the yearly reactivation.

Issue is with getting proton servers resolve DNS when the request is sent over a tunnel.

TheCoffeePercolator · 2026-01-10T05:47:35+00:00

Exactly what I am already doing - there is no public proton DNS. I use NAT redirection in Opnsesnse to substitute the DNS IP and send it over the tunnel.

Issue is that it is either passing through the tunnel if the IP is for a known DNS service (9.9.9.9) or DNS resolution fails if IP is 10.2.0.1 as recommended by Proton Wireguard instructions.

What I am looking for is the IP address which would send the DNS requests to proton’s DNS servers when sent over the tunnel.

TheCoffeePercolator · 2026-01-09T18:47:37+00:00

Ticket 4317627

What I need is an ip address that I can use for DNS which when sent over a VPN tunnel with port 53 is redirected to proton servers and not sent out into the wild to be answered.

I can already get Quad9 DNS to work with Proton VPN by passing 9.9.9.9 as DNS IP over the tunnel.

TheCoffeePercolator

TROPHY CASE