Messages

Ok fair so what happens when /usr/local/opnsense/scripts/wireguard/reresolve-dns.py is manually invoked without the workaround in place?


Cheers,
Franco

OK, tested this now on OPNsense 26.1.6-amd64

Wireguard site-to-site setup.

Router A has router B configured as a peer and endpoint address is a FQDN.
Router B has router A configured as a peer and endpoint address is a FQDN.

"Renew DNS for WireGuard on stale connections" --> is enabled and run periodically
--> cron entry: enabled * * * * * "Renew DNS for WireGuard on stale connections"

Step 1: disabled the workaround on both site-to-site routers (A and B)
--> workaround was the delayed restart (60 second delay) of Wireguard after system bootup to ensure that DNS is working when tunnel is restarted.
--> site-to-site tunnel is working at this point

Step 2: restart router A
--> wireguard tunnel starts properly as router A boots up
--> note that router B has not been restarted

Step 3: restart router B
--> wireguard site-to-site tunnel won't start on router B due to DNS resolve issues (Name does not resolve).
--> site-to-site tunnel is down

Step 4: manually invoke /usr/local/opnsense/scripts/wireguard/reresolve-dns.py on router B
--> tunnel is still down
--> no feedback from CLI and no log entry in Wireguard log

Step 5: manually invoke /usr/local/opnsense/scripts/wireguard/reresolve-dns.py on router A
--> tunnel is still down
--> no feedback from CLI and no log entry in Wireguard log

Step 6: restart Wireguard S2S on router A
--> tunnel is still down

Step 7: restart Wireguard S2S on router B
--> tunnel comes up and traffic flows

Any ideas how to debug this further?

I just tested this on OPNsense 26.1.7-amd64 as well. The behavior is exactly the same. The only way to get the tunnel online after rourter B restart is either
1) setup a script to perform delayed tunnel restart on router B after startup or
2) manually restart the tunnel on router B

Ok fair so what happens when /usr/local/opnsense/scripts/wireguard/reresolve-dns.py is manually invoked without the workaround in place?


Cheers,
Franco

OK, tested this now on OPNsense 26.1.6-amd64

Wireguard site-to-site setup.

Router A has router B configured as a peer and endpoint address is a FQDN.
Router B has router A configured as a peer and endpoint address is a FQDN.

"Renew DNS for WireGuard on stale connections" --> is enabled and run periodically
--> cron entry: enabled * * * * * "Renew DNS for WireGuard on stale connections"

Step 1: disabled the workaround on both site-to-site routers (A and B)
--> workaround was the delayed restart (60 second delay) of Wireguard after system bootup to ensure that DNS is working when tunnel is restarted.
--> site-to-site tunnel is working at this point

Step 2: restart router A
--> wireguard tunnel starts properly as router A boots up
--> note that router B has not been restarted

Step 3: restart router B
--> wireguard site-to-site tunnel won't start on router B due to DNS resolve issues (Name does not resolve).
--> site-to-site tunnel is down

Step 4: manually invoke /usr/local/opnsense/scripts/wireguard/reresolve-dns.py on router B
--> tunnel is still down
--> no feedback from CLI and no log entry in Wireguard log

Step 5: manually invoke /usr/local/opnsense/scripts/wireguard/reresolve-dns.py on router A
--> tunnel is still down
--> no feedback from CLI and no log entry in Wireguard log

Step 6: restart Wireguard S2S on router A
--> tunnel is still down

Step 7: restart Wireguard S2S on router B
--> tunnel comes up and traffic flows

Any ideas how to debug this further?

Ok fair so what happens when /usr/local/opnsense/scripts/wireguard/reresolve-dns.py is manually invoked without the workaround in place?


Cheers,
Franco

I will put this on my TODO list for the next maintenance period. All systems are now running and everything is OK but I will investigate this with my test setup when preparing for the next round of updates etc. I will test this before applying any updates just to confirm that we have a clear reference point.

There's also a DNS renew cron job for WireGuard to use... "Renew DNS for WireGuard on stale connections".

It's even more ironic than you might realise, because it is a Python rewrite of

https://github.com/WireGuard/wireguard-tools/tree/master/contrib/reresolve-dns

"Run this script from cron every thirty seconds or so, and it will ensure
that if, when using a dynamic DNS service, the DNS entry for a hosts
changes, the kernel will get the update to the DNS entry."

So the author of WireGuard recommends attempting to renew your DNS every 30 seconds.

You know why?

Because Kernel doesn't do DNS and all you do when configuring WireGuard (or any other tunnel using ifconfig) using a FQDN/hostname the tool will try to resolve it once and only the IP address is ever stored in the kernel, which makes it impossible for the kernel to renew the DNS.


Cheers,
Franco

In my case, this cron job has been enabled for a long time - and it was already enabled when I observed this change in behavior when upgraded from 25.7.11 to 26.1.3.

So, on 25.7.11:
"Renew DNS for WireGuard on stale connections" --> was enabled and run periodically
No issues when restarting firewall.

On 26.1.3:
"Renew DNS for WireGuard on stale connections" --> was enabled and run periodically
WireGuard did not start on reboot due to DNS resolve issues
--> delayed restart after reboot (60 seconds) --> WireGuard starts as expected.

I was happy enough to get it up and running with delayed restart after reboot so I didn't really investigate this further. However, noticed the change in the behavior although "Renew DNS for WireGuard on stale connections" has been enabled all the time.

I also suddenly started experiencing this issue when I upgraded from 25.7.11 to 26.1.3. I am using FQDN (not IPs) in the wireguard site-to-site config which was affected.

I knew that using FQDN was risky and not recommended as DNS resolution might not be working when Wireguard tries to start the tunnel. For some reason, it worked for a long time (maybe I was lucky). So, I was lazy and just too the risk until the problem emerged.

As I started experiencing the issues with 26.1.3., I implemented additional post-reboot script to restart Wireguard after DNS resolution is working (basically 60 seconds delay after startup - this gives time for Unbound to start and get going). For my site-to-site use case this is more than sufficient. Has been working without any issues for now. There are many tutorials in the web to explain how to do this.

I changed Interfaces / WAN / DHCPv6 client configuration prefix delegation size from 64 to 56 and now I got:
WAN ipv6 address zzz/128
LAN ipv6 address yyy/64

Also, the IPv6 connections are working after reboot without any manual work. Thanks!

WAN ipv6 address is zzz/128
LAN ipv6 address is yyy/56

LAN should be a /64. If it's showing /56, the prefix delegation size probably isn't configured correctly (Interfaces / WAN / DHCPv6 client configuration). This needs to be set to the prefix length actually delegated by your ISP.

Cheers
Maurice

Thanks for the hint. I checked that Interfaces / WAN / DHCPv6 client configuration has 64 as prefix delegation size.

[WAN]

Problems and steps to reproduce:
1. When I reboot the OPNsense box, WAN and LAN interfaces get the IPv4 and IPv6 addresses. Also, client in the LAN network get their IPv4 and IPv6 addresses correctly.
2. OPNsense box has both IPv4 and IPv6 connectivity to the internet. However, LAN clients can connect only using IPv4 trough the OPNsense box. IPv6 to the internet does not work.
3. When I disable IPv6 for LAN and immediately enable it back to "Track interface", LAN clients can connect to the internet using both IPv4 and IPv6 through the OPNsense box.
4. Both IPv4 and IPv6 connections remain stable until next time I reboot the system.

Just realized that I had a typo. Here are the correct steps to reproduce:
Problems and steps to reproduce:
1. When I reboot the OPNsense box, WAN and LAN interfaces get the IPv4 and IPv6 addresses. Also, client in the LAN network get their IPv4 and IPv6 addresses correctly.
2. OPNsense box has both IPv4 and IPv6 connectivity to the internet. However, LAN clients can connect only using IPv4 trough the OPNsense box. IPv6 to the internet does not work.
3. When I disable IPv6 for LAN WAN and immediately enable it back to "Track interface" DHCPv6, LAN clients can connect to the internet using both IPv4 and IPv6 through the OPNsense box.
4. Both IPv4 and IPv6 connections remain stable until next time I reboot the system.

Hi! I'm having the following issue with IPv6.

My OPNsense box is acting as firewall and router between WAN/LAN with the following setup:

Code Select Expand


TOPOLOGY
Internet -- WAN|opnsense|LAN -- LAN network

WAN igb0 IPv4 DHCP
WAN igb0 IPv6 DHCPv6

LAN em0 IPv4 static KEA DHCP serving the IPv4 LAN network (192.168.xx.yy/24)
LAN em0 IPv6 Track interface ISC DHCPv6 running on the interface

