Messages

Hey, sorry to hear your IPv6 settings are still not working.

1. My RA settings are blank. WireGuard assigns the IPv6 addresses, and I'm using Dnsmasq for DHCPv6 address assignment on my LAN.
2. NAT Outbound is set to Automatic Outbound NAT Rule Generation.
3. NAT NPTv6 is also blank.

What settings do you have set up for your WireGuard Server Instance? I know you have requested a /56 prefix from your ISP, but are you sure it's honoring it? When I tried to use a /56 the ISP kicked me back to a /64. The lowest it would let me go was a /60. See my last post regarding the Interface > Overview, to ensure your ISP is honoring the /56 prefix.

I also see you have 2a01:xxxx:xxxx:xx03::9001 listed as your DNS. When you entered this into your tunnel address, did you list it as 2a01:xxxx:xxxx:xx03::9001/64? This is just like setting the subnet mask for IPv4. The /64 in the tunnel address tells WireGuard that you've set the prefix for your VPN to 2a01:xxxx:xxxx:xx03. You should also make sure that your LAN is not using the same prefix as your VPN.

BOOM! Fixed! Thank you for your help with this.  I thought I was going crazy.  I'm sorry I didn't see the obvious solution. 

Have you tried turning it off and on again?
or
Have you tried uninstalling and reinstalling?

You Rock!
 

[a]

Hi Johnshill, I ran into a few issues getting IPv6 working with my WireGuard as well.  I'm going to go over some of my settings, maybe they will help you get yours set setup. I'm going to go over a lot of the basics, so apologies if some of this seems redundant. 

My ISP is Xfinity.

Interfaces > WAN
Generic configuration
IPv6 Configuration Type: DHCPv6
DHCPv6 client configuration
Prefix delegation size: 60
Request prefix only: unchecked
Request DNS configuration: Checked
Send prefix hint: Checked

Interfaces > WireGuardVPN
IPv4 Configuration Type: None
IPv6 Configuration Type: None

Interfaces > Overview
Go to the WAN row
Make note of the IPv4 Address (ignore the / and the numbers after it)
Next, select the Magnifying Glass icon at the end of the WAN Row
Scroll down to "Dynamic IPv6 prefix received", Mine is set as: 2601:xxxx:xxxx:xxxx::/60 (Redacted for privacy)
Notice the /60 prefix.  This means that I can use the following for my IPv6 address:
2601:xxxx:xxxx:xxx[0-f]::/60

I'm using 2601:xxxx:xxxx:xxxa::/64 for my LAN
I'm using 2601:xxxx:xxxx:xxxb::/64 for my VPN
The /64 means that the last digit of the prefix is locked for the specific network

VPN > WireGuard > Instances tab
Enabled: checked
Name: WG-VPN
Pubic Key: click Gear to generate Public and Private Key pair
Listen Port: set port (example: 51820)
Tunnel Address (this is where you set the IPv4 and IPv6 addresses for your VPN): 192.168.101.1/24 2601:xxxx:xxxx:xxxb::fffa/64
NOTICE the /64 and the b on the prefix, I also set the last 4 hex digits (hextet?)

Use the Peer Generator to create your peers.  It's an amazing tool:

Instance: WG-VPN
Endpoint: External IPv4 Address and port (Listen Port set earlier). Example: 17.16.15.14:51820
Name: Client Name. Example: MyPhone
Public Key: Auto Gen
Private Key: Auto Gen
Address: 192.168.101.2/32,2601:xxxx:xxxx:xxxb::fffb/128
DETAILS for Address: IPv4 address generated, Example: 192.168.101.2/32 IPv6 address prefix with full /128 address. You still need to specify the last hextet of the IP.  Prefill Example: 2601:xxxx:xxxx:xxxb::/128.  You need to add the last 4 of the ip: fffa or something, so it reads as follows: 2601:xxxx:xxxx:xxxb::fffa/128

Allowed IPs: 0.0.0.0/0,::/0
DETAILS for Allowed IPs: 0.0.0.0/0 is the IPv4 note to allow all IPv4 traffic through the VPN, ::/0 is the IPv6 version.

DNS Servers: 192.168.101.1,2601:xxxx:xxxx:xxxb::fffa
DETAILS for DNS Servers: It's your VPN Tunnel addresses.

When setting up the Clients, use the QR code.  Test with your phone. It basically starts with a blank rule and copys everything from the config section. 


Store and generate next: Checked
Enable WireGuard: Checked

ONLY WHEN THE QR CODE IS SAVED ON YOUR PHONE SHOULD YOU HIT APPLY. YOU CAN'T TEST OR USE THE VPN UNTIL YOU APPLY THE CHANGES! YOU CAN'T VIEW THE PRIVATE KEYS ONCE THE APPLY IS PRESSED, SO ORDER OF OPERATIONS IS IMPORTANT!

