Bug #13846
open
IPv6 firewall rules using the interface network macro on a GIF/GRE interface do not respect the configured subnet mask
Added by Danilo Zrenjanin over 1 year ago.
Updated over 1 year ago.
Description
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"
- 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.
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.
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.
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
Updated by 
Updated by 
Updated by