Problem with 6rd feature and reported prefix

saivert

Currently the 6rd feature in PFSense 2.6 reports the prefix length of the WAN interface as the same as the prefix on the wan_stf interface which is actually doing the tunneling.

For reference are outputs from ifconfig (with obfuscated addresses):

[2.6.0-RELEASE][admin@saivertrouter.saivert.lan]/var/run: ifconfig wan_stf
wan_stf: flags=4041<UP,RUNNING,LINK2> metric 0 mtu 1480
	inet6 xxxx:xxxx:xxxx:xxxx:: prefixlen 30
	groups: stf
	v4net x.x.x.x/32 -> tv4br y.y.y.y
	nd6 options=101<PERFORMNUD,NO_DAD>

As you can see the wan_stf interface is setup with a prefix length of 30 which is correct.

[2.6.0-RELEASE][admin@saivertrouter.saivert.lan]/var/run: ifconfig igb0
igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	description: WAN
	options=8120b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER>
	ether 00:0e:c4:d4:40:15
	inet6 fe80::zzzz:zzzz:zzzz:zzzz%igb0 prefixlen 64 scopeid 0x1
	inet x.x.x.x netmask 0xfffff000 broadcast 255.255.255.255
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

As you can see the igb0 (WAN) interface has prefix length of 64 which is correct. There is no public IPv6 assigned to this interface as the IPv6 connection is not actually terminated on this interface which it would be if using native IPv6.

Yet PFsense pretends that the assigned WAN interface does double duty as IPv6 termination point and thus reports the same prefix as used on the wan_stf interface which is incorrect.

This also causes problems because now the WAN interface as reported via internal configuration APIs occupies a whole /30 space and you cannot assign the other subnets to other interfaces otherwise you get an error:

The following input errors were detected:

Address xxxx:xxxx:xxxx:xxxx:: is already configured on this firewall. [ WAN (yyyy:yyyy:yyyy:yyyy::/30) ]

So I have to run a cron script to assign IPv6 address to my Wireguard interface for now to circumvent this issue.

I'm not sure how the internal mechanisms work here but it seems tunnel interfaces should be ignored when doing validation of input like this. wan_stf is an implementation detail only and is not actually occupying any address space.