Future Consideration Feature Request | Variable support in ACLs for IPv6 prefix
Future Consideration Feature Request | Variable support in ACLs for IPv6 prefix
I've deployed successfully IPv6 on my network, although my ISP sometimes changes the IPv6 scope, which impacts the ACLs so some systems are not accessible from the Internet over IPv6.
So for example I currently have a group profile with the systems that are allowed to have inbound SSH traffic (TCP/22), but this is hard coded:
2001:c0ff:ee:5838::1:241 / 128
So as you can see the prefix is 2001:c0ff:ee:5838::, would be nice to have a 'variable' to use in groups that will auto-populate the prefix, so when it changes it still works.
So I was thinking about (for example) to use [IPv6_PREFIX], so it looks like:
[IPv6_PREFIX]1:241 / 128
To update the DNS Records with Cloudflare, I wrote a small script that does an update of the AAAA record using the API of them.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi @paderijk
Thanks for posting in our business forum.
paderijk wrote
@Clive_A Curious if there are any updates from the TP-Link side?
I was considering to utilize the OpenAPI, although got with the last update an alert that it will be deprecated on (at least) the OC200.
I got a new piece of information.
Dev and PM, later on, discussed that after work, the schedule is full for V5.15.X. Dev and PM think this would not be released until V5.16.X and its iterations.
It might not come around that soon.
- Copy Link
- Report Inappropriate Content
Hi @paderijk
Thanks for posting in our business forum.
Where will this prefix come from? WAN or LAN?
LAN can do it. ACL supports IPv6 LAN. The IPv6 Group will change to the WAN v6 prefix if the WAN prefix changes.
- Copy Link
- Report Inappropriate Content
Hi @Clive_A,
The IPv6 prefix will come from the WAN (via the ISP) and "pushed" to the LAN, the LAN is configured this way:
I indeed found the IPv6 group for ACLs applicable to the whole subnet (2001:c0ff:ee:5838::/64), but I have not found a solution whereby I can have an ACL for a specific IPv6 address, that takes into count a potential prefix change.
In my case I want to have one system (2001:c0ff:ee:5838::1:241/128) over SSH accessible from the Internet over SSH (TCP/22) and all the other systems that do offer SSH should not be accessible. So I currently have an ACL that blocks everything incoming and another one that only allows inbound SSH to that specific system.
The system Berrystone is the one that should be accessible from the Internet using SSH.
The IPv6 Group:IPv6 berrystone looks like:
So if the provider pushes a new prefix to me (for example) 2001:b4b4:aa:1234::/64, the IPv6 Group:IPv6 berrystone needs to be changed.
Hope I clarified the feature request more, if not, please let me know.
I looked if there was already something in place, but was not able to find it.
DISCLAIMER: The IPv6 prefixes showed are not the actual ones I have in use due to privacy.
- Copy Link
- Report Inappropriate Content
Hi @paderijk
Thanks for posting in our business forum.
paderijk wrote
Hi @Clive_A,
The IPv6 prefix will come from the WAN (via the ISP) and "pushed" to the LAN, the LAN is configured this way:
I indeed found the IPv6 group for ACLs applicable to the whole subnet (2001:c0ff:ee:5838::/64), but I have not found a solution whereby I can have an ACL for a specific IPv6 address, that takes into count a potential prefix change.
In my case I want to have one system (2001:c0ff:ee:5838::1:241/128) over SSH accessible from the Internet over SSH (TCP/22) and all the other systems that do offer SSH should not be accessible. So I currently have an ACL that blocks everything incoming and another one that only allows inbound SSH to that specific system.
The system Berrystone is the one that should be accessible from the Internet using SSH.
The IPv6 Group:IPv6 berrystone looks like:
So if the provider pushes a new prefix to me (for example) 2001:b4b4:aa:1234::/64, the IPv6 Group:IPv6 berrystone needs to be changed.
Hope I clarified the feature request more, if not, please let me know.
I looked if there was already something in place, but was not able to find it.
DISCLAIMER: The IPv6 prefixes showed are not the actual ones I have in use due to privacy.
Got you. Our dev also took a look at this request.
So, it does not seem to be a mainstream request yet. We will keep an eye on this request if they are more feedback on this, we let the PM take a look and evaluate this feature.
BTW, is this for the business environment or home? If this is for business, how many users do you have requesting this feature?
- Copy Link
- Report Inappropriate Content
This is in my home-lab (as professional IT Engineer, I would like to have good stuff).
Understand it's not a mainstream request, at my work at a big international company IPv6 is unfortunately not yet on the roadmap to be deployed in the Datacenters/Office LAN.
- Copy Link
- Report Inappropriate Content
Hi @paderijk
Thanks for posting in our business forum.
paderijk wrote
This is in my home-lab (as professional IT Engineer, I would like to have good stuff).
Understand it's not a mainstream request, at my work at a big international company IPv6 is unfortunately not yet on the roadmap to be deployed in the Datacenters/Office LAN.
Understand that. If others vote on this, our dev can pull this to the request pool for further evaluation.
- Copy Link
- Report Inappropriate Content
@paderijk I think i am running into the same problem. I'm getting a 56 prefix from my ISP. When i enter the whole IPv6 from my Device to a ACL Rule everything works fine. If the prefix changes i have to manually enter the new prefix in the group for the ACL. The IPv6 IP-Port-Group has the setting prefix set to 64. Shouldn't the ACL ignore the first 64 bits of the IPv6 then? It knows the lenghts of the might changing prefix. On the WAN side there is only one prefix, so it isnt relevant for safety in the ACL, right?
I am still learning about IPv6, but this problem prevents Omada from being usable for every private Server that should be available over the Internet if there are prefix changes.
Or am I missing something?
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
@Clive_A Curious if there are any updates from the TP-Link side?
I was considering to utilize the OpenAPI, although got with the last update an alert that it will be deprecated on (at least) the OC200.
- Copy Link
- Report Inappropriate Content
@paderijk That was exactly what i had in mind. But the only thing i came across was that tp-link is planning to change to openapi, not replacing it again...
- Copy Link
- Report Inappropriate Content
Hi @paderijk
Thanks for posting in our business forum.
paderijk wrote
@Clive_A Curious if there are any updates from the TP-Link side?
I was considering to utilize the OpenAPI, although got with the last update an alert that it will be deprecated on (at least) the OC200.
I submitted for a response last week and today. I have not received a comment regarding this feature so far.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 3
Views: 540
Replies: 12