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.
Describe the bug
The schema for "address" for PATCH /api/v2/vpn/wireguard/tunnel says:
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:
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:
Affected Endpoints:
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.