-
-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancement/Feature request: Ability to whitelist IPv6 addresses and ranges #106
Comments
I am under the impression that skynet doesn't block over ipv6, am I wrong ? I think what you need is an enhancement request for skynet to support blocking over ipv6. |
You are probably correct though while googling for the answer, I came upon several posts alluding to skynet at least handling IPv6..? |
Interesting.. while skynet is running and loaded, maybe you should inspect the output of
That should give us some understanding on what skynet blocks over ipv6. BTW, I also would like to see such a feature available. |
Great point; there’s nothing! 👍🏽 |
@Adamm00 I guess this is more of a feature request for IPV6 firewall support. |
I've changed the title to reflect the nature of the issue - thanks jumpsmm7 :) |
@Adamm00 If you ever decide you would be fine with a pull request or collaborative work, I wouldn't mind helping port ipv6 support to skynet. Just say a word in support of the thought and I would be willing to work on it following your current scripting style of course. As we transition from the older AC router models, to the newer AX models, there is more support for making such a feature advantageous. |
I’ve thought about it in the past, my biggest issue being is there any real point to ipv6 blocking, addresses are so freely available that blacklisting starts to not make sense. I’m open to outside options on the matter. |
I believe all of the list that have a corresponding IPV6 blocklist are sources that have a known corresponding IPV4 address as well. So it is actually to ensure people are not able to access what they are already blocking on IPV4 over IPV6 instead. I know, I know, this goes back to the don't turn on IPV6 argument, but I actually have a block list with IPV6 address ranges in it. I aggregate all my blocked IP addresses using the python package called "aggregate6" just to ensure I am not blocking single IP'S that correspond to a netblock I am already blocking. This greatly reduces the size of my blocklists while ensuring I am getting more bang for my buck in blocking when using skynet. It won't be today, but at some point in the near future with time being permitted, I am going to sit down and look at the feasibility of coding ipv6 into skynet. It looks like it should be rather simple following the method you already have in place. Obviously some changes will be necessary with IPSET. I would actually have to divide the ip families as apart of the command arguments and include adequate regex parsers for parsing ipv6 feeds from ipv6 lists. Obviously, we would place a reasonable limit on the element size for the ipv6 ipset, I would say no bigger than the element size for the netblock ipset you already support for ipv4 ranges. 200,000 elements as oppose to the ipv4 single ip element of 500,000. I would say my ipv6 blocklist quantity is about 2/3'rds the size of my IPV4 (e.g. ipv6 ~ 200,000 to 300,000 where as ipv4 is 400,000 to 500,000). |
Brief Description Of Issue
Trying to whitelist an IPv6 range, I'm met with "[...] Is Not A Valid IP/Range".
IPv4 whitelisting works as expected.
Steps To Reproduce Issue
firewall whitelist range 2001:470:1:332::/64 "ShadowServer"
firewall whitelist range 2001:0470:0001:0332:0000:0000:0000:0000/64 "ShadowServer"
firewall whitelist range 2001:0470:0001:0332:0000:0000:0000:0001 "ShadowServer"
(Same behavior in amtm interface.)
Expected Behaviour
IPv6 address/range added to whitelist.
Output of ( sh /jffs/scripts/firewall debug info )
[] 2001:470:1:332::/64 Is Not A Valid IP/Range
[] 2001:0470:0001:0332:0000:0000:0000:0000/64 Is Not A Valid IP/Range
[*] 2001:0470:0001:0332:0000:0000:0000:0001 Is Not A Valid IP/Range
The text was updated successfully, but these errors were encountered: