Bug #9192
open
PPPoE daemon selects wrong interface
0%
Description
I'm experiencing a strange issue where the pppoe daemon selects/reports the wrong interface for establishing an IPv6 connection.
Background:
1x Intel i350-T4V2 card
Mac addresses of PHY:
xx:xx:xx:xx:xx:04 (WAN)
xx:xx:xx:xx:xx:05 (LAN)
xx:xx:xx:xx:xx:06 (OPT1)
xx:xx:xx:xx:xx:07 (OPT2)
During bootup, manually disconnecting/reconnecting pppoe session results in the unexpected behaviour. Also, sometimes when the ISP drops the pppoe session for load balancing purposes the pppoe daemon will sometimes select the improper interface. Sometimes the :04 interfaces is chosen and other times the :05. This behaviour wasn't present in pfSense 2.4.2.
The result of this instability is that sometimes the WAN wont receive and IPv6 address and thus no outbound/inbound IPv6 connectivity is possible.
Files
Related issues
Updated by Kristopher Kolpin almost 6 years ago
Note: One would expect the xx:xx:xx:xx:xx:04 interface to be chosen every time.
Updated by Jim Pingle almost 6 years ago
- Priority changed from High to Normal
- Target version deleted (
2.4.4-p2)
Updated by Kristopher Kolpin almost 6 years ago
It seems this was an issue that about 5 years ago that has now resurfaced.
https://forum.netgate.com/topic/59789/ipv6-over-pppoe-wrong-default-gateway
This is definitely a very high defect and should be triaged accordingly.
PPPoE authentication is still the preferred method for DSL and GPON connections for the majority of Canada. Can't speak for the U.S. though.
Updated by James Tandy over 5 years ago
Confirmed on 2.4.4-p2, when using a pppoe connection, with an isp who supports native ipv4 and ipv6, multiple times per day I am now required to delete my default route, and add a new default route using the %pppoe1 interface.
Original netstat -rn output:
Internet6:
Destination Gateway Flags Netif Expire
default fe80::f2f7:55ff:fe0c:5700%re1 UGS re1
This is the incorrect state that is applied multiple times per day.
Using the above gateway:
PING6 2a02:13a0:a006:1::1 --> 2a00:1450:4009:810::200e
^C
--- google.com ping6 statistics ---
7 packets transmitted, 0 packets received, 100.0% packet loss
To fix this, I do
route del -inet6 default
route add -inet6 default fe80::f2f7:55ff:fe0c:5700%pppoe1
And suddenly we have ipv6 connectivity again
PING6 2a02:13a0:a006:1::1 --> 2a00:1450:4009:810::200e
16 bytes from 2a00:1450:4009:810::200e, icmp_seq=0 hlim=57 time=8.511 ms
16 bytes from 2a00:1450:4009:810::200e, icmp_seq=1 hlim=57 time=7.992 ms
16 bytes from 2a00:1450:4009:810::200e, icmp_seq=2 hlim=57 time=8.129 ms
^C
--- google.com ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 7.992/8.211/8.511/0.220 ms
This is a high priority bug, as its a very bad experience using the internet when you have to wait for anything v6 to timeout before it falls back to v4.
Local clients are being handed ips in my static /56 ssigned from isp, with each local vlan using a seperate /64.
Locally v6 works fine, its jus tthe pfsense losing any route to send v6 traffic to the outside world.
Updated by Jim Pingle over 5 years ago
- Category changed from Interfaces to PPP Interfaces
Updated by Jim Pingle almost 4 years ago
- Has duplicate Bug #11505: PPPoE daemon selects wrong interface added