IPv6 GRE tunnel over PPPoE fails on startup
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
#2 Updated by Jim Pingle 3 months ago
- Assignee deleted (
- 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.