121
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
122
24.7 Production Series / Re: IPv6 prefix delegation not working with 24.7.1-.3
« on: August 30, 2024, 02:41:07 pm »
Now, I spotted this line...
https://github.com/opnsense/src/commit/164bfe67604#diff-efb487014794d10f6658bf2252b545ad5d64469bd0bc9dbde25dfab3a9b0ab9cR6488
Not so entirely sure about UDP being unrelated to ICMP any more.
(My brain is dead, someone else please read the surrounding code.)
https://github.com/opnsense/src/commit/164bfe67604#diff-efb487014794d10f6658bf2252b545ad5d64469bd0bc9dbde25dfab3a9b0ab9cR6488
Not so entirely sure about UDP being unrelated to ICMP any more.
(My brain is dead, someone else please read the surrounding code.)
123
24.7 Production Series / Re: 2 dhcpv6 in LAN
« on: August 30, 2024, 02:25:37 pm »Must be the idea of "private addresses" from IPv4 experience that misleads people to try to use ULA.
Probably, plus the stupid ISPs and changing prefixes. Making ULA less preferred than IPv4 in the stack somehow improved things here, at least using ULA does not break IPv4 on the way - https://datatracker.ietf.org/doc/html/rfc5220#section-2.2.2
124
24.7 Production Series / Re: IPv6 prefix delegation not working with 24.7.1-.3
« on: August 30, 2024, 02:19:31 pm »
The thing is, it shouldn't be blocked even with that horrible bogonsv6 stuff enabled, because the DHCPv6 rule has prio=1, while the bogonsv6 rule has prio=5, the packets will normally get matched with the higher rule and the latter will not apply (quick rule).
That said, I'd disable it altogether and never look at that checkbox again.
That said, I'd disable it altogether and never look at that checkbox again.
125
24.7 Production Series / Re: 2 dhcpv6 in LAN
« on: August 30, 2024, 01:30:55 pm »
Well, OK. It's working, just being unused. 
126
24.7 Production Series / Re: IPv6 prefix delegation not working with 24.7.1-.3
« on: August 30, 2024, 01:13:28 pm »* one or two times when trying to find out what goes wrong, I saw blocked packet in the firewall log (live view) with dst port 546. Weird here was, that there was no label (describing which rule caused the block) and it was not stable reproducable
Hmmm, sounds very much like the kernel mess to me. (Also considering 24.7.1 being completely broken for you and working much better in .[23])
127
24.7 Production Series / Re: IPv6 prefix delegation not working with 24.7.1-.3
« on: August 30, 2024, 01:04:07 pm »there must be another bug beside dhcp6c in 24.7.1 preventing PD from working (because I used 24.7.1 without success) fixed in .2 or .3.
Yes, sure. This one: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
Tens of mandays wasted on that nonsense with "stateful" ICMPv6 already.
128
24.7 Production Series / Re: 2 dhcpv6 in LAN
« on: August 30, 2024, 01:00:09 pm »may i recommend reading into: https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual-stack-networks/
I already linked to that indirectly, and expanded on that with a later post offering a practical demo.
So yes, IOW - overall this is a nice exercise in getting dual-stack working that will not be used anyway.
129
24.7 Production Series / Re: 2 dhcpv6 in LAN
« on: August 30, 2024, 12:28:37 pm »
If you run the normal routing diagnostic (such as netstat -rn) on the client and the router, you'll quickly see why. (And no, running one DHCP server per prefix is certainly not the solution.)
130
24.7 Production Series / Re: 2 dhcpv6 in LAN
« on: August 30, 2024, 11:37:09 am »There is no way to have some sort of private ipv6 address that can be routed between this public one (safe if ISP change the allocated prefix)
See, that's what I meant by "describe your goal here". I assume you are looking for this:
https://docs.opnsense.org/manual/nptv6.html
And be sure to tick "full help" and carefully read the notes there.
With that said, a sane ISP that does NOT change allocated prefixes is highly preferred.
More references:
- https://github.com/opnsense/core/issues/5284
131
24.7 Production Series / Re: 2 dhcpv6 in LAN
« on: August 30, 2024, 11:20:05 am »
Uhm... what I am suggesting is to ditch the entire ULA idea unless you have a very specific reason for using it. (I want to play with pings is not one).
SLAAC + RA/RDNSS happily coexists with the DHCPv6 "design afterthought" if you insist on using it.
P.S. And do NOT run multiple DHCP servers unless configured for failover (which Windows DHCP server does not support with IPv6). Yeah, there's not a trace of something that's completely outside of the configured DHCP server scope, or what's stateless and not configured by DHCPv6 for that matter.)
SLAAC + RA/RDNSS happily coexists with the DHCPv6 "design afterthought" if you insist on using it.
Quote
but not trace of that lease in the opnsense DHCPV6)
P.S. And do NOT run multiple DHCP servers unless configured for failover (which Windows DHCP server does not support with IPv6). Yeah, there's not a trace of something that's completely outside of the configured DHCP server scope, or what's stateless and not configured by DHCPv6 for that matter.)
132
24.7 Production Series / Re: 2 dhcpv6 in LAN
« on: August 30, 2024, 11:09:08 am »
But - why? Use the GUA prefix on Windows DHCPv6 server. I mean, this whole thing is seriously pointless. To illustrate this, run the command on some Windows box:
50 is localhost, 40 is GUA. That 35 is IPv4 (well, IPv4 to IPv6 mapped addresses). Still WAY higher precedence than ULA (fc00::7).
Now, with that, try to ping some dual-stack hostname from that fd07:: and see for yourself what's gonna be used.
Code: [Select]
netsh interface ipv6 show prefixpolicies
Querying active state...
Precedence Label Prefix
---------- ----- --------------------------------
50 0 ::1/128
40 1 ::/0
35 4 ::ffff:0:0/96
30 2 2002::/16
5 5 2001::/32
3 13 fc00::/7
1 11 fec0::/10
1 12 3ffe::/16
1 3 ::/96
50 is localhost, 40 is GUA. That 35 is IPv4 (well, IPv4 to IPv6 mapped addresses). Still WAY higher precedence than ULA (fc00::7).
Now, with that, try to ping some dual-stack hostname from that fd07:: and see for yourself what's gonna be used.
133
24.7 Production Series / Re: 2 dhcpv6 in LAN
« on: August 30, 2024, 10:53:15 am »
Technically, SLAAC is not a "lease".
https://www.networkacademy.io/ccna/ipv6/stateless-address-autoconfiguration-slaac
It is doable but completely pointless at the same time. IPv4 will be preferred to ULA. Almost everywhere.
Perhaps describe your goal here instead of drafting solutions (for potentially non-existent problems).
https://www.networkacademy.io/ccna/ipv6/stateless-address-autoconfiguration-slaac
It is doable but completely pointless at the same time. IPv4 will be preferred to ULA. Almost everywhere.
Perhaps describe your goal here instead of drafting solutions (for potentially non-existent problems).
134
24.7 Production Series / Re: 2 dhcpv6 in LAN
« on: August 30, 2024, 10:42:22 am »I need to have an external ip from my ISP (it's currently working)
And 1 inside the lan
But that "external IP" is also "inside LAN".
I would strongly suggest reading this thread: https://forum.opnsense.org/index.php?topic=33902.0
Finally, the inventor of DHCPv6 should be tortured daily.
135
24.7 Production Series / Re: Pings through WAN interface not working (broken in 24.7.1-.3)
« on: August 30, 2024, 09:09:37 am »
Ugh, not again... 
Also, "nice" radio silence on the upstream bug. Seems even the actionable item is not actionable any more.
I'd suggest an ultimate solution for the entire "security improvement" if the SA is indeed involved here. I don't expect things to move any further until this mess is dumped on + users in the project run by the involved upstream actors - and then their user base starts complaining about downstream issues.
Also, "nice" radio silence on the upstream bug. Seems even the actionable item is not actionable any more. I'd suggest an ultimate solution for the entire "security improvement" if the SA is indeed involved here. I don't expect things to move any further until this mess is dumped on + users in the project run by the involved upstream actors - and then their user base starts complaining about downstream issues.