Firewall rules bug?
-
Any reason your NAPt, you probably don't need to run it ?
-
@nogbadthebad said in Firewall rules bug?:
Any reason your NAPt, you probably don't need to run it ?
Yeah, I do, sadly, since IPv6 support is still broken badly at a carrier level.
Problems:
- ISP1: Cable - will give up to a /60, but that IP space isn't routable via ISP2, so stinks to DHCPv6 the space to LAN. Randomly stops giving out any delgations for weeks at a time, then works again.
- ISP2: DSL - only supports 6rd. Gives a single /64, no more. Also not routable via ISP1, so stinks to DHCPv6 the space to LAN
- HE tunnel 1 - works perfectly via ISP1. If I allocate the from the /48 I'm given for that tunnel, on LAN, works like a charm
- HE tunnel 2 - works perfectly via ISP2. If I allocate the from the /48 I'm given for that tunnel, on LAN, works like a charm
Solution:
- ULA space to LAN subnets (all 10 of them) then NPt into the /48's given for both tunnels, a /64 at a time.
Result:
- IPv6 functionality across both carriers.
If there's a better solution, I'm all ears.
https://redmine.pfsense.org/issues/4881
https://redmine.pfsense.org/issues/7712 -
@dlasher said in Firewall rules bug?:
@nogbadthebad said in Firewall rules bug?:
Any reason your NAPt, you probably don't need to run it ?
Yeah, I do, sadly, since IPv6 support is still broken badly at a carrier level.
Problems:
ISP1: Cable - will give up to a /60, but that IP space isn't routable via ISP2, so stinks to DHCPv6 the space to LAN. Randomly stops giving out any delgations for weeks at a time, then works again.
ISP2: DSL - only supports 6rd. Gives a single /64, no more. Also not routable via ISP1, so stinks to DHCPv6 the space to LAN
HE tunnel 1 - works perfectly via ISP1. If I allocate the from the /48 I'm given for that tunnel, on LAN, works like a charm
HE tunnel 2 - works perfectly via ISP2. If I allocate the from the /48 I'm given for that tunnel, on LAN, works like a charmSolution:
- ULA space to LAN subnets (all 10 of them) then NPt into the /48's given for both tunnels.
Result:
- IPv6 functionality across both carriers.
If there's a better solution, I'm all ears.
Ah that explains it :)
-
I think I found the problem, but I don't know the cause.
binat on $HURRICANETUNNELCA inet6 from to any -> 2001:xxx:xxxx:20::/64 binat on $HURRICANETUNNELCA inet6 from any to 2001:xxx:xxxx:20::/64 -> binat on $HURRICANETUNNELWA inet6 from to any -> 2001:xxx:xxxx:20::/64 binat on $HURRICANETUNNELWA inet6 from any to 2001:xxx:xxxx:20::/64 ->I'm guessing the "FROM" in lines 1 & 3 shouldn't be empty. The config in the UI isn't empty, either initially, or when I go back to edit the NPt rule.
Looks like a bug of some sort to me. How/where does one go about submitting a bug report?
EDIT: Answered my own question: https://redmine.pfsense.org/issues/8575
-
What exactly do you have configured in the GUI?
-
@jimp said in Firewall rules bug?:
What exactly do you have configured in the GUI?
Here''s one of them:
Disabled: [ ] Interface: HURRICANETUNNELWA Internal IPv6 Prefix [ ] Not Address: fabc::20:: /64 DestinationIPv6 Prefix [ ] Not Address: 2001:470:xxx:20:: /64 Description: NPt via HE WA tunnelWriting this up, I may have found one problem.
fabc::20:: -- breaks fabc:20:: -- doesn't breakSo perhaps it's a parse error when the IPv6 address is formatted incorrectly.
-
Could be, since
::can only appear once in a valid IPv6 address. That input should be rejected. -
Yeah it was a validation problem. GIGO. I added some frontend and backend validation.
-
@jimp said in Firewall rules bug?:
Yeah it was a validation problem. GIGO. I added some frontend and backend validation.
Thank you!
-
@jimp said in Firewall rules bug?:
Yeah it was a validation problem. GIGO. I added some frontend and backend validation.
Put those changes in by hand, and it does parse the above case correctly, throws a red
The following input errors were detected: The specified source address is not a valid IPv6 prefixperfect!
