I use the negative netmask notation on my IPv6 firewall rules to allow for prefix changes. It works fine for addresses such as:
1::1234/-48
Both luci and a firewall restart process fail to accept an address like:
1:208:9bff:feda:1234/-48
Bug?
This does not look like a valid IPv6 address to me (but I am not an expert). I would expect either 8 full stanzas or a double colon ellipsis, no?
2 Likes
It's documented here:
It says:
The negative netmask notation
/-64works only with OpenWrt firewall, equivalent for/::ffff:ffff:ffff:ffff.
1 Like
Oh, the negative netmask is a fine OpenWrt-ism, my concerns are about the initial IPv6 address in his non working example...
1:208:9bff:feda:1234
I thought you either need to specify all 8 groups or use ::to show where 'contractions' should be, the example had only 5 groups and no ::, which to me looks incorrect, but I do not claim to have mastered IPv6....
1 Like
The quoted address would be invalid. Although I'm surprised the OP had any success with 1::1234/-48, unless that was a typo and should have been ::1234/-48 .
1 Like
No it is not a typo and works perfectly. It gets translated to:
ip6 daddr & ::ffff:ffff:ffff:ffff:ffff == 1::1234 tcp dport 22 counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: ssh"
Do not assume that everyone is using a /64 prefix. I am using /48.
I wasn't. However, as far as I understand it, 1::1234 is equivalent to 0001:0000:0000:0000:0000:0000:0000:1234 which falls within reserved address space. I'm not surprised that you could add it to the firewall (as I doubt it's been programmed to verify against allocated address space), but I am surprised there's any routable traffic that would match the rule.
I think this expands to:
0001:0000:0000:0000:0000:0000:0000:1234
this looks like a valid IPv6 address (probably an address with interface-local scope given the leading "1:"). Interface identifiers are 64 bit, but a local network can slice and dice them as it sees fit, whether upstream router will bother with prefix length > 64bit is a different question... smaller than /64 prefixes are obviously just fine 
Having thought on this a little more, it's not even about whether it could be routed or not (although if it can't be routed the rest is a bit of a moot point). An ADD operation such as the one quoted above will always produce an outcome where the first 3 octets (hextets/segments/chunks/groups?) are 0000:0000:0000, which makes sense because we essentially want to remove the network prefix so we're only matching against the host address portion.
But that does make it impossible for any address to match if the result you're looking for is an address with anything other than a 0 in those first 3 octets (such as 1::1234). So while the firewall may accept it as a valid address there will never be (or shouldn't be) any packets that match the rule and get allowed through.
There is no reason to have a /48 on one interface. You are delegated a /48 in order to have 65.536 /64 networks, not to assign it all on one interface.
1 Like
Does everyone agree this isn’t a valid IPv6 address?
4 Likes
I think so...
With negative prefix it is a valid end part. E.g. assigning a static address in the local, inside prefix at least /48
But it is not a valid whole address.
See also
Based on that, it might need to start with ::
1 Like
You are correct, 1:208:9bff:feda:1234 is an invalid IPv6 notation. Correcting this will likely fix the issue.
1 Like
I'm pretty sure it just needs to be a full IPv6 address in order to be accepted. You can, for example, allow 0:0:0:1::1/-48 when adding a rule in LuCI.
Not if they leave 1 at the start of the address (as with their 'working' example). It won't throw an error but the rule will never be matched against making it a pointless addition to the firewall.
1 Like
LOL
They have to correct notation and use proper syntax/numbering in the firewall config.
Which would turn it into a well-formed IPv6 address using the zero 'compaction' method. I think the actual values in the masked out parts do not matter the existence of 'something' might, but as I said I am no IPv6 expert. I am a happy user of the negative netmask 'prefix-masking' approach to generate host-stable firewall rules that survive a prefix change...which is really sweet!
I simply picked the adress with the prefix current at the time I generated the rule and it just works since then.
To all those carrying on about what is a valid IPv6 address, PLEASE STOP. I suspect that you do not understand the issue at hand, which is how to represent the non-prefix bits of an IPv6 address in a firewall rule.
@krazeh If you look at the nft rule, you'll see the leading :: before the 5 groups of ffff. Traffic which comes to my prefix, plus the subprefix 1, plus the matching last 64 bits does indeed match.
Prefix = 48 bits
Subprefix = 16 bits
Remainder of Address = 64 bits
This is a confirmed working rule? You have working access to port 22 through the firewall to a host with an IPv6 address of xxxx:xxxx:xxxx:1::1234? With associated matches showing against the firewall rule you quoted earlier when traffic is passing through?