Is your feature request related to existing pfSense functionality that is missing from the API? Please describe.
Yes. pfSense Plus includes a feature for filtering Ethernet packets, configurable under System > Advanced > Firewall & NAT > Ethernet Filtering, but this functionality is not currently exposed through the API.
Describe the solution you'd like
pfSense Plus uses an internal rule schema to represent Ethernet filtering. A typical Ethernet filter rule looks like this:
{
"type": "pass",
"interface": ["any"],
"direction": "any",
"proto": "any",
"srctype": "single",
"src": "10.1.1.24",
"dsttype": "any",
"descr": "Allow 10.1.1.24",
"srcmac": "aa:bb:cc:00:11:22",
"dstmac": "",
"tag": "",
"tagged": "",
"bridgeto": "",
"sched": "",
"id": "1",
"tracker": "1234567890",
"after": "",
"ruleid": "",
"ethernet": "ethernet",
"save": "Save"
}
Since pfSense Plus already uses this schema internally to distinguish Ethernet rules, exposing this through the API should be straightforward. One possible approach would be to extend the existing /firewall/rule endpoint by allowing a flag such as:
This would indicate that the rule is an Ethernet rule, making API integration simpler with the existing rule structure. Alternatively, this logic could be placed in a dedicated endpoint (e.g., /firewall/ethernet).
Is your feature request related to existing pfSense functionality that is missing from the API? Please describe.
Yes. pfSense Plus includes a feature for filtering Ethernet packets, configurable under System > Advanced > Firewall & NAT > Ethernet Filtering, but this functionality is not currently exposed through the API.
Describe the solution you'd like
pfSense Plus uses an internal rule schema to represent Ethernet filtering. A typical Ethernet filter rule looks like this:
{ "type": "pass", "interface": ["any"], "direction": "any", "proto": "any", "srctype": "single", "src": "10.1.1.24", "dsttype": "any", "descr": "Allow 10.1.1.24", "srcmac": "aa:bb:cc:00:11:22", "dstmac": "", "tag": "", "tagged": "", "bridgeto": "", "sched": "", "id": "1", "tracker": "1234567890", "after": "", "ruleid": "", "ethernet": "ethernet", "save": "Save" }Since pfSense Plus already uses this schema internally to distinguish Ethernet rules, exposing this through the API should be straightforward. One possible approach would be to extend the existing
/firewall/ruleendpoint by allowing a flag such as:This would indicate that the rule is an Ethernet rule, making API integration simpler with the existing rule structure. Alternatively, this logic could be placed in a dedicated endpoint (e.g.,
/firewall/ethernet).