Firewall rules bug?



  • version: 2.4.3_1
    Ipv4 connectivty: cable + dsl
    IPv6 connectivty: he.net tunnels

    I added a new tunnel, to start playing with NPt, and am seeing loads of the following errors in the UI now.

    @ 2018-06-14 08:56:33
    There were error(s) loading the rules: /tmp/rules.debug:191: syntax error - The line in question reads [191]: binat on $HURRICANETUNNELCA inet6 from to any -> 2001:xxx:xxxx:20::/64
    @ 2018-06-14 08:56:34
    There were error(s) loading the rules: /tmp/rules.debug:193: syntax error - The line in question reads [193]: binat on $HURRICANETUNNELCA inet6 from to any -> 2001:xxx:xxxx:20::/64
    @ 2018-06-14 08:57:27
    There were error(s) loading the rules: /tmp/rules.debug:193: syntax error - The line in question reads [193]: binat on $HURRICANETUNNELCA inet6 from to any -> 2001:xxx:xxxx:20::/64
    @ 2018-06-14 08:57:28
    There were error(s) loading the rules: /tmp/rules.debug:195: syntax error - The line in question reads [195]: binat on $HURRICANETUNNELCA inet6 from to any -> 2001:xxx:xxxx:20::/64
    @ 2018-06-14 08:57:47
    There were error(s) loading the rules: /tmp/rules.debug:195: syntax error - The line in question reads [195]: binat on $HURRICANETUNNELCA inet6 from to any -> 2001:xxx:xxxx:20::/64
    @ 2018-06-14 08:57:48
    

    (yes, I replaced the inner prefixes with xxx:xxxx)

    entry from /tmp/rules.debug looks like:

    binat on $HURRICANETUNNELCA inet6 from  to any -> 2001:xxx:xxxx:20::/64
    binat on $HURRICANETUNNELCA inet6 from any to 2001:xxx:xxxx:20::/64 -> 
    

    HURRICANETUNNELCA is assigned an interface of GIF 64.62.134.13

    Based on : https://www.netgate.com/docs/pfsense/interfaces/using-ipv6-with-a-tunnel-broker.html - all of that looks correct, so I'm trying to figure out what is breaking.

    Ideas?

    kind of like : https://www.reddit.com/r/PFSENSE/comments/6oa0ol/ipv6_multi_wan_centurylink_comcast/


  • Galactic Empire

    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


  • Galactic Empire

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



  • 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


  • Rebel Alliance Developer Netgate

    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 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.


  • Rebel Alliance Developer Netgate

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


  • Rebel Alliance Developer Netgate

    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 prefix
    

    perfect!


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy