Appears the problem was related to a secondary WAN interface we have configured in the firewall. As soon as that WAN interface was disabled, the GIF tunnel would work without the filtering disabled. When the secondary WAN interface was enabled again, the tunnel still worked, so probably some messed up routing.

@steveits OK, thanks. If I can ever get registered on Redmine, I'll file a bug report.

@gwabber No, you route the traffic, just as you do with your default gateway.

@r4ptor Your win dhcpdv6 client is working : [image: 1677233457673-467e835f-706e-4d56-9b18-38360a17e76c-image.png]

@tanya-0 I believe those decisions are made either from a performance standpoint (must be cheaper resource-wise to not having to handle network prefixes greater than half the address), a security standpoint (most pfsense subsystems, which are dependent on the specific implementation of the BSD kernel would IM ignorant O have to be re-written to change the long-standing in-code "assumptions" about the IPv6 netstack, which would introduce bugs and vulnerabilities that would take a lot of revisions to be ironed out and would reduce customer trust in the product) and a demand standpoint (not many of us, either pros like you, or enthusiasts like me) ask for that specific thing (I think).

Thanks for the hint. Maybe it could be related to my Post here

@defunct78 unfortunately that is not my issue. I have a IPv6 Gateway Group selected the same as before.

Thinking about it, it makes sense, that it is only working for the first entry because no router will make many connections from one. So to get this working better it would need a dialog like for port forwarding where the router can be instructed what to do for what port.

@lurick Seems to have been an issue with the probe I have. I setup a VM version of the probe on the same network as the physical probe, no issues after 48 hours and counting.

@bob-dig said in [solved] NPt doesn't let me do that, why?: I don't immediately update my DDNS-records. Are you talking about internal or external DNS? If internal, ULA is all you need for static addresses.

@bob-dig This is in Denmark, and the ISP is called Kviknet. I know My used settings at this time works with kviknet in other parts of the country (i have a friend using pfsense with kviknet), and more than One OPNsense uses them as Well. So what things could influence this and cause My dhcp6c Client to behave so irradically?

The Netgate 6100 interface on the fd04:2240::/48 segment has the following flags: nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> I did a bit of research and I think the following might solve the issue: ifconfig inet6 accept_rtadv It's a production setup so I'm reluctant to try it. Does adding the accept_rtadv make sense?

@jknott # netstat -r Routing tables (output omitted) Internet6: Destination Gateway Flags Netif Expire localhost link#10 UH lo0 tunnel814714.tunne link#17 UH gif0 tunnel814714-pt.tu link#17 UHS lo0 fe80::%mvneta1/64 link#2 U mvneta1 fe80::208:a2ff:fe0 link#2 UHS lo0 fe80::%mvneta2/64 link#8 U mvneta2 fe80::208:a2ff:fe0 link#8 UHS lo0 fe80::%lo0/64 link#10 U lo0 fe80::1%lo0 link#10 UHS lo0 fe80::%mvneta1.10/ link#13 U mvneta1. fe80::208:a2ff:fe0 link#13 UHS lo0 fe80::%mvneta1.7/6 link#14 U mvneta1. fe80::208:a2ff:fe0 link#14 UHS lo0 fe80::%mvneta1.8/6 link#15 U mvneta1. fe80::208:a2ff:fe0 link#15 UHS lo0 fe80::%ovpns1/64 link#16 U ovpns1 fe80::208:a2ff:fe0 link#16 UHS lo0 fe80::%gif0/64 link#17 U gif0 fe80::208:a2ff:fe0 link#17 UHS lo0 Looks like there is a tunnel setup. not sure how to connect to the other side without using the software and in the cli. The goal here is Dual stacking ipv4/6.

@steve1515 Sometimes the solution is to start from scratch, as you may have set something and not realized it.

First, let me note that I'm assuming your IOT devices are on their own network here. If they're on the same network as your other LAN devices, what you want won't be possible. If both WAN 1 and WAN 2 providers have IPv6 available, you would set your IOT network to track the IPv6 prefix of WAN 1, and your other network(s) to track the prefix of WAN 2. pfSense should then be able to route the IPv6 traffic accordingly. If WAN 1 provider doesn't provide IPv6 service then I would disable IPv6 on your IOT network. You wouldn't be able to use WAN 2's IPv6 prefix to provide IPv6 to IOT, then have it route through WAN 1. Your WAN 1 provider wouldn't be able to route traffic from WAN 2's IPv6 addresses.

@johnpoz I'm only using 5 of my 256 /64s. However, I think people have learned a lot of bad habits, with having to conserve IPv4 address space. The only place where a smaller prefix makes sense is with a point to point link, where a /127 is all you need.