Appliance L3 Firewall Rules - Unexcepted Behavior/Error Handling

[jmarstonccc]

When performing an HTTP put request against endpoint /networks/{networkId}/appliance/firewall/l3FirewallRules and specifying a protocol of "any" or "icmp" the API should return an error if I specify a "srcPort" or "destPort". However the API returns a success and changes these values to "Any".

Here is an example body of an HTTP put request that should return an error
{
"rules": [
{
"comment": "Allow TCP traffic to subnet with HTTP servers - POSTMAN.",
"policy": "allow",
"protocol": "icmp",
"destPort": "443",
"destCidr": "1.1.1.1/32",
"srcPort": "Any",
"srcCidr": "Any",
"syslogEnabled": false
}
]
}

This is the response returned from the API:
{
"rules": [
{
"comment": "Allow TCP traffic to subnet with HTTP servers - POSTMAN.",
"policy": "allow",
"protocol": "icmp",
"srcPort": "Any",
"srcCidr": "Any",
"destPort": "Any",
"destCidr": "1.1.1.1/32",
"syslogEnabled": false
},
{
"comment": "Default rule",
"policy": "allow",
"protocol": "Any",
"srcPort": "Any",
"srcCidr": "Any",
"destPort": "Any",
"destCidr": "Any",
"syslogEnabled": false
}
]
}

[alemabrahao]

It is expected, albeit not explicitly documented as a validation rule. When protocol is set to "icmp" or "any", the API automatically overrides srcPort and destPort to "Any" during processing.
This behavior is not flagged as an error, and the request returns a 200 OK with the modified rule.

If you need stricter validation, you might consider implementing client-side checks before sending the request or I suggest you open a support case.

[jmarstonccc]

I already opened a support case and they confirmed the same thing. I'd like to submit a feature request so this can be fixed in the future. This behaviors differs from the dashboard and should return an error.