@Bob-Dig That looks like it worked! Is there a limitation I should be aware of with how quickly those rules will update? I just don't want to leave an open hole in my firewall whenever my ISP drops the ball.

@JKnott said in Anyone ever seen fe80 src address trying to access internet port 443?:

Also, DNS is not normally used for link local addresses as the addresses are determined from the various ICMP6 traffic.

exactly.. So if there is no gua or ula on a device - then there is zero point to doubling the amount of dns traffic by asking for AAAA when there is no way you could ever go there in the first place without atleast a gua or ula. Lazy coding to be honest..Vs having the dns client validate it could even use an answer if it got one before asking for it.

My AVR asks for these 3 fqdn every minute.. It has no IPv6 - what is the point of it asking for AAAA when it has zero way to get there via the IPv6.

dns.jpg

So it out of the box is doing double the amount of dns queries it needs too.. It wouldn't be all that horrible if it would actually cache the response so it only needs to ask say once an hour or so.. But it doesn't so it asks every single minute..

@Gertjan

Oh - good observation - you know, my ISP had many issues recently, and my modem had to be restarted.

Also, I added some new devices and reconfigured my DHCP server (new static mappings) several times recently.

It seems like it might correspond to those events. Could it simply be a remnant of that? Since it hasn't happened in several days, might everything be OK?

FYI:

root 69058 0.0 0.1 13024 2796 - Ss 24Jan25 1:10.52 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog

Yes, just one instance, dating back.

@Gertjan

OK, now I think I've hit a Heisenbug

I noticed the rule specified the same port in the "From" and "To" port range, and the surrounding text said to leave the "To" port blank for a single port. I blanked out the "To" port and committed the change, and the ipv6 ssh forwarding started working.

I made no other changes, and now the form fills in the "to" port with the same number, so it looks exactly like it did when it wasn't working.

It appears the rule just needed to be updated, but I have no idea why since the update didn't actually change anything.

@JonathanLee said in Alias tables don't contain IPv6 addresses anymore:

Is your zone transparent ? I had an issue with mine set to (type transparent) and it was causing issues

Zone type is at default "transparent" not "type transparent".

@jhg

Curious. I replaced the computer I originally ran pfSense on a few years ago. Other than changing the interface assignments, it just worked. I'm still using that new computer today. I'm on Rogers and they use a lot of the same hardware as Comcast. The first computer I ran pfSense on was a refurb HP compact computer and when it died I replaced it with the mini PC described in my sig.

Solved, and it's not pretty.

A debug message pointed me to /var/db/dhcp6c_duid containing text. So I removed the file to give DHCP6 a chance to start fresh. Then I disabled and re-enabled the WAN interface, and now everything's working.

When I look at that file now, it's binary, not text. Somehow, that file was preventing IPv6 connectivity.

Now all I have to do is reboot a few LAN devices that are hanging on to their old delegated prefix :-)

@JKnott After coming back to this a few days later all the wifi clients are now getting ipv6. Must of been some sort of delay from when the ISP gives out the ip addresses.

@haunted

If your prefix is consistent, you don't need DynDNS. I've had the same prefix for almost 6 years and just use a regular DNS server.

Issue still present exactly as described above. Confirmed via wireshark that pfsense will relay ULA requests from a GUA to active directory and AD will ignore it since no scope is establish for my GUA.

@JKnott

I was younger than you when I got mine, but based upon your other historical background, I suspect that you're a few years older than me as well. Too bad we didn't know each other back then. I think we would have had a lot of fun.

Thank you again for engaging with me in this discussion, and for keeping it civil. I've enjoyed the discussion, and look forward to communicating with you again.

@CatSpecial202

There's no such thing as broadcasts on IPv6. The closest to it is all nodes multicast, which is an ICMP6 message. FF00::/8 is multicast. Since IPv6 relies on multicasts for a lot, you want to be careful of what in that range you filter. For example I just saw a multicast to ff02::1, which is a router advertisement to all nodes. If you block that, you'll kill your network. FE80 the link local range and those shouldn't even be passing through pfSense. However, they are also critical to the operation of IPv6, so again be very careful of what you filter.