1. Enter info
2. Scan QR Code, Save to Device
3. Click Apply
4. Test VPN connections

Let us know what matches, what changes you didn't use, and what questions you have.

Info:
OPNsense Ver:    26.1.8
os-caddy Ver:   2.1.0

I was clearing out some old API settings and deleted the one I was using for Caddy.  I followed the steps in the directions to setup a new API Token.  After a lot of troubleshooting, I've come to the conclusion that the Caddy Plugin is not accepting my new API Token, because Cloudflare is now giving out longer API Tokens than what the plugin is expecting. 

Caddy will fail to start when the new API Token is saved.  However, it will not add anything to the log file.  I had to run the following shell command, and here is the result:

Command:

Code Select Expand

caddy validate --config /usr/local/etc/caddy/Caddyfile
Reply:

Code Select Expand

2026/05/12 23:27:32.387 INFO    using config from file  {"file": "/usr/local/etc/caddy/Caddyfile"}
2026/05/12 23:27:32.388 WARN    No files matching import glob pattern   {"pattern": "/usr/local/etc/caddy/caddy.d/*.global"}
2026/05/12 23:27:32.388 WARN    No files matching import glob pattern   {"pattern": "/usr/local/etc/caddy/caddy.d/*.conf"}
2026/05/12 23:27:32.389 WARN    caddyfile       Unnecessary header_up X-Forwarded-For: the reverse proxy's default behavior is to pass headers to the upstream
2026/05/12 23:27:32.389 WARN    caddyfile       Unnecessary header_up X-Forwarded-Host: the reverse proxy's default behavior is to pass headers to the upstream
2026/05/12 23:27:32.390 WARN    caddyfile       Unnecessary header_up X-Forwarded-For: the reverse proxy's default behavior is to pass headers to the upstream
2026/05/12 23:27:32.390 WARN    caddyfile       Unnecessary header_up X-Forwarded-Host: the reverse proxy's default behavior is to pass headers to the upstream
2026/05/12 23:27:32.392 INFO    adapted config to JSON  {"adapter": "caddyfile"}
2026/05/12 23:27:32.393 INFO    redirected default logger       {"from": "stderr", "to": "unixgram//var/run/caddy/log.sock"}
Error: loading dynamic_dns app module: provision dynamic_dns: loading DNS provider module: loading module 'cloudflare': provision dns.providers.cloudflare: API token 'cfut_PhB{Rest-Of-The-Key}' appears invalid; ensure it's correctly entered and not wrapped in braces nor quotes

Notice the error at the end of the startup attempt.  It says that the token is invalid.  The API tokens generated by Cloudflare now have a prefixes:

API Token (User API Token in Directions): cfut_{48 char string}
Global API Key (Not Recommended): cfk_{48 char string}
Account API Token: cfat_{48 char string}

These Cloudflare prefixes make the API Token longer than what is expected and prevent the service from starting properly. The wiki documentation page lists https://github.com/caddy-dns/cloudflare as the GitHub for Cloudflare, and the cloudflare.go file shows that the old API Tokens, which may still be in use, are 35-50 characters long (see line 27).  The new API Tokens are 32-256 characters, and it takes the prefix into account (see line 30). 

Will this update be incorporated into an update at any point, or is there another way I should update the DNS records?

I followed the high level guidance provided by franco in this thread:

https://forum.opnsense.org/index.php?topic=15875.0

Worked perfectly. Very simply:

- Boot OPNsense to Single-User Mode
- Mount the / with "mount -o rw /"
- Run "/usr/local/sbin/opnsense-shell password"

It will ask you if you want to reset the root password and also the authentication method... it will shut off the TOPT server and flip you back to local database.

Then "/sbin/reboot" and you should be good to go.

Cheers!

Thank you, jim2cpu! This helped me login again. Had to follow the steps for ZFS (https://docs.opnsense.org/troubleshooting/password_reset.html).

The first question was, do you want to change Authentication to Local Database!  ;D
Still had to reset the root password, but who cares. I was able to login after the reboot.

Yes, maybe 24.7 if all goes well. We will discuss roadmap stuff in two weeks.


Cheers,
Franco

I switched over to Kea DHCPv4 and it works great. I haven't run into any issues using Kea DHCPv4 and ISC DHCPv6 together, but it would be nice to have the latest and greatest running both versions. Hopefully we will see Kea DHCPv6 in 24.7. I didn't see anything in the current roadmap for 24.7, so I'm a little worried that we wont see it until 25.1