Messages

Hi Bob,

I will try it here . I was afraid the tunnel ip was somehow tied to a nat on proton side .
Doesn't hurt to try .

Many thanks

I won't be able to have two connections with proton, once their tunnels always have the same address

Just change the first 2 with a different number (e.g. 10.3.0.2).

Thanks for your response .
If the tunnels needs to have different ip addressing , I won't be able to have two connections with proton, once their tunnels always have the same address, except by the public ip of endpoint that changes according to the location .

Pretty sad . I will try with proton and another vpn provider .

Thanks

The Gateway failover is dependent on the state of the Gateway.
Thus this means you need to have 2 GWs, one per tunnel and those need to be unique and per GW needs to be router per Tunnel.

TO achieve that, create a GW, bind it to the specific Tunnel Interface, and do not disable the host routes. This will basically enforce the specific GW only to route and to be accessible via the specific tunnel. This means when the Specific Tunnel will go down so will go down as well the GW cause a static route points over it and the GW monitoring & failover will trigger properly.

Regards,
S.

Hi Bob ,

All the proton configs have the same tunnel address , the only thing that changes beyond the keys, are the endpoints.

Proton tunnels reuse the same local tunnel IP (10.2.0.2), which may contribute to routing/state ambiguity

What do you mean by that.
And my observations are, that those tunnels stay up almost all the time, only ICMP gets dropped from time to time, nothing else.

Hello everyone,

I am trying to implement automatic failover between two ProtonVPN WireGuard tunnels on OPNsense, but I am hitting what seems to be unreliable behavior with WireGuard gateway groups and dpinger.

Environment:
- Latest OPNsense version
- Two ProtonVPN WireGuard tunnels
- VLAN100 traffic policy-routed through a gateway group
- Primary tunnel: CHPROTON-BKP (wg3)
- Backup tunnel: CHPROTON
- Gateway group configured with Tier1/Tier2 failover
- Both WireGuard tunnels are operational and working correctly individually

Observed behavior:
- Traffic works correctly through the primary WG tunnel
- If I manually disable the primary gateway/interface, failover works and traffic correctly moves to the backup tunnel
- However, if the primary Proton peer becomes unusable or disconnected, the WireGuard interface often still remains "UP"
- dpinger/gateway monitoring still considers the gateway healthy
- Gateway group does not fail over correctly
- Traffic blackholes until I manually disable the dead gateway/interface

Additional observations:
- Proton tunnels reuse the same local tunnel IP (10.2.0.2), which may contribute to routing/state ambiguity
- OPNsense locally-generated traffic (ping/curl from firewall itself) does not seem to follow policy-routing/gateway-group rules, making reliable local health probing difficult
- Handshake age and RX/TX counters are not reliable enough because WireGuard keepalives continue even when real Internet traffic is broken
- Packet captures confirm that route-to rules are applied and packets leave through the expected WG interface, but sessions still fail when the gateway/group logic gets stuck

What I already tested:
- Different monitor IPs
- Gateway groups with trigger levels
- State resets
- Manual route testing
- tcpdump validation on WG interfaces
- Monitoring handshake age
- curl/ping probes
- Rebooting OPNsense
- Manually disabling/enabling gateways/interfaces

At this point I am considering:
1. Keeping only one active Proton tunnel and one cold standby
2. Creating a custom watchdog script using Monit
3. Using WAN failover underneath a single WireGuard tunnel instead of multiple WG tunnels in a gateway group

My questions:
- Has anyone successfully implemented reliable automatic failover between multiple ProtonVPN WireGuard tunnels on OPNsense?
- If yes, how are you detecting tunnel failure reliably?
- Are you using gateway groups, Monit scripts, dpinger, or another method?
- Did anyone find a clean workaround for locally-generated traffic not following policy-routing rules?
- Is this considered a known limitation/bug with WireGuard + gateway groups on OPNsense?

Any feedback or working architectures would be greatly appreciated.

Thanks!

Hi everyone,

I am trying to improve hostname visibility in OPNsense/Zenarmor and I am facing an issue with reverse PTR resolution for dynamic DHCP leases.

Current setup:

* OPNsense latest version
* Unbound enabled as main DNS resolver
* Dnsmasq DNS & DHCP enabled only for DHCP handling
* dnsmasq listening on port 53053
* Local domain: lab
* Zenarmor installed

What works:

* Forward lookup works correctly

Example:

```bash
drill lab003.lab @127.0.0.1
```

Returns:

```text
lab003.lab. IN A 192.168.100.204
```

What does NOT work:

* Reverse PTR lookup

Example:

```bash
drill -x 192.168.100.204 @127.0.0.1
```

Returns:

```text
NXDOMAIN
```

I also verified:

```bash
cat /var/db/dnsmasq.leases
```

and the lease hostname is correctly present.

Additional observations:

* dnsmasq logs show:

```text
read /var/etc/dnsmasq-leases - 0 names
```

* Enabling "Prefer DHCP" did not resolve the PTR issue.
* Enabling "Register ISC DHCP4 leases" also did not help.
* Zenarmor mostly displays IP addresses instead of hostnames due to missing reverse PTRs.

Questions:

1. Is this expected behavior with Unbound + dnsmasq DHCP integration?
2. Are dynamic PTR records supposed to be generated automatically in this architecture?
3. Is there a recommended approach to get automatic reverse PTR resolution without creating static mappings for every device?
4. Would using KEA DHCP improve this situation?
5. Is there a known limitation/bug regarding dynamic PTR generation in OPNsense?

Goal:

* Preserve dynamic DHCP
* Avoid static mappings for every device
* Improve hostname visibility in Zenarmor/logging/reporting

Thanks!

# My OPNsense + Proton VPN + Oracle Cloud Recursive DNS Journey (WireGuard + VLANs + DNS Hijacking)

Hi everyone,

I wanted to share a project I've been working on over the last few days with OPNsense. I still consider myself a beginner/newbie with OPNsense specifically, but I honestly had a lot of fun building and troubleshooting this environment over roughly 3 days.

The amount of flexibility OPNsense provides is honestly impressive.

My goal was to build a segmented home/lab network with:

* VLAN isolation
* forced DNS
* recursive DNS with filtering
* private DNS transport over WireGuard
* selective VPN routing
* RFC1918 local bypass
* cloud-hosted DNS
* clean routing logic

I also wanted to understand *why* things worked, not just copy/paste configs.

I'm posting this because I learned a lot during the process and maybe it helps someone else trying to build a similar architecture.

All sensitive information below is sanitized:

* no real public IPs
* no private keys
* no preshared keys
* no exact cloud identifiers

---

# Physical Infrastructure

Current hardware/network:

* OPNsense firewall/router
* 2x Layer-3 switches
* SFP56 fiber interconnects between switches
* dual fiber uplinks between switches
* multiple VLANs
* Oracle Cloud VM
* Proton VPN WireGuard tunnels

I will also add:

* a third access switch

because the current switches are 24-port models and I'm starting to run out of ports.

The switches are connected through:

* SFP56 fiber
* 2 physical links between them

The idea is eventually to continue expanding VLAN segmentation and lab environments.

---

# High-Level Goal

The final design became:



