Repository navigation
PATCH /api/v2/vpn/wireguard/tunnel does not actually ignore the address parameter if the tunnel is assigned an interface #902
Description
Describe the bug
The schema for "address" for PATCH /api/v2/vpn/wireguard/tunnel says:
The IPv4 or IPv6 addresses to assign this WireGuard tunnel interface. This field is ignored if this tunnel interface is assigned to an existing pfSense interface object.
However, if you try to call that endpoint with the same address that is assigned to the interface, you get:
{
"code": 400,
"status": "bad request",
"response_id": "WIREGUARD_TUNNEL_ADDRESS_AND_MASK_ALREADY_IN_USE",
"message": "Field `addresses` encountered a nested validation error: This tunnel`s `address` and `mask` is already in use on this system.",
"data": []
}To Reproduce
Steps to reproduce the behavior:
- Create a wireguard tunnel and give it some ip address / mask
- Assign the tunnel to an interface, and give that interface the same ip address / mask
- Make a PATCH call as above with the same ip address / mask
- See error
Expected behavior
"address" should be ignored
Screenshots or Response
If applicable, add screenshots or response data to help explain your problem.
pfSense Version & Package Version:
- pfSense Version: 2.8.1
- Package Version 2.8.1
Affected Endpoints:
- URL: /api/v2/vpn/wireguard/tunnel
Additional context
It seems like there's some hidden state in pfsense that's still storing the address on the tunnel object even when it's assigned to an interface. It seems you can null it out by PATCHing an empty address.
Activity
fix(WireGuardTunnel): ignore addresses if tunnel has a current iface …
jaredhendrickson13 commentedon Jun 5, 2026
I'll have this addressed in the next patch.
Thanks!
jaredhendrickson13 commentedon Jun 8, 2026
Realizing now, the fix in v2.8.1 won't cover every scenario where this validation can be triggered. Since the validation occurs in a child object, not the direct object being updated, the condition can still occur. I'll see what can be done to avoid the child validation as well.
kaysond commentedon Jun 8, 2026
It seems that my use case falls under this scenario because I'm still seeing the error on 2.8.1.
fix(WireGuardTunnel): adjust 'addresses' validation pre-condition tim…
fix(WireGuardTunnel): adjust 'addresses' validation pre-condition tim…
kaysond commentedon Jun 9, 2026
@jaredhendrickson13 confirming this is fixed in 2.8.2. FYI - the file name of the 2.8.2 release package is wrong (but the tag in the package is correct, and the URL in the readme matches the incorrect file name).
Thanks!
jaredhendrickson13 commentedon Jun 9, 2026
Thanks for confirming, glad that's working now. The version name in the release package's filename relates to the version of pfSense the package is built for, not the version of the package itself. A little confusing at a glance since the package version has caught up to the pfSense version but is actually correct.