For example:
If I have droplets B1, B2 and B3, all tagged “B”, and a droplet A1 with the firewall rule “allow HTTP from tag:B”, A1 receives HTTP traffic from B1, B2 and B3. All OK so far.
But if I then create B4, tagged “B”, A1 does not accept traffic from it, unless I remove “B” from the firewall rule and re-add it.
This would seem to be problematic when adding new droplets that need to consume a secured internal service.
Is this expected behaviour? I can use the API to add a rule for each new droplet, but that seem like a pity.
Cheers, Graham.
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
i’m having the same exact problem and it is definitely not the expected behavior.
in addition, new when you add a droplet to your firewall by using tags and then assign that tag to a new droplet, the firewall will not apply to the newly tagged droplet as it should.
conversely, destroying a droplet that has been tagged for a firewall will not remove that droplet from the firewall and you will be left with orphan droplets when you view the firewall. i believe what is actually happening here is that the firewalls and rules that you set up are being assigned their various droplets only at the time that the firewall or firewall rule is saved.
see: [https://www.digitalocean.com/community/tutorials/an-introduction-to-digitalocean-cloud-firewalls]
where it says:
Any Droplet or Load Balancer already tagged will be allowed to establish a connection, and new or existing Droplets will be allowed as soon as they are tagged.
i’ll open a case.
I haven’t pursued this issue since I posted it here. For now, I’ve just worked around it (there is no work around that’s as nice as “it just working”, which is what I hoped tagged rules would do).
Having the same problem here, did you contacted support?
Also experiencing this.
An update to this post, I’ve had success applying the tag to the newly created droplet in a separate call to the “tags” API after the droplet is in the active state. It seems the firewall doesn’t pick up the droplet only if the tag is included in the droplet creation body. I’m wondering if this has something to do with the unavailability of the droplet at the time of creation.
I was going to report this issue but after reading it seems you’re all experiencing the same problem as I am. Core issue is that there is a noticeable delay between API creation of a new droplet (with tag), and firewall adding said droplet (by tag) to the firewall. As a result, I’m unable to communicate with new droplets. I’m not sure if this is accurate or not, but it seems as though after I browse the UI in the firewalls section, the droplet becomes listed, though I’m unsure as to whether or not this is purely coincidence.