Clients
→ OPNsense
→ DNS hijacking / local forwarding
→ WireGuard tunnel
→ Oracle Cloud recursive DNS
```

while one VLAN uses Proton VPN for Internet egress:

```text id="xv7fzo"
VLAN100
→ Proton VPN
→ Internet
```

and all internal RFC1918 traffic stays local.

---

# Sanitized Topology Diagram



The diagram includes:

* VLAN layout
* WireGuard topology
* Proton VPN tunnels
* Oracle Cloud recursive DNS
* DNS flow
* PBR logic
* security controls
* validation tests

All IPs are sanitized intentionally.

---

# VLAN Layout

Current VLANs:

```text id="6b6rk4"
VLAN50  Users
VLAN60  IoT
VLAN70  General
VLAN80  Lab
VLAN90  Management
VLAN100  PowerUser
VLAN240  Infra
```

Each VLAN has:

* its own gateway
* firewall rules
* DNS handling
* routing policy

---

# DNS Architecture

Initially I was forwarding DNS from OPNsense to Oracle Cloud using the Oracle public IP.

That worked, but I quickly realized:

* source IP changes become annoying
* VPN exits complicate ACLs
* public DNS exposure is unnecessary

So I built a dedicated WireGuard tunnel between:

* OPNsense
* Oracle Cloud

Now DNS travels privately:

```text id="sv3m8j"
OPNsense
→ wg2
→ Oracle wg0
→ Unbound recursive DNS
```

This was validated using:

```bash id="6np8n5"
tcpdump -ni wg2 port 53
```

I could clearly see:

```text id="j6v1p8"
OPNsense-WG-IP → Oracle-WG-IP:53
```

which confirmed DNS was traversing the private tunnel.

---

# Important Discovery #1

## OPNsense Uses Round-Robin DNS Behavior

One thing I discovered:

If multiple DNS servers are configured under:

```text id="vppfjt"
System → Settings → General
```

OPNsense appears to use them in a round-robin-like manner.

That caused confusion during testing because:

* some queries used Oracle
* others used another resolver

For clean validation and predictable behavior:

* I ended up using only the Oracle WireGuard DNS server.

This made troubleshooting MUCH easier.

---

# Important Discovery #2

## WireGuard Instances Must Use Different Ports

Another thing that confused me initially:

Different WireGuard instances on OPNsense should use different listen ports.

Example:

```text id="o1pl5j"
wg0 → 51820
wg1 → 51830
wg2 → 51840
```

When multiple instances were using overlapping/default ports, behavior became inconsistent.

After assigning unique ports:

* everything stabilized immediately.

---

# Important Discovery #3

## WireGuard Key Logic

This was another major learning point for me.

The rule is simple:

```text id="9blz0y"
Your device keeps its own private key.
The peer gets your public key.
```

So on OPNsense:

```text id="0twd1z"
Instance:
- OPNsense private key

Peer:
- Oracle public key
```

On Oracle:

```text id="4ujpx3"
Interface:
- Oracle private key

Peer:
- OPNsense public key
```

The preshared key:

* must match on both sides
* but does NOT replace public/private key authentication.

At first I was confusing:

* public keys
* private keys
* preshared keys

especially because Proton VPN client configs look different from traditional WireGuard server configs.

---

# Important Discovery #4

## Cloud Firewalls + OS Firewalls Both Matter

This was another very important lesson.

When working with cloud VMs, you often have:

* cloud-level security rules
* operating system firewall rules

Both must allow the traffic.

In my case:

* Oracle Cloud security lists / NSGs had to allow:

  * WireGuard UDP port
  * DNS traffic
* Ubuntu itself also needed firewall rules

Even after Oracle Cloud allowed the traffic, DNS still failed until I allowed it locally on Ubuntu.

Example:

```bash id="0w7b1s"
sudo iptables -I INPUT 1 -i wg0 -p udp --dport 53 -j ACCEPT
sudo iptables -I INPUT 1 -i wg0 -p tcp --dport 53 -j ACCEPT
```

So the troubleshooting sequence became:

```text id="1rj4z9"
Cloud security rules
→ Linux firewall
→ Service binding/listening
→ routing
```

This was probably one of the biggest troubleshooting lessons from the whole project.

---

# Proton VPN Setup

I configured:

* Proton UAE
* Proton Switzerland

using WireGuard.

Important detail:

* I did NOT route the whole firewall through Proton.

Instead:

* only VLAN100 uses Proton through Policy-Based Routing.

This keeps:

* management stable
* OPNsense updates clean
* troubleshooting easier

while still allowing selected clients to use VPN egress.

---

# PBR (Policy-Based Routing)

The key logic:

```text id="z3b6q8"
Default VLANs
→ WAN

VLAN100
→ Proton VPN
```

For VLAN100 I added:

1. RFC1918 bypass rule
2. Proton gateway rule

in that order.

That means:

```text id="yp9u4r"
Internal traffic
→ local routing

Internet traffic
→ Proton VPN
```

This solved:

* local access issues
* inter-VLAN communication
* NAS/server access problems

while still tunneling Internet traffic.

---

# DNS Hijacking

All VLANs now use DNS hijacking rules.

If a client tries:

```text id="iq6jrf"
8.8.8.8
1.1.1.1
9.9.9.9
```

the request gets redirected back to OPNsense.

Then:

```text id="x0s2d2"
OPNsense
→ Oracle over WireGuard
```

This ensures:

* filtering
* DNSSEC
* logging consistency
* centralized control

---

# Oracle Cloud DNS Server

Oracle Cloud VM runs:

* Ubuntu
* WireGuard
* Unbound recursive DNS
* DNSSEC
* HaGeZi blocklists
* TIF threat feeds

Unbound receives DNS from OPNsense through WireGuard only.

I also modified iptables to:

* allow DNS from wg0
* allow WireGuard UDP
* restrict unnecessary exposure

---

# Validation Tests I Used

## Verify WG Route

```bash id="wsc9d3"
route -n get <oracle-wg-ip>
```

Expected:

```text id="20y5zy"
interface: wg2
```

---

## Verify DNS Through WG

```bash id="3h5m9r"
tcpdump -ni wg2 port 53
```

Then:

```bash id="otm32j"
dig google.com
```

Expected:

```text id="vw2m7i"
WG-IP → WG-IP:53
```

---

## Verify Proton Exit

From VLAN100:

```bash id="quvb8f"
curl ifconfig.me
```

Expected:

* Proton public IP

---

## Verify OPNsense Still Uses WAN

From OPNsense shell:

```bash id="wq1pp9"
curl ifconfig.me
```

Expected:

* ISP WAN IP

This was intentional.

I did NOT want the firewall itself depending on the VPN.

---

# Current Status

Everything is now operational:

* Proton VPN working
* Oracle WireGuard tunnel working
* DNS over WireGuard validated
* VLAN100 PBR validated
* DNS hijacking validated
* DNSSEC validated
* recursive DNS validated
* RFC1918 bypass working
* internal access preserved

---

# Next Improvements

Some of the next things I plan to implement:

* EAP-TLS certificate-based Wi-Fi authentication
* additional VLAN segmentation
* third access switch deployment
* improved monitoring
* maybe HA/failover later
* physical topology documentation
* additional DNS hardening
* more management isolation

I'm especially interested in moving toward:

* WPA-Enterprise
* EAP-TLS
* certificate-based authentication

instead of relying only on traditional PSKs.

---

# Final Thoughts

Honestly, I started this mostly wanting to "play" with OPNsense and learn more deeply how:

* routing
* WireGuard
* DNS
* VLANs
* firewall rules
* recursive DNS

all interact together.

It became a much bigger learning experience than expected.

I still consider myself a beginner with OPNsense specifically, but I'm really impressed with:

* flexibility
* visibility
* debugging capabilities
* policy routing
* WireGuard integration
* overall architecture possibilities

The troubleshooting tools alone:

* tcpdump
* route inspection
* firewall logs
* live states

made learning much easier.

Hopefully this helps someone trying something similar.

Hey Nero

Thanks for responding .

I've made a summary that can help others :


Successfully validated transparent DNS interception + centralized DNS enforcement.

Test scenario:
Client intentionally queried external resolvers directly:

* 1.1.1.1
* 2.2.2.2

Goal:
Force all DNS traffic to local resolver regardless of client configuration.

Validation chain:

1. Client-side packet capture initially showed:

192.168.50.214 -> 2.2.2.2:53

2. However, WAN-side packet capture showed NO outbound DNS/53 traffic leaving externally.
3. At the same time, local Unbound overrides were applied successfully even when querying external resolvers directly:

dig @2.2.2.2 aljazeera.com

Returned:

0.0.0.0

which only existed in local Unbound configuration.

4. VLAN-side capture still showed original tuples (expected pre-NAT behavior):

192.168.50.214.57805 > 2.2.2.2.53: A? aljazeera.com

but WAN capture confirmed no actual DNS egress.

5. Final proof came from Unbound query logs:

query: 192.168.50.214 ufpa.br. A IN
reply: 192.168.50.214 ufpa.br. A IN NOERROR

6. Upstream DNS validation:
    WAN capture on TCP/853 showed:

192.168.1.74 -> 9.9.9.9:853

confirming:

* local interception works
* firewall itself performs upstream DNS-over-TLS
* clients no longer query external resolvers directly.

Final architecture:

Client
→ forced DNS interception (NAT redirect)
→ local Unbound
→ Quad9 DNS-over-TLS

Interesting observation:
Ingress/VLAN packet captures may still display original pre-NAT destination tuples, while WAN captures reveal the actual post-NAT egress reality.


Hope I'm correct on my understanding and that's also helps someone

Even more confusing:

* `dig @1.1.1.1 google.com
* `dig @2.2.2.2 aljazeera.com

still succeed from the client (macbook terminal) (just in case has something special with mac).

After applying the correct DNAT/SNAT Rules and related Firewall Rules that should work indeed, but instead of the queries going to those Public DNS Servers the queries should show up in the Query Log of your Private DNS Server ;)

I also noticed:

* some DNS requests *are* going to `192.168.50.1`
* but other requests still leave directly to public DNS servers

That's not good...

Try these settings : https://forum.opnsense.org/index.php?msg=259581
And if you have questions let me know :)

Hi Folks,

Actually maybe its working. Just need to know when capturing packets from opnsense, if it capture before NAT, if its the case, then probably its working.
Im confused now. lol

Hi everyone,

I'm trying to enforce DNS redirection/blocking on the latest OPNsense version for a VLAN network, but I'm seeing behavior that I don't fully understand and would appreciate some clarification from experienced users.

My setup:

* VLAN interface: `VLAN50Users`
* Firewall IP / local DNS resolver: `192.168.50.1`
* Goal:

  * Force all clients to use the local Unbound resolver
  * Prevent clients from using external DNS servers like:

    * `1.1.1.1`
    * `8.8.8.8`
    * `2.2.2.2`

What I configured:

1. NAT Port Forward rule:

* Interface: VLAN50Users
* Protocol: TCP/UDP
* Source: VLAN50Users net
* Destination: any
* Destination Port: 53
* Redirect target IP: 192.168.50.1
* Redirect target port: 53

2. Firewall rules on VLAN50:

* Pass DNS to `This Firewall`
* Block DNS to external destinations
* General allow rule below them

States were reset after every change.

However, packet captures still show direct DNS traffic going to public resolvers:

Example captures:

```text id="8x3y4q"
192.168.50.214 -> 1.1.1.1:53
192.168.50.214 -> 8.8.8.8:53
192.168.50.214 -> 2.2.2.2:53
```

Even more confusing:

* `dig @1.1.1.1 google.com`
* `dig @2.2.2.2 aljazeera.com`

still succeed from the client (macbook terminal) (just in case has something special with mac).

I also noticed:

* some DNS requests *are* going to `192.168.50.1`
* but other requests still leave directly to public DNS servers

Additional notes:

* Client is connected via Ethernet (not Wi-Fi)
* Rules are on the VLAN interface tab (not floating)
* Direction is IN
* Protocol is TCP/UDP
* Tested with macOS terminal using `dig`

Questions:

1. Is packet capture showing packets before NAT/filter processing?
2. Is there something different in newer OPNsense versions regarding DNS interception?
3. Is the recommended modern approach:

   * NAT redirect only?
   * block only?
   * or both together?
4. Is DNS over TLS / HTTPS interfering here?
5. Is there a known requirement for floating rules or reply-to disabling in this scenario?

I found this old tutorial:
https://forum.opnsense.org/index.php?topic=9245.0

but behavior on current versions seems different.

Any clarification on the correct/recommended way to fully enforce local DNS on current OPNsense would be greatly appreciated.

Thanks!

Hello Team,

I bought a EC-XS too and could figure out most of the steps, until arrive this thread.
My issue is due to the fact the device is not detecting my usb stick and im unable to boot from it and install opnsense.
I was wondering if someone face that or would have a tip to give me.
I could potentially install the opnsense in another computer with ec-xs hd, but i dont know if when i swap it back to ec-xs it will detect the interfaces and so on.
Any guidance its welcome.
ps.: im mac user, then maybe im struggling a little bit and not sure if my usb stick its really booting.