No, there isn't. miniupnpd itself doesn't support IPv6 ACLs.

https://github.com/miniupnp/miniupnp/issues/694

@tibere86 said in Why does my WAN get an autoconf (slaac) address when I'm using DHCP6?:

Hello @keyser and @leres .Were either of you able to resolve this issue?

I to get both DHCP6 and autoconf addresses with the autoconf address usually before the DHCP6 address so it's the one that gets used. I found I can change the order by manually removing and adding ones of the addresses but this reverts after awhile so I gave up and just live with the order I end up with.

[anonymized addresses]

pylon 724 # ifconfig mvneta0 mvneta0: flags=1008b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 description: WAN options=800bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE> ether 58:9c:fc:01:02:03 inet 99.105.88.5 netmask 0xfffffe00 broadcast 99.105.88.255 inet6 fe80::29c:fcff:fe01:7f15%mvneta0 prefixlen 64 scopeid 0x1 inet6 2600:1700:c01b:5700:29c:fcff:fe01:7f15 prefixlen 64 autoconf pltime 3600 vltime 3600 inet6 2600:1700:c01b:5700::36 prefixlen 128 pltime 3600 vltime 3600 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

Sorry I was late to the party,

I was getting this error for the XBOX UPNP ..

setsockopt(udp, IPV6_RECVPKTINFO): Invalid argument

Jan 3 09:06:45 miniupnpd 11721 Listening for NAT-PMP/PCP traffic on port 5351 Jan 3 09:06:45 miniupnpd 11721 setsockopt(udp, IPV6_RECVPKTINFO): Invalid argument Jan 3 09:06:45 miniupnpd 11721 HTTP IPv6 address given to control points : [2001:REDCACTED] Jan 3 09:06:45 miniupnpd 11721 HTTP listening on port 2189 Jan 3 09:06:45 miniupnpd 11721 STUN: ext interface mvneta0 with IP address CLASSIFIED is now behind restrictive NAT with public IP address IP AWAS HERE: Port forwarding is now impossible Jan 3 09:06:45 miniupnpd 11721 perform_stun: 2 response out of 4 received Jan 3 09:06:09 radvd 55136 warning: AdvDNSSLLifetime <= 2*MaxRtrAdvInterval would allow stale DNS suffixes to be deleted faster Jan 3 09:06:09 radvd 55136 warning: (/var/etc/radvd.conf:52) AdvRDNSSLifetime <= 2*MaxRtrAdvInterval would allow stale DNS servers to be deleted faster Jan 3 09:06:09 radvd 55136 warning: AdvRDNSSLifetime <= 2*MaxRtrAdvInterval would allow stale DNS servers to be deleted faster Jan 3 09:06:09 radvd 55136 warning: AdvDNSSLLifetime <= 2*MaxRtrAdvInterval would allow stale DNS suffixes to be deleted faster Jan 3 09:06:09 radvd 55136 warning: (/var/etc/radvd.conf:24) AdvRDNSSLifetime <= 2*MaxRtrAdvInterval would allow stale DNS servers to be deleted faster Jan 3 09:06:09 radvd 55136 warning: AdvRDNSSLifetime <= 2*MaxRtrAdvInterval would allow stale DNS servers to be deleted faster Jan 3 09:06:09 radvd 55136 version 2.19 started Jan 3 08:21:25 miniupnpd 96990 Listening for NAT-PMP/PCP traffic on port 5351 Jan 3 08:21:25 miniupnpd 96990 setsockopt(udp, IPV6_RECVPKTINFO): Invalid argument

Can you create a ACL in UpNp?

Screenshot 2025-01-03 at 17.23.14.png

It only shows examples for Ipv4