Bug: sdwan_system_ipv4_device_access_feature fails with SCHVALID0001 due to destinationPort type mismatch
Summary
When configuring the sdwan_system_ipv4_device_access_feature resource with a destination_port match entry in a sequence, terraform apply fails with an HTTP 400 error from vManage. The vManage API rejects the payload because destinationPort is being serialised as an integer in the JSON body, but the vManage schema for this parcel endpoint requires it as a string.
Affected Resource
sdwan_system_ipv4_device_access_feature
Terraform / Provider Version
- Provider:
CiscoDevNet/sdwan
- Version:
0.9.0 (latest)
- NaC Module:
netascode/nac-sdwan
- vManage / SD-WAN Manager: 20.18.2.1
- IOS XE SD-WAN: 17.18.1
Terraform Configuration during the plan (some omitted for brevity)
sequences :
[
create
{
create
base_action :
"accept"
create
destination_data_prefix_list_id :
"1c440898-b8af-4616-961a-e27429a7c040"
create
device_access_port :
22
create
id :
1
create
name :
"acl"
}
create
{
create
base_action :
"accept"
create
destination_data_prefix_list_id :
"3d2f9510-7775-4bcc-b2e3-2eb0382acb55"
create
device_access_port :
22
create
id :
2
create
name :
"acl"
}
create
{
create
base_action :
"accept"
create
destination_data_prefix_list_id :
"23e9f272-9322-4822-957d-7b05e49faafd"
create
device_access_port :
22
create
id :
3
create
name :
"acl"
}
create
{
create
base_action :
"accept"
create
destination_data_prefix_list_id :
"d16a0b8c-e365-4d08-a77b-e9797caa5158"
create
device_access_port :
161
create
id :
4
create
name :
"acl"
}
]
Error: Failed to configure object (POST), got error: HTTP Request failed:
StatusCode 400,
{
"error": {
"message": "Invalid Json Payload Input",
"code": "SCHVALID0001",
"details": "{"Validation Errors":{"Invalid Format Attributes":["data.sequences[3].matchEntries.destinationPort"]}}",
"type": "error"
}
}
---
### Root Cause
The provider serialises `destination_port` as a bare **integer** in the JSON payload sent to the vManage API endpoint `POST /v1/feature-profile/sdwan/system/{systemId}/ipv4-device-access`.
The vManage API schema for this specific parcel endpoint appears to require `destinationPort` to be a **string** (e.g. `"22"` not `22`).
The GUI abstracts port selection behind named protocol dropdowns (SSH, SNMP), which correctly constructs the string-typed payload. The Terraform provider has no equivalent handling and sends the integer directly.
Expected Behaviour
terraform apply should succeed and create the device access feature with the destination port match entry correctly serialised as a string in the API payload.
Actual Behaviour
terraform apply fails with HTTP 400 / SCHVALID0001 on every attempt when destination_port is included in a sequence's match entries.
Workaround
Currently working around this by using a sdwan_cli_config_feature (CLI Add-On Profile) to push the ACL and VTY access-class configuration directly:
resource "sdwan_cli_config_feature" "vty_acl" {
name = "vty-acl-cli"
feature_profile_id = sdwan_system_feature_profile.system_profile.id
cli_configuration = <<-EOT
ip access-list extended VTY_FILTER_SSH
10 permit tcp 10.10.10.0 0.0.0.255 any eq 22
100 deny ip any any log
line vty 0 4
access-class VTY_FILTER_SSH in vrf-also
transport input ssh
line vty 5 80
access-class VTY_FILTER_SSH in vrf-also
transport input ssh
EOT
}This works but loses the idiomatic config groups approach and drift detection that the native resource would provide.
Suggested Fix
Change the schema type for destination_port (and potentially source_port) within the sdwan_system_ipv4_device_access_feature resource from Int64Attribute to StringAttribute, and ensure the JSON marshalling wraps the value in quotes when constructing the API payload.
Happy to test a fix against our environment if a branch or pre-release build is available.
Bug:
sdwan_system_ipv4_device_access_featurefails with SCHVALID0001 due todestinationPorttype mismatchSummary
When configuring the
sdwan_system_ipv4_device_access_featureresource with adestination_portmatch entry in a sequence,terraform applyfails with an HTTP 400 error from vManage. The vManage API rejects the payload becausedestinationPortis being serialised as an integer in the JSON body, but the vManage schema for this parcel endpoint requires it as a string.Affected Resource
sdwan_system_ipv4_device_access_featureTerraform / Provider Version
CiscoDevNet/sdwan0.9.0(latest)netascode/nac-sdwanTerraform Configuration during the plan (some omitted for brevity)
sequences :
[
create
{
create
base_action :
"accept"
create
destination_data_prefix_list_id :
"1c440898-b8af-4616-961a-e27429a7c040"
create
device_access_port :
22
create
id :
1
create
name :
"acl"
}
create
{
create
base_action :
"accept"
create
destination_data_prefix_list_id :
"3d2f9510-7775-4bcc-b2e3-2eb0382acb55"
create
device_access_port :
22
create
id :
2
create
name :
"acl"
}
create
{
create
base_action :
"accept"
create
destination_data_prefix_list_id :
"23e9f272-9322-4822-957d-7b05e49faafd"
create
device_access_port :
22
create
id :
3
create
name :
"acl"
}
create
{
create
base_action :
"accept"
create
destination_data_prefix_list_id :
"d16a0b8c-e365-4d08-a77b-e9797caa5158"
create
device_access_port :
161
create
id :
4
create
name :
"acl"
}
]
Error: Failed to configure object (POST), got error: HTTP Request failed:
StatusCode 400,
{
"error": {
"message": "Invalid Json Payload Input",
"code": "SCHVALID0001",
"details": "{"Validation Errors":{"Invalid Format Attributes":["data.sequences[3].matchEntries.destinationPort"]}}",
"type": "error"
}
}
The GUI abstracts port selection behind named protocol dropdowns (SSH, SNMP), which correctly constructs the string-typed payload. The Terraform provider has no equivalent handling and sends the integer directly.
Expected Behaviour
terraform applyshould succeed and create the device access feature with the destination port match entry correctly serialised as a string in the API payload.Actual Behaviour
terraform applyfails with HTTP 400 /SCHVALID0001on every attempt whendestination_portis included in a sequence's match entries.Workaround
Currently working around this by using a
sdwan_cli_config_feature(CLI Add-On Profile) to push the ACL and VTYaccess-classconfiguration directly:This works but loses the idiomatic config groups approach and drift detection that the native resource would provide.
Suggested Fix
Change the schema type for
destination_port(and potentiallysource_port) within thesdwan_system_ipv4_device_access_featureresource fromInt64AttributetoStringAttribute, and ensure the JSON marshalling wraps the value in quotes when constructing the API payload.Happy to test a fix against our environment if a branch or pre-release build is available.