DHCPv6 on WAN works but pf uses SLAAC address

[keyser]

I have a problem I can't quite figure out. I'm testing a new ISP with pfSense IPv6.
The ISP uses DHCPv6 to assign an address to the user (my pfsense in this case), and then uses DHCPv6-PD to assign a /48 that they route to the DHCPv6 assigned address on WAN.

The ISP assigns a DHVPv6/128 address to my pfSense, and my pfsense gets and assigns the IP to WAN. I also get the PD and can use it.

However: My pfSense also use SLAAC to assign an IPv6 address on WAN, and it insists on using that address as a source address for all automatic operations instead of the address assigned by DHCPv6 (Which I asked pfsense to use on WAN).

The ISP does not reply to traffic sourced from the SLAAC IP at all, They require all traffic to originate from the DHCPv6/128 address for them to pass it on.

When i specifically use WAN as source in DIAGNOSTICS -> PING/TRACEROUTE the entire Internet is available. But If I use AUTO as source it uses the SLAAC address, and nothing is available.

The IPv6 gateway is learned by RA and is a LinkLocal fe80 address (which is common, and works fine).

How can I get pfSense to use the DHCPv6 assigned address as source instead of the SLAAC address. I thought that asking WAN to use DHCPv6 would do that implicitly

[keyser]

@keyser As a brief follow up I assume the issue is my ISP that sends a faulty RA with the A flag set even though they blackhole traffic from the selfassigned SLAAC address. I found this post with other users experiencing what seems like the same issue:

https://forum.opnsense.org/index.php?topic=31317.0

Is there any ways to have pfSense ignore the A flag and NOT assign itself a SLAAC address?

[JKnott]

@keyser said in DHCPv6 on WAN works but pf uses SLAAC address:

The ISP does not reply to traffic sourced from the SLAAC IP at all, They require all traffic to originate from the DHCPv6/128 address for them to pass it on.

That's nonsense. I also have a /128 address, as well as a /56 prefix. I have no problem using any address in that /56. In fact, that /128 isn't even used, unless I use it to connect my VPN. With IPv6, routing is often done using the link local address.

I use SLAAC on my LAN. Don't use DHCPv6, unless you have a need to, as Android devices won't work with it. You can thank some genius at Google for that.

Also, your ISP has no way of knowing if the address was provided with SLAAC or DHCPv6. It's simply an address within your prefix.

[keyser]

@JKnott You are misunderstanding. For pfSense itself to reach anything on the internet, the traffic needs to be sourced from the WAN assigned DHCPv6 address. If if is sourced from the WAN self assigned SLAAC address, they do not route/pass the traffic on (likely an ACL preventing anything but their assigned address or the assigned PD to pass).

Clients on my LAN using addresses from the Prefix delegation works fine and is routed as expected. So the issue here is really only pfsense itself - it uses the SLAAC address as source instead of the DHCP6 assigned WAN address. This causes pfSense itself to be unable to reach any DNS servers, NTP servers and what not on IPv6.

[keyser]

@JKnott A little Update: I tried in the CLI to have pfsense prefer the DHCP6 assigned address, and then things work as I would expect. Obviously not a good solution as I would have to do that every time at reboot or full IPv6 Renewal on WAN.

BUT: Another issue has turned up. No DHCP Renewal or Rebinds completes successfully. pfSense continues to attempt Renew and later on rebind on WAN as intended in IPv6, but no replies are recieved. Eventually both the WAN DHCP6 assigned address and the Prefix delegation is timed out, and full DHCP discover process is needed to get the address and PD back.
I did a packet capture and all Renew and Rebind packets are transmitted to the multicast fe02:1:2 address from the link local fe80 address. That probably explains why no replies are recieved.
I would have expected those to be a unicast from the DHCP6 assigned address to the DHCPv6 server directly (or is that IPv6 thinking only?)

Any ideas?

[JKnott]

@keyser

I just ran Packet Capture for a few minutes and didn't see any RAs. I also pinged Google and it came from my WAN address.

Can you do a Packet Capture of your WAN interface, filtering on ICMP6 and post the capture file here? Also, try ping6 to something like google.com, while the capture is running.

[dem]

@keyser said in DHCPv6 on WAN works but pf uses SLAAC address:

When i specifically use WAN as source in DIAGNOSTICS -> PING/TRACEROUTE the entire Internet is available. But If I use AUTO as source it uses the SLAAC address, and nothing is available.

Oddly I have the opposite behavior. A ping using Auto uses the DHCPv6 address, but choosing WAN uses the SLAAC address. Fortunately for me both work.

A ping from the command line uses the DHCPv6 address. However pfSense shows the SLAAC address in the Web UI and uses the SLAAC address in firewall rules. But dpinger uses the DHCPv6 address.

@JKnott said in DHCPv6 on WAN works but pf uses SLAAC address:

I use SLAAC on my LAN. Don't use DHCPv6, unless you have a need to, as Android devices won't work with it. You can thank some genius at Google for that.

By default pfSense runs DHCPv6 and RA in Assisted mode on LAN so non-Android clients can get both kinds of addresses.

[keyser]

@JKnott Yeah, I need to do some more diagnosing, but it works right now because of my CLI command to prefer the DHCP6 assigned address.. (works apart from the renew/rebind that is...)

I'll need some time without users on my net to do some proper testing. But I did do a packet capture, and the ICMP6 flow looked normal. When my pfSense transmitted packet from the SLAAC GUA address to the fe80 default gateway, they were simply blackholed. No ICMP6 packets saying anything. When I make pfSense transmit with the DHCP6 address instead things work and respond as expected.

I have a sneaky suspicion this issue is related to DPINGER. With Gateway monitor disabled on IPv6 the Slaac issues remains. But if I enable Gateway monitor (but pinging a GUA instead of the actual GW fe80 address), then pfSense seems to start using my DHCP6 assigned address as default (and stops assigning a SLAAC address to its WAN interface).

[keyser]

@dem said in DHCPv6 on WAN works but pf uses SLAAC address:

@JKnott said in DHCPv6 on WAN works but pf uses SLAAC address:

I use SLAAC on my LAN. Don't use DHCPv6, unless you have a need to, as Android devices won't work with it. You can thank some genius at Google for that.

By default pfSense runs DHCPv6 and RA in Assisted mode on LAN so non-Android clients can get both kinds of addresses.

Yeah, the issue is WAN side only, so lets keep LAN side issues and specifically LAN side DHCPv6/RA konfiguration out of this thread. Any mention of DHCP6 and RA implies packets to and from WAN on the ISP link going forward :-)

[JKnott]

@keyser said in DHCPv6 on WAN works but pf uses SLAAC address:

I'll need some time without users on my net to do some proper testing. But I did do a packet capture, and the ICMP6 flow looked normal. When my pfSense transmitted packet from the SLAAC GUA address to the fe80 default gateway, they were simply blackholed.

When pinging link local addresses, you have to specify the interface with the -I option. You could also try capturing the full DHCPv6 sequence and posting the file here.