Project

General

Profile

Actions

Bug #8273

open

IPv6 GRE tunnel over PPPoE fails on startup

Added by Wagner Sartori Junior almost 7 years ago. Updated about 2 years ago.

Status:
Confirmed
Priority:
Normal
Category:
Interfaces
Target version:
Start date:
01/11/2018
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Plus-Next
Release Notes:
Affected Version:
2.4.x
Affected Architecture:

Description

I have a XS4ALL FTTH pppoe connection that provides IPv6. IPv6 works perfectly, however GRE doesn't during initialization.

My PPPoE interface configuration have:
  • Request a IPv6 prefix/information through the IPv4 connectivity link
  • Request only an IPv6 prefix
  • DHCPv6 Prefix Delegation size: /48
  • Do not allow PD/Address release

LAN interface track PPPoE with a prefix ID I have chosen.

I created an IPv6 GRE tunnel on my LAN interface (to use the LAN address).

After pfsense is up, I have (note the lack of the tunnel line):

gre2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1374
    options=80000<LINKSTATE>
    inet6 fd7c:d51:b33e:efd5::12a --> fd7c:d51:b33e:efd5::129  prefixlen 128 
    inet6 fe80::ae1f:6bff:fe00:25c0%gre2 prefixlen 64 scopeid 0x12 
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    groups: gre 

My manual workaround is to go to the GRE interface on the web interface, edit and save. Everything starts working fine after that:

gre2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1374
    options=80000<LINKSTATE>
    tunnel inet6 2001:?:?::5 --> 2001:?:?::2
    inet6 fd7c:d51:b33e:efd5::12a --> fd7c:d51:b33e:efd5::129  prefixlen 128 
    inet6 fe80::ae1f:6bff:fe00:25c0%gre2 prefixlen 64 scopeid 0x12 
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    groups: gre 

Actions #1

Updated by Jim Thompson almost 7 years ago

  • Assignee set to Jim Pingle
Actions #2

Updated by Jim Pingle almost 7 years ago

  • Assignee deleted (Jim Pingle)
  • Target version changed from 2.4.3 to 2.4.4

I don't have a means to test IPv6 over PPPoE, but I tried this with DHCPv6 with LAN set to track and the same behavior happens there. The tunnel line with the external addresses is not in ifconfig at boot time.

Looking at the logs, this appears to be due to the tracked LAN address being empty when the first GRE pass is done:

Jan 22 10:42:12 clara php-cgi: rc.bootup: The command '/sbin/ifconfig gre0 inet6 tunnel  '2001:db8:1:deb0::1'' returned exit code '1', the output was 'ifconfig: 'tunnel' requires 2 arguments'

The argument shown there is the remote endpoint, the local endpoint is missing.

The code is doing things in the proper order. The track interface is setup before the GRE interface is attempted. It could be a timing issue, but if that's the case there may not be a good way around that other than attempting to (re)configure interfaces like GRE which depend on the tracked address when it appears.

I don't see any easy fix for this at the moment, any changes to interface configuration timing in that area will need more time/testing than we'll have before 2.4.3 needs to be out.

Actions #3

Updated by Wagner Sartori Junior over 6 years ago

As we're not having traction here, is there a way to manually trigger the GRE interface restart from the command line (emulate clicking SAVE on GRE interface configuration) ?

I will add something to CRON.

Actions #4

Updated by Mickaël FALCK over 6 years ago

I've stumbled onto a similar problem in my unrelenting quest to get IPv6 to work (but in DHCPv6+PD on WAN + VIP): the script doesn't know the local endpoint because the virtual IP hasn't been initialized yet.

I've (shamefully) worked it around by installing the "shellcmd" package and adding the following command:

  • Command: ifconfig gre1 inet6 tunnel <LOCAL_ENDPOINT> <REMOTE_ENDPOINT>
  • Shellcmd type: shellcmd

Of course, make sure to replace LOCAL/REMOTE_ENDPOINT with the IPv6 addresses you need.
Hopefully this will help you out.

Actions #5

Updated by Anonymous over 6 years ago

  • Target version changed from 2.4.4 to 48
Actions #6

Updated by Jim Pingle over 5 years ago

  • Target version changed from 48 to 2.5.0
Actions #7

Updated by Anonymous about 4 years ago

  • Assignee set to Renato Botelho
Actions #8

Updated by Anonymous about 4 years ago

  • Target version changed from 2.5.0 to CE-Next
Actions #9

Updated by Viktor Gurov almost 4 years ago

  • Status changed from New to Duplicate

Duplicate of #6507

Actions #10

Updated by Jim Pingle over 3 years ago

  • Target version deleted (CE-Next)
Actions #11

Updated by Steve Wheeler about 2 years ago

  • Status changed from Duplicate to Confirmed
  • Target version set to CE-Next
  • Plus Target Version set to Plus-Next

This is not a duplicate directly because in this scenario the parent interface is not a WAN directly but an internal interface that tracks the WAN for IPv6.

It looks like the only things that are restarted when the tracked interface changes are DNS and DHCPD. It should probably also restart tunnels, VPNs etc.

Actions

Also available in: Atom PDF