Firewall rules bug?

[NogBadTheBad]

Any reason your NAPt, you probably don't need to run it ?

[dlasher]

@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

[NogBadTheBad]

@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 charm

Solution:

• 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 :)

[dlasher]

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

[jimp]

What exactly do you have configured in the GUI?

[dlasher]

@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 tunnel

Writing this up, I may have found one problem.

fabc::20:: -- breaks
fabc:20:: -- doesn't break

So perhaps it's a parse error when the IPv6 address is formatted incorrectly.

[jimp]

Could be, since :: can only appear once in a valid IPv6 address. That input should be rejected.

[jimp]

Yeah it was a validation problem. GIGO. I added some frontend and backend validation.

[dlasher]

@jimp said in Firewall rules bug?:

Yeah it was a validation problem. GIGO. I added some frontend and backend validation.

Thank you!

[dlasher]

@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 prefix

perfect!