You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
For the purpose of automating and managing NAT port forwarding through an API, I am missing a solution that will allow me to programmatically configure port forwarding rules, add or remove specific ports, and manage related NAT entries without needing to use the OPNsense GUI. This would significantly improve the flexibility and efficiency of managing network settings in an automated environment.
Describe the solution you like
I would like to request a new API endpoint under the Firewall/NAT section that will allow users to:
Create new port forwarding rules with the required fields like source port, destination IP, and destination port.
Modify existing port forwarding rules to update parameters such as destination IP or port.
Delete port forwarding rules by specifying a rule identifier.
List current NAT port forwarding rules.
For example, an endpoint like:
POST /api/firewall/nat/portforward to add a new rule
GET /api/firewall/nat/portforward to list all current port forwarding rules
DELETE /api/firewall/nat/portforward/{id} to remove a rule
Additionally, the API should include proper authentication (e.g., API key-based) and support for error handling in case of invalid inputs or missing parameters.
Describe alternatives you considered
Currently, OPNsense only allows configuring port forwarding rules via the web interface, which limits automation capabilities. An alternative approach is to modify configuration files directly through SSH, but this is not user-friendly and requires manual intervention. Having a built-in API for NAT port forwarding management would provide a more seamless and efficient solution.
Additional context
Adding this feature will help integrate OPNsense with automation tools, improving both scalability and ease of management, especially for environments where port forwarding rules change frequently or need to be dynamically adjusted based on certain triggers.
The text was updated successfully, but these errors were encountered:
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
Is your feature request related to a problem? Please describe.
For the purpose of automating and managing NAT port forwarding through an API, I am missing a solution that will allow me to programmatically configure port forwarding rules, add or remove specific ports, and manage related NAT entries without needing to use the OPNsense GUI. This would significantly improve the flexibility and efficiency of managing network settings in an automated environment.
Describe the solution you like
I would like to request a new API endpoint under the Firewall/NAT section that will allow users to:
For example, an endpoint like:
POST /api/firewall/nat/portforward
to add a new ruleGET /api/firewall/nat/portforward
to list all current port forwarding rulesDELETE /api/firewall/nat/portforward/{id}
to remove a ruleAdditionally, the API should include proper authentication (e.g., API key-based) and support for error handling in case of invalid inputs or missing parameters.
Describe alternatives you considered
Currently, OPNsense only allows configuring port forwarding rules via the web interface, which limits automation capabilities. An alternative approach is to modify configuration files directly through SSH, but this is not user-friendly and requires manual intervention. Having a built-in API for NAT port forwarding management would provide a more seamless and efficient solution.
Additional context
Adding this feature will help integrate OPNsense with automation tools, improving both scalability and ease of management, especially for environments where port forwarding rules change frequently or need to be dynamically adjusted based on certain triggers.
The text was updated successfully, but these errors were encountered: