Extend firewall plugin (for API support) with snat support [tracking ticket] #1749
Comments
… different prefixes than "M" when sharing the same namespace. While here, also perform a style sweep. Needed for opnsense/plugins#1749 (using the same namespace as the aliases in core)
It's probably better to keep (filter)rules and source nat rules combined, so we can stick to the same rollback pattern and guarantee a consistent set when performing a rollback.
… different prefixes than "M" when sharing the same namespace. While here, also perform a style sweep. Needed for opnsense/plugins#1749 (using the same namespace as the aliases in core)
- reuse filter template, link endpoint to selected controller (filter/snat) - push shared code to FilterBaseController
… possible to call api/firewall/filter_base endpoints directly, for #1749
…sses, add used model when using standard templates. needed to better explain documentation for opnsense/plugins#1749
|
(internal reference) this point should be in 20.1.4-devel |
since filter rules and source nat rules share source and destination constructions, we can easily loop over the types and detect if source nat fields exists when validating.
…se/plugins#1749 (cherry picked from commit d24a546)
… different prefixes than "M" when sharing the same namespace. While here, also perform a style sweep. Needed for opnsense/plugins#1749 (using the same namespace as the aliases in core) (cherry picked from commit c81b5b8)
I did not find a relevant issue for this, nor a better place to ask: I am wondering if you have DNAT support in Firewall Plugin in scope for near future? (EDIT: found this thread, which is relevant https://forum.opnsense.org/index.php?topic=25861.0) |
|
@wrobelda not really, we build this for a client back in the days, it's not extremely difficult to add portforwards in terms of complexity but for us there's no business case at the moment. |
|
Thanks for a quick response. I need a programmatic access to a DNAT rule, but luckily the "Alias" workaround laid out in the thread I linked should be sufficient. |
|
you could also consider the relayd plugin (https://docs.opnsense.org/manual/relayd.html) when it comes to forwarding |
In #1720 we worked on API support for the basic firewall features, this ticket describes the extension with source (outbound) nat rules.
Scope:
This feature addition is not about: port forwards and 1:1 rules, these are destination type nat rules, which therefor lie outside the scope of this ticket.
At minimum this plugin should provide the possibility to use standard API endpoints, similar to the ones for all other new style features.
The rules settings provided should be the following:
Existing (manual) rules can't be changed with this plugin, since they live in another section of the configuration (separation of concerns).
The rules created by the api don't depend on mode settings of the outbound nat rules, such as "Manual outbound NAT rule generation" or "Hybrid outbound NAT rule generation".
Since automatic rules are not visible elsewhere in the gui, it's imperative that this plugin has a simple user interface to retain visibility.
The text was updated successfully, but these errors were encountered: