GRE/GIF IPv6 tunnel netmask ignored on interface configuration

[franco]

Thanks for the great input from both of you.

@franco @Maurice Then what shall we do with that? An additional drop-down box to select between point-to-point and broadcast? Or force migrate everybody to /128 and let them change it later? Or make an empty remote address set the broadcast mode?

Aha! So according to the theory voiced here we test if the remote net fits the local address. If it does apply prefixlen as given, if not apply 128 as before? Should both be working according to you and no new knobs and migrations necessary. I like how we could solve this locally in the GRE configuration code.


Cheers,
Franco

[vnxme]

@Maurice Thank you for explaining the 'dynamic gateway policy'.

I'm not sure that I can properly test this edge case as it barely suits my setup. I have an IPv6-in-IPv4 GRE tunnel between two OpnSense virtual machines, one of which is a VPS. The VPS has a native dual-stack connection and a routed /56 prefix. On the other side a default IPv6 route is set via the VPS and I use active gateway monitoring to switch to another upstream gateway. If I created a default route where the next-hop is the interface itself, I wouldn't be able to monitor my connection status and switch gateways automatically.

That would be my choice. Shouldn't brake any existing setups, doesn't require migration code an seems intuitive.

Making an empty remote address set the broadcast mode likely requires changes to both interfaces.inc and GIF/GRE configuration pages. Besides, we should take into account that the 'dynamic' gateway configuration might be broken and it even shouldn't be allowed on such an interface.

Aha! So according to the theory voiced here we test if the remote net fits the local address. If it does apply prefixlen as given, if not apply 128 as before? Should both be working according to you and no new knobs and migrations necessary. I like how we could solve this locally in the GRE configuration code.

@franco, like your suggestion! Let me know if you expect me to prepare a pull request or test your patch.

[franco]

Patch is here: https://github.com/opnsense/core/commit/d69ff4a16a89

I've also added https://github.com/opnsense/core/commit/889420b652b and it needs both...

# opnsense-patch 889420b652b d69ff4a16a89

So if this works I'm not so sure about this anymore although it seems more true to the original implementation:

https://github.com/opnsense/core/commit/111a2560fb7


Cheers,
Franco

[vnxme]

@franco Great, will test shortly. Shouldn't we also make a change to the GIF part similar to https://github.com/opnsense/core/commit/d69ff4a16a89 ?

[franco]

Yes, we will keep GIF/GRE implementation as close as possible. But GRE test first. :)


Cheers,
Franco

[vnxme]

Tested the patch on 2 machines, switched between /128 and /126 and vice versa. Works fine in both modes, no errors in log. BGP also works fine when /126 is configured.

[franco]

Yay, awesome :)

[Maurice]

Neat solution! Before releasing it, I'd suggest thoroughly testing whether switching from this ...

Code Select Expand

ifconfig gif0 inet6 2001:db8::2 2001:db8::1 prefixlen 128

... to this ...

Code Select Expand

ifconfig gif0 inet6 2001:db8::2 prefixlen 64

... has any weird side effects. Probably not, but you never know. This is the typical tunnelbroker.net setup.

Cheers
Maurice

[franco]

Yep, will do.

What Ad mentioned regarding this is for VTI we seem to just calculate a matching subnet size between local and remote which also works fine to get rid of the hardcoded prefixlen 128 .. that means omitting the selected remote net on the GUI altogether, but I'm not sure if we should be going this far here.


Cheers,
Franco

[Maurice]

That could result in a very large subnet (e. g. if local and remote address are not in the same /64). I don't think we should ditch the /128 mode entirely.

Cheers
Maurice

[franco]

Yup, we could consider /64 to be the breaking point of that method, but since we have a net size selection the current approach seems more reasonable and we could also add a validation to the page so we can get rid of implicit prefixlen 128 in the future (it continues to work but use is discouraged unless specifically configured).


Cheers,
Franco