OPNsense addresses:
WAN ipv6 address is zzz/128
LAN ipv6 address is yyy/56

Router advertisement daemon enabled
pf enabled for both IPv4 and IPv6


Problems and steps to reproduce:
1. When I reboot the OPNsense box, WAN and LAN interfaces get the IPv4 and IPv6 addresses. Also, client in the LAN network get their IPv4 and IPv6 addresses correctly.
2. OPNsense box has both IPv4 and IPv6 connectivity to the internet. However, LAN clients can connect only using IPv4 trough the OPNsense box. IPv6 to the internet does not work.
3. When I disable IPv6 for LAN and immediately enable it back to "Track interface", LAN clients can connect to the internet using both IPv4 and IPv6 through the OPNsense box.
4. Both IPv4 and IPv6 connections remain stable until next time I reboot the system.

Restarting DHCP servers or router advertisement daemon doesn't help. So far the only way to get the IPv6 connectivity seems to be temporarily disabling IPv6 and then enabling it again.

Would anybody have any idea what might be wrong with my setup? What additional information you would need to help narrowing down the issue?

I started testing IPv6 with OPNsense 25.7.9 which was also the first time I observed the issue.

Now I am running OPNsense 25.7.10-amd64 and the issue is the same.

I have two firewalls which both are running 1.18 on OPNsense 24.7.7.

Wireguard is working without issues on both systems.

Are you running an untagged vlan on the same trunk? Thats not recommended. If you are running vlans all of them should be tagged, even vlan 1. Freebsd doesnt like this.

The untagged parent interface doesnt need to be assigned. If you use a switch with native vlan id (or how its called) use a sacrafice vlan like 2000 or something for the untagged traffic so it doesnt collide with tagged traffic on the connected trunk interface.

Dont know if thats related to the KEA issue.

Thank you! This was indeed the issue. Now all VLANs (including VLAN 1) are tagged and KEA is also working as expected after a system reboot.

KEA does not even issue a warning "em0 is not running" now that VLANs are properly configured (not mixing tagged and untagged).

I am testing KEA dhcpd on OPNsense 24.1.2_1-amd64.

I have configured five subnets (LAN + four VLANs) for which KEA is the dhcp server:
192.168.22.0/24 (LAN)
192.168.202.0/24 (VLAN 2)
192.168.205.0/24 (VLAN 5)
192.168.210.0/24 (VLAN 10)
192.168.220.0/24 (VLAN 20)

Everything is fine until I reboot the system. After reboot I see the following warning in the KEA log file:

WARN [kea-dhcp4.dhcpsrv.0x835bc5000] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface em0 is not running

It seems like KEA is starting before the em0 interface (which is the interface for the LAN and VLANs).

However, KEA seems to start and servers fine on the VLAN-intefaces but does not provide DHCP leases for the LAN interface. Once I restart the KEA service, it starts serving on both LAN interface and VLANs.

Again, when I reboot the system, the same issue occurs until I manually restart KEA.

Is this a known issue and is there any workaround for the issue? Is there any information I can provide for inspecting this further?

Please run the following commands

rm -fr /usr/local/opnsense/version/sensei-db
rm -fr /usr/local/sensei-db
Click in System - Firmware - Resolve Plugin Conflicts - Reset All Local Conflicts

Thank you! This did the trick! Rebooted the system to confirm everything is running fine - all good.

Just upgraded my OPNsense installation from 23.7.11 to 24.1.2.

I also upgraded Zenarmor from 1.16.1 to 1.16.3.

Now I see red os-sensei-db (missing) line at System -> Firmware -> Plugins.

I have tried both Resolve Plugin Conflicts -> Run the automatic resolver and Reset all local conflicts but the problem remains.

Some old threads suggest to reinstall Zenarmor to solve this issue but I was wondering if there is a way to fix whit problem without reinstalling Zenarmor.

OPNsense 24.1.2_1-amd64
FreeBSD 13.2-RELEASE-p10
OpenSSL 3.0.13

Hi,

A network issue is occurred. It should be ok now. Can you confirm?

Thanks!
Looks OK now, had to re-check with the button there though. Did not resolve on it's own.

Thanks! It works now!

In my case both systems show that the status has been UP for about 5 hours. It fixed without any interaction from my side.