The act of toggling "Disable Ingress filtering" in GIF makes DS-Lite work

[Vacyyyy]

So I managed to setup DS-Lite using OPNsense from the GUI. However after a reboot IPv4 doesn't work. Going into the GUI and toggling (not specifically enabling or disabling, that doesn't matter) "Disable Ingress filtering" immediately restores IPv4 internet access. I hope one of you can help me with this.

Here is my DS-Lite setup (if you find anything else wrong with it, please tell me):

LAN Interface: Static IPv4: 192.168.1.1
WAN Interface: DHCP; DHCPv6 (no hinting etc. configured yet)
DSLITE GIF Tunnel: Parent interface: WAN; GIF remote address: ISP's AFTR; GIF tunnel local address: 192.0.0.2; GIF tunnel remote address: 192.0.0.1/29; Disable Ingress filtering: the opposite to what it was before reboot/reload.
Interface Assignments: DSLITE (opt1): gif0 (DSLITE).

[franco]

Is this really about "Disable Ingress filtering" or just some sort of "applying" a configuration instead? "LINK2" is set correctly as far as I can see.

It would help to have an ifconfig from the working and non-working case. Also try to only toggle a blank save to see if that works as well.


Cheers,
Franco

[Maurice]

I'm pretty sure this isn't related to any particular setting. Try just saving the GIF settings without changing anything, that most likely fixes it, too.

I've made the same observation when I was still using DS-Lite. The root cause was that after a reboot, the GIF interface gets configured before the WAN interface acquires an IPv6 address. The GIF interface needs to be reconfigured once the parent interface acquires an address (or the address changes), but this doesn't seem to happen automatically. Simply saving the GIF settings reconfigures it.

@franco Sorry for not opening an issue when I observed this, had other things on my mind back then. And now I'm no longer using DS-Lite, switched to 464XLAT instead.

Cheers
Maurice

[franco]

Ok, I think I know what's going on. To confirm after boot there should be an error here:

# opnsense-log | grep ifconfig


Cheers,
Franco

[Vacyyyy]

That's actually what I guessed too. However I did it when someone else had pulled WAN out, so it didn't change anything and I forgot to test it again. Either way, is this a thing to fix in OPNsense or for a script? The log gives "The command: '/sbin/ifconfig 'gif0' [...] the output was: ifconfig: error in parsing address string: name does not resolve" So yeah, probably what y'all suggested.

[franco]

AFTR gateway is a freaking host name? So the ISP forces you to use their servers? Or is this done for your convenience? Snipping the relevant bits from the report is problematic.


Cheers,
Franco

[Maurice]

Franco, that's just how DS-Lite works. From RFC 6334:

To provide the conveyance of the configuration information, a single DHCPv6 option is used, expressing the AFTR's Fully Qualified Domain Name (FQDN) to the B4 element.

¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

You don't have to use the ISP's DNS servers. The AFTR FQDNs are typically resolvable via public DNS.

That's not really relevant here though, because OPNsense doesn't allow configuring a GIF tunnel with an FQDN anyway (input validation prevents that).

I can reactivate my old DS-Lite setup later today and provide some more details.

Cheers
Maurice

[franco]

Okay, learned something today.

Issue with host names/FQDN is that ifconfig will take them and translate them on the spot and never change them again... if the entry is static that is better, but in order to resolve the WAN needs to be established.

Now DS-Lite has IPv6 as primary, which doesn't reload GIF tunnels like IPv4 does:

https://github.com/opnsense/core/blob/a8c348cfa437b918228a5a3ac0cb4e8eb538047e/src/etc/rc.newwanip#L98-L101

rc.newwanipv6 needs the same, but maybe we can actually split the gif into inet and inet6 iteration.. Reloading on IPv4 will probably fail a IPv6 tunnelled GIF.


Cheers,
Franco

[Maurice]

gif section of config.xml:

Code: [Select]

<gif>
  <tunnel-local-addr>192.0.0.2</tunnel-local-addr>
  <tunnel-remote-addr>192.0.0.1</tunnel-remote-addr>
  <tunnel-remote-net>29</tunnel-remote-net>
  <remote-addr>2a02:8071:2000::4002</remote-addr>
  <descr>Vodafone West DS-Lite (Karlsruhe AFTR)</descr>
  <gifif>gif0</gifif>
  <if>wan</if>
  <ipaddr/>
</gif>
Error logged after reboot:

Code: [Select]

/usr/local/etc/rc.bootup: The command '/sbin/ifconfig 'gif0' inet6 tunnel '' '2a02:8071:2000::4002'' returned exit code '1', the output was 'ifconfig: error in parsing address string: Name does not resolve'
The local address is empty ('') because the WAN interface hasn't acquired a GUA yet. That's what triggers the "error in parsing address string".

The gif tunnel gets created, but doesn't have outer addresses:

Code: [Select]

# ifconfig gif0
gif0: flags=8011<UP,POINTOPOINT,MULTICAST> metric 0 mtu 1280
        options=80000<LINKSTATE>
        inet 192.0.0.2 --> 192.0.0.1 netmask 0xfffffff8
        groups: gif
        nd6 options=2b<PERFORMNUD,ACCEPT_RTADV,IFDISABLED,AUTO_LINKLOCAL>      
After a simple edit & save of the gif settings, the tunnel is correctly configured and running:

Code: [Select]

# ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
        description: WAN_4in6 (opt1)
        options=80000<LINKSTATE>
        tunnel inet6 2a02:8071:3123:4567::a --> 2a02:8071:2000::4002
        inet 192.0.0.2 --> 192.0.0.1 netmask 0xfffffff8
        groups: gif
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

Now DS-Lite has IPv6 as primary, which doesn't reload GIF tunnels like IPv4 does:

I suspected something like this, but didn't dig deeper back then.

Cheers
Maurice

[franco]

"" does not resolve is a strange error Ok so not a FQDN... the problem here again seems to be that if an FQDN were to be used for remote-addr we don't know if it's going to be IPv4 or IPv6, but from the code an FQDN is not allowed so let's assume this will not change.

I'll try to offer a patch today.


Cheers,
Franco

[franco]

https://github.com/opnsense/core/commit/315153a07

# opnsense-patch 315153a07

Applies cleanly to 23.7.3, but consider this a work in progress.


Cheers,
Franco

[franco]

Maurice, do you know if this part is even needed?

https://github.com/opnsense/core/blob/315153a07b71840b2ac8caea69e700c5621a0085/src/etc/inc/interfaces.inc#L664-L666

I always considered GIF and GRE to have feature parity but this is only done by GIF and I have no clue if this is actually needed (leaning towards "not needed" myself).


Cheers,
Franco

[franco]

I looked up the historic reason for this. The employed idea is clear but still no real world idea why...

https://github.com/pfsense/pfsense/commit/01a58d89dad


Cheers,
Franco

[Maurice]

# opnsense-patch 315153a07

Thanks, works nicely on my test VM! GIF tunnel is up & running after a reboot. Tested with DHCPv6 WAN and SLAAC WAN.

I think the host route for the GIF remote address is required in some multi WAN scenarios. When selecting a parent interface in the GIF settings, the expectation is that this interface will be used for routing the GIF packets. The static route makes sure this happens even if the selected parent interface is not the one which has the default gateway.

Cheers
Maurice

[franco]

It's just odd the GRE setup never did this. Normally GIF and GRE have feature parity. But let's keep it for now then.


Cheers,
Franco