IPv6 is not working if gateway address is outside of provided /64 subnet.

qtlnx

I will gladly provide full access to my pfSense installation to anyone willing to figure out and/or report this problems upstream.

Given the fact that in DHCP6 mode default gateway and routing are discovered correctly a workaround could be added to pfSense UI to allow user to specify desired IPv6 address/mask even if DHCP6 mode is selected. I believe it is a simplest shot term solution.

BTW, in Linux there are two automatic modes: "Automatic" and "Automatic, DHCP6 only", pfSense offers only DHCP6.

athurdent

I don't get this. Why would one use a dynamic IP for a server? Why not go with something static that you can create DNS records for?
I had a KVM with the same wierd IPv6 config some time ago, so I just used the Standard Gateways Link-Local address as default gateway. Did not try that with pfSense though, the cheapo KVM tech specs were to small. :)

qtlnx

Please read the whole topic from the very beginning. Specifying DHCP6 will allow underlying FreeBSD networking to setup gateway and routing, I suppose via router advertisement, since there is no DHCP6 on the network. Manually setting up the same gateway and routing does not result in a a working IPv6. However if desired address is manually set via ifconfig after automatic routing discovery then everything is working but does not survive a reboot.

athurdent

So if there is no DHCPv6 server and you want it to be dynamic, try SLAAC. That normally chooses the LL address as Standard Gateway anyway.

qtlnx

SLAAC does not make a difference. Gateway is being set automatically but it is not reachable unless IPv6 address netmask made sufficiently wide, e.g. /64 to reach gateway. I don't know what is behind pfSense DHCP6 client settings but routing is working only if DHCP6 is enabled. I am sure there isn't any DHCP6 server on the subnet. I already specified all details in original post in IPv6 section. 2.3-BETA adds a route to the gateway but gateway is not reachable.

jimp

Are you certain that you used the exact same settings from when it worked using DHCP?

Given the previous difference you showed, DHCP apparently added a link route:

prefix_48::/48                    link#1                        U        vtnet0

That route was not present in your manual config output.

This command:

route add -inet6 -net prefix_48::/48 -interface vtnet0

doesn't produce the same type of route, which may account for the difference, though it should have made an entry, it doesn't show. When I test here for example I get```
prefix::/48 00:0c:29:xx:xx:xx US 0 1500 vmx1


Though it's possible that dhcp6c is able to set the route in some way that the user-space route command cannot. You can also try adding "-link" before "-interface" though it may not make a difference, it's worth trying.

qtlnx

I currently don't have access to original gateway /48, network /64 system, since it runs Linux right now.
Another system where gateway is on /64 but network /80 even DHCP6 mode does not help.
As you correctly noted the difference, a route command does not create "link#n" entries.
However I can deal with setting up wider subnet for now.

On another note, I am looking for FreeBSD command which on Linux looks like

ip neigh add proxy [ipv6_address] dev eth0

ndp manual page http://www.freebsd.org/cgi/man.cgi?query=ndp&sektion=8 is somewhat cryptic.

qtlnx

Going back to original topic - it looks like discrepancy between gateway and subnet among VPS providers is pretty common.
Here is another case:
https://clients.liteserver.nl/knowledgebase.php?action=displayarticle&id=2

JorgeOliveira

Hello,

Have you tried going to:
System > Routing > Gateways > WAN_DHCP6 (default) > Edit (pencil icon) > Advanced Options

Then check "Use non-local gateway through interface specific route." and save.

It should work if you do that.

Regards,
Jorge M. Oliveira

qtlnx

@JorgeOliveira:

Hello,

Have you tried going to:
System > Routing > Gateways > WAN_DHCP6 (default) > Edit (pencil icon) > Advanced Options

Then check "Use non-local gateway through interface specific route." and save.

Of course I did. I was told to do in one of the responses to my original posting https://forum.pfsense.org/index.php?topic=106392.0 and upgraded to latest BETA specifically for this purpose.