Firewall filter rules order #293
Comments
|
Hi, can you show both terraform scenarios that give not expected behavior? Which can be executed to reproduce the problem. |
|
Hello @vaerh, I'm unsure for the value of the place_before parameter in the resource ( data.routeros_firewall.fw ). So, to apply this configuration to a new firewall, we'll need to apply the configuration without the place_before parameter and then reapply the rules one by one with the place_before. That's why, i open this request for a new feature ^^. Have a nice day. |
|
Yeah, unfortunately that's not a good scenario. On MT, the rules will be created exactly in the sequence in which the REST requests arrive. Parallelism of resource creation > 1 will result in rules being created in a chaotic order. Maybe this discussion will tell you something. |
|
For comparison, in ansible, we can set the whole linux iptables firewall rules using a single ansible module as: # NB this is equivalent to iptables-apply /etc/iptables/rules.v4.backstage
- name: Set the iptables rules
community.general.iptables_state:
state: restored
path: /etc/iptables/rules.v4.backstage
async: "{{ ansible_timeout }}"
poll: 0
# NB this is skipped when running in check mode because it requires the
# backstage file.
when: not ansible_check_modeI think this terraform provider should have a resource that allows us to do the same. That is, declare the desired state using a single resource, which would ensure the rules are applied in one go/transaction and in the order defined in the resource. IMHO, the existing terraform resources provided by this module are somewhat misleading, because, in practice, the actual router firewall rules are created out of order (using |
|
While thinking about the answer, I also considered the option of a resource with a multiple set of rules, but this would entail the impossibility to operate with individual rules and would require significant refactoring. |
|
@vaerh, that would be nice! if possible, the provider should abort the plan when the user mixes the two resource types. The entire rule set apply should be transactional and idempotent. if that's not possible to implement with the existing mikrotik api, we should try to plea mikrotik to implement it. mainly, because implementing this is tricky (e.g. deleting the firewall rules and creating them again leaves a open window of time without an active firewall; also, while deleting the firewall rules you have to be careful for not blocking the active provider connection to the mikrotik api; also, "Here be dragons"). |
|
I'm glad we're both presenting the dubious benefit of recreating firewall rules on the fly. |
|
from the mikrotik forums, it seems there's no way to do this in a elegant way, nor it seemed to peek mikrotik interest in implementing that feature. so I think I will not buy Mirotik hardware at all. FWIW, I've found these references related to the firewall rules: |
Do you know which fw hardware is properly implemented with tf? |
|
@Drygster I have a concept for a firewall rule sorter, but in keeping with MT tradition it doesn't always work the way I envision. Sometimes the rules are sorted, sometimes not. Is there any way to test the module without modifying the main provider? |
A number of vendors support their TF providers, you can see if they are available in the registry |
|
Hello @vaerh, "Sometimes the rules are sorted, sometimes not. Is there any way to test the module without modifying the main provider?" |
|
@Drygster What OS do you use? I will make a provider build for you. I'm also debugging the functionality on CHR, but maybe you'll do much better. |
|
~/.terraformrc provider_installation {
dev_overrides {
"registry.terraform.io/terraform-routeros/routeros" = "/path-to-directory-w-provider/terraform-provider-routeros"
}
}test.tf variable "rule" {
type = list(object({
chain = string
action = string
connection_state = optional(string)
in_interface_list = optional(string, "all")
out_interface_list = optional(string)
src_address = optional(string, "0.0.0.0/0")
dst_address = optional(string)
src_port = optional(string)
dst_port = optional(string)
protocol = optional(string)
comment = optional(string, "(terraform-defined)")
log = optional(bool, false)
disabled = optional(bool, true)
position = optional(number)
}))
default = [
{ chain = "input", action = "accept", position = 00 },
{ chain = "input", action = "accept", position = 01 },
{ chain = "input", action = "accept", position = 02 },
{ chain = "input", action = "accept", position = 03 },
{ chain = "input", action = "accept", position = 04 },
{ chain = "input", action = "accept", position = 05 },
{ chain = "input", action = "accept", position = 06 },
{ chain = "input", action = "accept", position = 07 },
{ chain = "input", action = "accept", position = 08 },
{ chain = "input", action = "accept", position = 09 },
{ chain = "input", action = "accept", position = 10 },
{ chain = "input", action = "accept", position = 11 },
{ chain = "input", action = "accept", position = 12 },
{ chain = "input", action = "accept", position = 13 },
{ chain = "input", action = "accept", position = 14 },
{ chain = "input", action = "accept", position = 15 },
{ chain = "input", action = "accept", position = 16 },
{ chain = "input", action = "accept", position = 17 },
{ chain = "input", action = "accept", position = 18 },
{ chain = "input", action = "accept", position = 19 },
{ chain = "input", action = "accept", position = 20 },
{ chain = "input", action = "accept", position = 21 },
{ chain = "input", action = "accept", position = 22 },
{ chain = "input", action = "accept", position = 23 },
{ chain = "input", action = "accept", position = 24 },
{ chain = "input", action = "accept", position = 25 },
{ chain = "input", action = "accept", position = 26 },
{ chain = "input", action = "accept", position = 27 },
{ chain = "input", action = "accept", position = 28 },
{ chain = "input", action = "accept", position = 29 },
{ chain = "input", action = "accept", position = 30 },
{ chain = "input", action = "accept", position = 31 },
]
}
locals {
rule_map = { for idx, rule in var.rule : idx => rule }
}
resource "routeros_ip_firewall_filter" "rule" {
for_each = local.rule_map
chain = each.value.chain
action = each.value.action
comment = each.value.position
log = each.value.log
disabled = each.value.disabled
connection_state = each.value.connection_state
in_interface_list = each.value.in_interface_list
src_address = each.value.src_address
dst_port = each.value.dst_port
protocol = each.value.protocol
position = each.value.position
}
resource "routeros_move_items" "fw_rules" {
resource_name = "routeros_ip_firewall_filter"
move = zipmap(values(routeros_ip_firewall_filter.rule)[*].position, values(routeros_ip_firewall_filter.rule)[*].id)
depends_on = [routeros_ip_firewall_filter.rule]
}If you use part of your original configuration for testing, it would be very interesting to know the result. |
|
|
Use linux-amd64.zip |
|
Hello @vaerh, |
|
@Drygster, to close this issue... Please also delete the rules and the state file and execute the plan that way: TF_LOG=debug ROS_LOG_COLOR=1 terraform ...From the output I will only be interested in the last green lines that have |
|
Helo @vaerh, |
|
Thank you! Moving the rules unfortunately doesn't work. Looks like an internal ROS error. Rules are moved from the console in a chaotic way. So this implementation will not help us. |
|
After a number of experiments on this issue, I can state a disappointing result: the creation of rule groups requires a major redesign of the main data serializer, which is used in all provider resources. |
|
@Drygster |
|
🎉 This issue has been resolved in version 1.27.2 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Hello everyone,
New on terraform, i try to create a Terraform configuration for firewalls who could be apply on fresh firewall installation.
Is your feature request related to a problem? Please describe.
When using the "place_before" parameter, we encountered problem between the new incoming rules who need to be order at the same time.
For example :
Describe the solution you'd like
When integrating new rules, the use of "place_before" will be usable directly.
Then, permitting to reapply the configuration on different environment without the need to :
comment "place_before" -> apply a first time -> uncomment -> reapply with the "place_before"
Additional context
Is there a meaning to add a parameter to force the rule order and configure the environment on the first terraform apply ?
The text was updated successfully, but these errors were encountered: