Access Control: possibility to create not bidirectional rules (one direction) & port ranges in ACLs

[florian-obradovic]

Dear Team,

as an admin I want to create one-way / not bidirectional ACLs where I am allowed to:

1. ICMP ping everyone (I want to ping all machines but they shouldn't be allowed to ping all admin machines) < this works with stateful firewalls
2. access all machines with all ports for all protocols / or two rules for each proto (UDP / TCP)
3. define port ranges in ACL like 1433-1438 or 1-65535

Best regards, Flo.

[Gauss23]

+1 from my side. That's really an important feature.

[JonTheNiceGuy]

Partial-duplicate of #1328

[ThHirsch]

+1, otherwise following best practices in 'least privilege' setup is a faaar too tedious task.

[ThHirsch]

Hmm, the API documentation is stating, that port RANGES can be specified. see: Api-docu which states elemnts of "port_ranges - start - end' So is this just a missing piece int the current UI and we could create port-ranges for TCP and UDP by API already? Are there any plans to to have it in the UI soon?

[mad73923]

Hmm, the API documentation is stating, that port RANGES can be specified. see: Api-docu which states elemnts of "port_ranges - start - end' So is this just a missing piece int the current UI and we could create port-ranges for TCP and UDP by API already? Are there any plans to to have it in the UI soon?

I tried to set a policy via API with the following payload:

{
    "name": "Admin Common Ports to All",
    "description": "",
    "enabled": true,
    "query": "",
    "rules": [
        {
            "bidirectional": false,
            "description": "",
            "name": "Admin Common Ports to All",
            "action": "accept",
            "protocol": "tcp",
            "enabled": true,
            "sources": [
                "ctpbua196f2c73bgvc40"
            ],
            "destinations": [
                "ctp6us196f2c73bgvc00"
            ],
            "port_ranges": [
                {
                    "start": 1,
                    "end": 65535
                }
            ]
        }
    ],
    "source_posture_checks": []
}

Got the following answer: {"message":"for all or icmp protocol type flow can be only bi-directional","code":422} It seems like the UI isn't the blocker.

[JonTheNiceGuy]

So, I was talking to someone who was a project member, but isn't any more, who suggested doing instead of like @mad73923 wrote, do this instead:

{
    "name": "Admin Common Ports to All",
    "description": "",
    "enabled": true,
    "query": "",
    "rules": [
        {
            "bidirectional": false,
            "description": "",
            "name": "Admin Common Ports to All",
            "action": "accept",
            "protocol": "tcp",
            "enabled": true,
            "sources": [
                "ctpbua196f2c73bgvc40"
            ],
            "destinations": [
                "ctp6us196f2c73bgvc00"
            ],
            "ports": [
                1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
                ........
                65535
            ]
        }
    ],
    "source_posture_checks": []
}

OK, so listing all 64454 ports does work from a policy perspective, but what it also does do is crash the web UI.

If you are entirely managing your policy using the API, it's fine, but as soon as you try to use the webUI for it, it's no longer fine!

[mad73923]

Hi @JonTheNiceGuy alright, seems like a feasible hack. But a crashing webUI is no option for me. BR

[the-project-group]

I've heard rumors that a feature addressing this is in the making. @mlsmaycon is that true?

[Blackclaws]

So I've also just run into this and this would be very important to have as right now manually adding a huge list of ports isn't really feasible.

[YellowSnowman23]

I was making the switch from Tailscale to NetBird today, and I also ran into this.

This is unfortunately causing me to revert back to Tailscale for the time being. I have high hopes for NetBird.

[flotpg]

Both features have been addressed in the latest release IIRC. I didn’t test it yet.

[YellowSnowman23]

This policy results in "Any peer in "ALL" group can connect to any peer with "Admin" group"

Here is an example peer with just the "All" group

Edit: To add, I was on the peer with just the "All" group and i could RDP (Port 3389 obv) to WS-Arlis machine with the "Admin" group. Despite there being no policy to allow that (Yes the default policy is deleted as well)

[PatrLind]

Maybe the latest release v0.48.0 fixes this issue?

[artemklevtsov]

On the netbird.io:

[YellowSnowman23]

Maybe the latest release v0.48.0 fixes this issue?

Yeah, everything other than iOS is on v0.48.0. Problem still persists

[zsmith009]

Again, I was switching to netbird, but I saw this issue not fixed. Opened more than a year ago. The dashboard clearly doesn't seem to work. This should have been a high priority issue.

[the-project-group]

Is unidirectional still missing for all and ICMP ?

@mlsmaycon https://github.com/netbirdio/netbird/pull/3826 < is this addressing my use case?

[nazarewk]

I am not 100% sure when exactly it was implemented on the frontend, but it's possible to create unidirectional rules for all kinds of traffic using the web dashboard for a few days/weeks already.

[the-project-group]

Thanks, works!

[flotpg]

@mlsmaycon, @bcmmbaga, @pascal-fischer I think I found a bug (v0.59.3), probably related to https://github.com/netbirdio/netbird/pull/3826 ?

I have a unidirectional policy which allows peers which are member of Netbird-Admins to access all others. This doesn't work if the target peer is in the same Netbird-Admins group:

It works if I: a) set the group to bidirectional b) add a policy to which allows admins -> admins and disable the admins -> all:

[bcmmbaga]

Hi @flotpg,

Thanks for reporting this! We’re able to reproduce the issue and are already working on a fix.