Bug #6506
closed
IPv6 static routes omit interface scope of link-local gateways
0%
Description
When getting an address assigned from a DHCPv6 Server pfSense automatically creates a gateway to monitor using the link-local address which is fine in general. Dpinger fails to start monitoring the gateway because of the the socket issue described in #6505, but that's the the main point of this issue. The %interface section is omitted when a static route gets pushed to the system and an additional route (link-local to interface) is added. But the main problem when you've duplicate link-local addresses due to vlans:
Example:
- Interface: vtnet0
- Gateway (vlan 41) fe80::5054:ff:fee0:a429%vtnet0_vlan41
- Gateway (vlan 42) fe80::5054:ff:fee0:a429%vtnet0_vlan42
Network:
.-----------. .-----------.
__ _ | pfsense | VLAN Trunk 41,42 | gateway | ---->
[__]|=| ----> | | -----------------> | |
/::/|_| | | | | ---->
'-----------' '-----------'
On both nodes (in my case virtual pfsense boxes to test with) both ports are a single port with vlan trunks on it. Therefore the interface has a single mac and the same link-local address is generated on different subinterfaces (aka vlan interfaces). This is totally fine if pfsense would omit the link-local-interface in the gateway ipv6 address.
Routing Table:
Internet6: Destination Gateway Flags Netif Expire default fe80::5054:ff:fee0:a429%vtnet0_vlan41 UGS vtnet0_v ::1 link#5 UH lo0 fc00::21 fe80::5054:ff:fee0:a429 UGHS vtnet0_v [...]
This route should include the %vtnet0_vlan41 interface identifier other the route will fail and you can't push it to the right uplink interface
Workaround
Disable the automatically created Gateways and manually create the gateway using the correct link-local%interface notation.
Version tested
I'm using pfsense 2.3.1_5
Updated by Chris Buechler over 8 years ago
Daniel Hoffend wrote:
when a static route gets pushed to the system
What do you mean by "pushed to", that via DHCP option, or?
Updated by Daniel Hoffend over 8 years ago
No, with pushed to the system i mean: When the static route that you've added using the WebUI is getting added to the kernel routing table using route commands.
When a static routes gets added to the routing table using an IPv6 link-local next-hop address that is missing the interface part it's possible that the route can't work. In 99 of the cases you've a host route for the link-local address to the corresponding interface, then a static route will work fine. But in the moment you've duplicate link-local addresses in different interfaces you can get into trouble.
A duplicate link-local next-hop address can happen when a router advertises the same link-local address (because it's based on the physical hw addr) on multiple vlan subinterfaces.
My idea:
When adding routing entries to the routing table using a link-local address as next-hop always include the %interface part in the next-hop/gateway part.
Updated by Chris Buechler over 8 years ago
- Subject changed from static ipv6 route misses %interface of automatic link-local gateways to IPv6 static routes omit interface scope of link-local gateways
- Status changed from New to Confirmed
- Affected Version changed from 2.3 to All
confirmed, thanks
Updated by Chris Buechler over 8 years ago
- Status changed from Confirmed to Feedback
- Assignee set to Chris Buechler
- Target version set to 2.3.1-p6
fix pushed to always include interface scope on static routes to a link local v6 gateway IP.
Updated by Daniel Hoffend over 8 years ago
Manuelly applied the change to my system.inc file. Seems to work. The static routes using a dynamic IPv6 WAN Gateway now includes the interface scope. Only sad that the dpinger has a problem with too long ipv6 socket names. But that's a different ticket (#6505)
Updated by Chris Buechler over 8 years ago
- Target version changed from 2.3.1-p6 to 2.3.2