Hi,
I have HE Tunnel Broker configured (gif tunnel). I noticed two problems.
1. Disabling interface (assigned to gif tunnel) doesn't have an effect, routes are still there and traffic is routed through this interface. (gateway is disabled and not shown, but still works)
2. Re-enabling interface doesn't work correctly. Gateway is still "disabled" and from GUI there is no way to enable it, it never goes up. I need to reboot to get to valid state.
I want the ability to enable/disable interface, because I don't want to use it all the time. But currently I cannot do that apparently.
Thanks,
Kacper
So which version it is then?
As per design devices like GIF are stand-alone. Assignments can be used but are not required. That also means disabling assigned interfaces won't disable devices like you imply.
Cheers,
Franco
Quote from: franco on June 16, 2022, 01:48:51 PMSo which version it is then?
Version: 22.1.8_1
Quote from: franco on June 16, 2022, 01:48:51 PMThat also means disabling assigned interfaces won't disable devices like you imply.
Ok, if it by design like that, you can discard point 1. But still 2. seems like a bug, no?
So, I cannot disable gif tunnel without removing it? I can block traffic in firewall on given interface, but was intuitive for me to just disable it.
If you save from GIF device settings it starts working again, right?
Cheers,
Franco
Indeed. If I save from "Interfaces: Other Types: GIF" gateway is enabled, but shows as offline, monitoring is not working (monitor ip is correct), I also need to go to "System: Gateways: Single" and save there also and then it works.
Sure, thanks for confirming. I'll fix this tomorrow, but it's likely available in 22.7 as there are some other changes required that are not yet ready for release.
Cheers,
Franco
Quote from: franco on June 16, 2022, 01:48:51 PMAs per design devices like GIF are stand-alone. Assignments can be used but are not required. That also means disabling assigned interfaces won't disable devices like you imply.
Ok, back to this then. I would like to understand. You said that "assignments are not required" and "disabling assigned interfaces won't disable devices like you imply"... ok. But in fact I don't care about the device itself. It can be active or not.
Shouldn't disabling gateway or setting it as not upstream remove the default route for this gateway (and therefore not route through GIF)? I don't see how it related to GIF, but disabling assigned interface disables the gateway and at this point why the routes are still there? I don't see how this is by design? How one handle multiple GIF tunnels if associated gateways/interfaces doesn't affect routing? Do you see my point? If not, let me know, I can rephrase my questions.
That's a lot of questions without technical execution and testing against latest development code.
For one the change discussed was added as https://github.com/opnsense/core/commit/7aecb367c
Maybe it's working as intended already, but I don't know since I don't have steps to reporduce... only bad current behaviour that could have all sorts of side effects of the things you describe. Namely:
> Shouldn't disabling gateway or setting it as not upstream remove the default route for this gateway (and therefore not route through GIF)?
Yes it should. It even has to, but at the same time you need to set another gateway as new default.
> but disabling assigned interface disables the gateway and at this point why the routes are still there?
Again, could be a side effect of the current behaviour.
> I don't see how this is by design?
I assume this is rhetorical.
> How one handle multiple GIF tunnels if associated gateways/interfaces doesn't affect routing?
This makes no sense when talking about "default routes" in the first place. Only one can be default anyway.
> Do you see my point?
I can see there are multiple points with partial structure.
> If not, let me know, I can rephrase my questions.
Well, let's go one by one. First we would ideally be able to confirm the fix works and then work up to the next issue like e.g. disabling a gateway / setting another default route.
Cheers,
Franco
QuoteFirst we would ideally be able to confirm the fix works
Can I test it without much hassle? Can I do opnsense-patch on them? Not sure they would apply cleanly? You mentioned before that some other changes are required, so probably I need to wait for 22.7?
Do you have a VM? You can switch to development release and test there as it includes the discussed change. Patching is too difficult but as long as you can snapshot the development version is worth a try.
Cheers,
Franco
Oh, I just lost whole finished post when trying to send it, because it log me out. I guess we go again, probably shorter version this time and less coherent...
Indeed I can work with snapshots. I didn't know it is such painless to move to dev version. So I moved to 22.7.a_413 (7fdc163bf).
Issue 1. from OP is fixed, enabling interface seems to work as expected.
But there are still issues. Sorry for being chaotic before I wasn't sure how it should work exactly.
Disabling gateway does not adjust routes correctly. To recap I have gif0 device assigned to WANv6 interface that is used as upstream gateway for IPv6.
I will be disabling WANv6 interface which also controls associated gateway.
netstat -6rWn | grep gif0$
1. Nominal case, after reboot (WANv6 interface enabled)
Destination Gateway Flags Nhop# Mtu Netif
default <ipv6> UGS 13 1480 gif0
<ipv6> link#10 UH 10 1480 gif0
fe80::%gif0/64 link#10 U 12 1480 gif0
2a. After disabling gateway only (no change to 1)
Destination Gateway Flags Nhop# Mtu Netif
default <ipv6> UGS 13 1480 gif0
<ipv6> link#10 UH 10 1480 gif0
fe80::%gif0/64 link#10 U 12 1480 gif0
2b. After disabling WANv6 interface
Destination Gateway Flags Nhop# Mtu Netif
default <ipv6> UGS 13 1480 gif0
fe80::%gif0/64 link#10 U 12 1480 gif0
3. After reboot (WANv6 interface disabled or only gateway disabled)
Destination Gateway Flags Nhop# Mtu Netif
<ipv6> link#10 UH 9 1280 gif0
fe80::%gif0/64 link#10 U 11 1280 gif0
4. After enabling WANv6 interface
Destination Gateway Flags Nhop# Mtu Netif
default <ipv6> UGS 11 1480 gif0
<ipv6> link#10 UH 8 1480 gif0
fe80::%gif0/64 link#10 U 10 1480 gif0
As we can see it is not consistent. 1 and 4 is expected. In 2 and 3 case I would expect there are no routes. Traffic is still routed through this gateway while I would expect there is no default route for IPv6. After disabling WANv6 interface firewall rules for this interface does not apply to traffic that is still routed there, but this is side effect. Also note that after reboot in case 3 MTU is set to default 1280, again side effect, because if device is associated to interface while this interface is disabled I would expect no routes created.
I hope I didn't forget anything, let me know if more detailed info is needed.
Thanks,
Kacper
Any news about this? Do we want to fix this before 22.7?
I'm afraid the code is full of side effects in this regard.
If GIF is created on top of WAN interface, it adheres to its presence of WAN address. If WAN is disabled host route cannot be created (UH), otherwise it sticks around if you disable WAN after it being up.
Now this wouldn't be so bad if during WAN disable it would bring down the GIF interfaces on top of it as well, but there is no way to "deconfigure" a GIF interface anywhere in the code so that's out of the current scope as well.
As for gateways that is similar: there isn't any "deconfigure", just a disable flag which skips configuration and if the IPv6 default route is the only one it just sticks around...
I'm happy to work on this further (22.1 -> 22.7 has made larger steps towards cleanups), but we need to pick the battles wisely in order to make operational progress in the long term. I'm not sure where to start here to be honest. ;(
Cheers,
Franco