Bug #13846


IPv6 firewall rules using the interface network macro on a GIF/GRE interface do not respect the configured subnet mask

Added by Danilo Zrenjanin 3 months ago. Updated 2 months ago.

Rules / NAT
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


Steps to reproduce:

1. Define GRE tunnel with a remote peer and define IPv6 Local and Remote Tunnel addresses
2. Assign the GRE interface
3. Define a rule on the GRE interface, Address Family IPv6, Protocol ICMP, Source GRE net, and Destination Any
4. Under Diagnostics/Command Prompt execute cat /tmp/rules.debug and locate the generated rule defined in step 3.
5. The system generated the rule using the Local IPv6 tunnel address instead of the tunnel network.

pass  in  quick  on $GRE reply-to ( gre0 fc01::2 ) inet6 proto ipv6-icmp  from fc01::1/128 to any ridentifier 1673087868 keep state label "USER_RULE" label "id:1673087868" 
Actions #1

Updated by Jim Pingle 2 months ago

  • Subject changed from IPv6 rule generated for GRE network on a GRE interface doesn't have the correct subnet mask to IPv6 firewall rules using the interface network macro on a GIF/GRE interface do not respect the configured subnet mask
  • Category changed from Interfaces to Rules / NAT
  • Target version deleted (2.7.0)
  • Plus Target Version deleted (Plus-Next)

That is expected based on how the interfaces are configured in the OS.

It's a point-to-point link so the underlying interface configured with "A -> B" and a 128 length prefix, there is no interface "network" on a point-to-point link, so it ignores what the user chooses in the GIF/GRE config. It used to respect this in the past but IIRC it was changed as that caused a problem at some point.

There is an argument to be made that for firewall rules it should read the mask from the underlying GIF/GRE config and not what is present on the interface, but that would require a bit of re-engineering of the code around how it forms the macros since it currently can't do that.

I don't see this being a release blocker since it's not new behavior and there is a simple workaround by hardcoding the network in the rule or an alias if needed.

Actions #2

Updated by Ross Tajvar 2 months ago

Why is the IPv4 behavior different from the IPv6 behavior? From my perspective, IPv4 is "working" and IPv6 is "broken". IMO they should behave the same.

Actions #3

Updated by Danilo Zrenjanin 2 months ago

Since there is an option to define the subnet manually, the option 'Interface net' when the interface is GRE or GIF type can be grayed or removed.

Actions #4

Updated by Ross Tajvar 2 months ago

You can do that, but that removes functionality. It would be better to make it work as expected. And again, IPv4 is working as expected already, so greying out the option would make it stop working.


Also available in: Atom PDF