Alias Native not combining ASN enumeration with custom list in same rule
-
OK, I think I found the core problem: partial PEBKAC
Where I was looking for the custom CIDR blocks was in "Firewall / pfBlockerNG / Log Browser" not in "Diagnostics / Tables".
The custom CIDRs are correctly listed in the latter in a correctly sorted order.
BUT they ARE in the "Firewall / pfBlockerNG / Log Browser" at the END of the file, partially sorted. The Custom list is sorted but just appended to the main file.
Completely unexpected behavior.
I was unaware of the "Diagnostics / Table" section and didn't expect a difference in content.
-
@lohphat said in Alias Native not combining ASN enumeration with custom list in same rule:
I was unaware of the Diagnostics / Table" section .....
Don't feel bad, I was also not aware of the Diagnostics/Table section either, but THANKS to @johnpoz , I learned something new today as well.
-
Shouldn't the CIDR aggregation merge these 2607:f8b0:4000:: CIDRs into the main 2607:f8b0::/32 network?
From: PfB_ASN_List_v6 Table
2607:f8b0::/32 2607:f8b0:4000::/48 2607:f8b0:4001::/48 2607:f8b0:4002::/48 2607:f8b0:4003::/48 2607:f8b0:4004::/48 2607:f8b0:4005::/48 2607:f8b0:4006::/48 2607:f8b0:4007::/48 2607:f8b0:4008::/48 2607:f8b0:4009::/48 2607:f8b0:400a::/48 2607:f8b0:400b::/48 2607:f8b0:400c::/48 2607:f8b0:400d::/48 2607:f8b0:400e::/48 2607:f8b0:400f::/48 2607:f8b0:4010::/48 2607:f8b0:4011::/48 2607:f8b0:4012::/48 2607:f8b0:4013::/48 2607:f8b0:4014::/48 2607:f8b0:4015::/48 2607:f8b0:4016::/48 2607:f8b0:480e::/48 2607:f8b0:480f::/48 2607:fb90:c150::/48 -
@lohphat said in Alias Native not combining ASN enumeration with custom list in same rule:
2607:f8b0::/32
yeah you would think.. @BBcan177 would know ;) I don't really load any IPv6 addresses into pfblocker at all.
-
@johnpoz Given that aggregation stats are given in the logs when IPv4 ASNs are downloaded but not IPv6 ASNs, it may be that aggregation only applies to IPv4 at this time. The settings descriptions need updating to reflect this apparent limitation.
IPv4 update log:
[ AS16509_v4 ] Downloading update [ 10/15/22 19:24:44 ] . Downloading ASN: 16509... completed . completed .. Aggregation Stats: ------------------ Original Final ------------------ 7329 2902 ------------------ [ AS13335_v4 ] Downloading update [ 10/15/22 19:24:50 ] . Downloading ASN: 13335... completed . completed .. Aggregation Stats: ------------------ Original Final ------------------ 1606 361 ------------------ [ AS15169_v4 ] Downloading update [ 10/15/22 19:24:52 ] . Downloading ASN: 15169... completed . completed .. Aggregation Stats: ------------------ Original Final ------------------ 818 84 ------------------ [ ASN_List_custom_v4 ] Reload [ 10/15/22 19:24:54 ] . completed ..IPv6 update log:
[ AS8075_v6 ] Downloading update . Downloading ASN: 8075... completed . completed .. [ AS13335_v6 ] Downloading update [ 10/15/22 19:24:55 ] . Downloading ASN: 13335... completed . completed .. [ AS15169_v6 ] Downloading update [ 10/15/22 19:24:57 ] . Downloading ASN: 15169... completed . completed .. [ AS16509_v6 ] Downloading update [ 10/15/22 19:24:58 ] . Downloading ASN: 16509... completed . completed .. [ ASN_List_custom_v6 ] Reload [ 10/15/22 19:25:33 ] . completed ..Note the lack of "Aggregation Stats" in the IPv6 logs.
-
@lohphat said in Alias Native not combining ASN enumeration with custom list in same rule:
Note the lack of "Aggregation Stats" in the IPv6 logs.
There are probably a lot of things to do with IPv6 in this package that are not implemented yet because IPv6 is still fairly new and not that widely used. I wouldn't expect those updates to be done for another year or so given that the maintainer of this package, @BBcan177 , has limited time right now to devote to this package. He is quite busy working other things.
I would say to just post any issues you find with IPv6 and he will work them as time permits. -
@jdeloach I understand. But if simple updates to UI text to set expectations and clarify before features are implemented, that seems a reasonable course.
I'm from the world of software development so I do understand the pressures, but small incremental changes can make a big difference.
IPv6 is here and if you network can handle it, the large players are using it (e.g. YouTube content), and some countries ONLY have IPv6 addressing. We have to get used to it sooner than later.
-
@jdeloach said in Alias Native not combining ASN enumeration with custom list in same rule:
IPv6 is still fairly new and not that widely used.
Not sure if 20 some years counts as fairly new ;) Arin made their first assignments of IPv6 back in 1999. But not that widely used I would agree with.. We all get it, its the future.. But currently to be honest, there is zero reason to have it, other than a learning tool.
Name 1 actual resource that would require you to have it? Just one, been asking that question for years here, and have yet to get an answer..
I am all for moving towards it, and I have been playing with it for 13 years + but have yet to find and actual requirement that says yeah I have to have that.. My isp currently doesn't even provide it. I get my ipv6 from a HE tunnel.
Sure in some parts of the world - hey that is what the ISP gives you.. And then they convert your ispv6 to an ipv4 on their network via say 464XLAT. And with the billions of phones on the globe yeah ipv4 isn't going to cut it.. Now think about cars all being connected as we move towards self driving, etc. IPv4 can't really handle that.. But, still - what actual main public resource requires IPv6? Name one?? Name one game that requires you to have IPv6 to play on your consoles.. And that really should be a driving force for people demanding IPv6 from their ISPs, etc.
We are like 20 years in, and ISPs still can not get it right.. Hand your users a /48 prefix, assign that to them.. So it doesn't change every other day.. Let them do with that what they will.. Its not like there is not enough already assigned IPv6 space to give like everyone on the planet 4000 some /48's each. Or a /56 or even a /60 for gosh sake.. And the amount of available IPv6 is just the very tip of the iceberg of the total available space, etc. But ISP continue to hand out single /64s that change when the wind blows, etc.
If you are new to IPv6, be ready for a learning curve, be ready for issues and problems - Its just much easier to just not use it, unless your stuck with it - ie your in some isp that won't actually give you a public IPv4, and you want to have inbound unsolicited traffic. And then just hope your users that want to access your resource actually have IPv6, or are smart enough to setup a IPv6 tunnel, etc.
Sorry IPv6 is one of those topics that just drives me nuts, especially after a few cocktails ;) I want it to move forward, I want it to be done right, but I have been banging my head against a wall for like 10 years at work, and have yet to see progress - and I work for a major player.. And have seen no real progress other than in the mobile device space. Finally a year or so ago I got to assign a /32 from arin for use in some car related project - that has not gone anywhere really.
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.03 | Lab VMs 2.7.2, 24.03 -
@johnpoz I agree. I owe you some cocktails for all the sh!t I've stirred up anyway.
I view IPv6 akin to saying please and thank you -- you don't NEED to use them, but it makes the world a better place if you do. It's not about either/or IPv4 vs IPv6 it's AND.
I've been beating on IPv6 for years too but I'm lucky my ISP supports it and pissed that FiOS STILL doesn't in many markets (but that's changing).
Local nets and IoT will be using IPv4 NAT (RCT1918) for the foreseeable future, but like any new thing, the more we encourage its use, the sooner well get there.
More than 40% of users hitting Google are IPv6 clients. It's no longer a "niche":
And in the US and EU , the adoption rate is more than 50%:
SG-3100 24.03-RELEASE (ARM) | Avahi (2.2_5) | ntopng (5.6.0) | openvpn-client-export (1.9.3) | pfBlockerNG-devel (3.2.0_20) | System_Patches (2.2.11_15)
-
@johnpoz said in Alias Native not combining ASN enumeration with custom list in same rule:
But, still - what actual main public resource requires IPv6? Name one?? Name one game that requires you to have IPv6 to play on your consoles..
I can't but many people will have to use IPv6 to vpn into their own homes in the near future around my place.
And pfSense is not doing a great job regarding dynamic IPv6, so the people in this forum might be last ones, who will be using IPv6. I reduced it to one host at home.
dhcpd is almost eol so I hope we get better dynamic IPv6 support in the future?! -
@lohphat said in Alias Native not combining ASN enumeration with custom list in same rule:
but like any new thing, the more we encourage its use
No I don't buy this to be honest.. A user or 2, or even 10,000 of them isn't going to move IPv6 along any faster ;) If your isp hands you out some shitty deployment of IPv6 you using it or not using it isn't going to slow or speed up the adoption of IPv6 at a global scale.
Now if enough users called their isp and said hey we need IPv6.. Maybe they might think about adding it, but they can also ask you why you need it - what resource are you trying to get to that you can not ;)
And they might up your cost, because hey switching to and deploying IPv6 sure isn't free ;)
-
@johnpoz This is a protocol issue transparent to the user community.
It no different than you asking your airline which tires they use on their aircraft or what they fill them with. The decision to use a particular vendor and to use nitrogen instead of air was not a user issue, but one of operations to improve reliability. The users weren't consulted.
The decision of IPv6 functionality is not at the user level no more than a user deciding what the flag bits are in a TCP packet or enet frame.
Users don't deal with the IETF or even need to know they exist, but WE at the operational level do.
IPv6 is a thing. QUIC is a thing. Infrastructure vendors need to accommodate progress or stand aside with their excuses so that others can meet the market changes.
-
@lohphat said in Alias Native not combining ASN enumeration with custom list in same rule:
IPv6 is a thing. QUIC is a thing
While I agree, vendors do need to support current protocols, etc. but doesn't mean the users have to leverage them if they see no benefit.
A user not using IPv6 is not going to slow down progress was my point.. Me and the local ipv6 cheerleader bump heads over this quite a bit.. My advice to a user that is having issues with IPv6, and doesn't want to put in the time to learn about all the differences, and how to properly manage and or even have to deal with a isp nonsense deployment of it.. The simple solution is just put it away for another day.. And you will save yourself a lot of grief.. The "requirement" of having IPv6 is years away, years! Now it could come quickly at some point in the future as when they finally get to the top of the hill and start rolling down the other side.. To me IPv6 is actually here when you have a major player say, hey on XYZ date, even if 10-15 years in the future will be turning off IPv4 access..
Have you heard of any such announcements? Until that happens, IPv6 is just an option that you do not need to use if you do not want too. Until there is actually something that requires you to have IPv6 - it is a choice.. Users making the choice to use or not use is not going to slow down or speed up its global adoption.. Quic is an option, Some site that says hey you can use quic to connect to me, nothing saying I have to allow or use that.. Unless they turn off other normal means of access. Quic has been around for a long time as well, don't really see it taking off like a rocket either ;)
We are going to be stuck in this middle ground for a really long time, where mobile devices, things that require large number of IPs will leverage IPv6, this just frees up IPv4 space for other users where it not cost effective to transition to IPv6..
To be honest there is a very large grey market for selling IPv4 space.. We had sold off a portion of our IPv4 space that we were not using, and really had no plans of ever using for a nice chunk of change.. And now those locked away IPv4 can be used by people that have need/use of them, its a win win for al involved.
-
@johnpoz The either/or of IPv4 vs Ipv6 is a false dichotomy you're imposing on yourself where it doesn't exist from external pressure. Not even the IETF is proposing a sundown for IPv4 but they ARE pushing for dual stack interoperability ASAP.
The better throughput due to improved congestion handling is a big one. Most of my Google/YouTube traffic (the bulk of my traffic is streaming media) and now, some of my gaming traffic is IPv6. Most of my mobile traffic is IPv6.
The "we don't have to because IPv4 is not going away" mantra is only a form of procrastination and ignoring the market trend. We're already past 50% adoption in the developed world. Get your IPv6 skills and infrastructure in the game as soon as you can so that you're comfortable with it and prepared so that it's not a mystery.
As an infrastructure player, pfSense needs to stay in the game. Fine, make your personal choices for your use case, but from this point forward, if an infrastructure vendor isn't IPv6 compliant, it's off my vendor list. I'm not going to make capital investments in hobbled gear who can't support a 20 year ratified protocol with over 50% adoption.
