Thanks. I realised I could put the rapid commit command via the GUI using https://imgur.com/a/IdxTJAr The problem I have is that I just cannot get IPv6 working at all with Australia's largest ISP Telstra. They only issue PD's (/56), but they don't respond to solicit commands at all. I think they only broadcast initially an IPv6 Neighbourhood advertisement which pfsense doesn't initially pick up. I've tried everything. All my config files are found here: https://forums.whirlpool.net.au/thread/2784659

While there is no doubt this problem is occurring at the ISP, I've continued investigating. I'm examining the DHCPv6 XID advertise packet. What I've found it this: Status Message: No prefix available on Link 'CMTS89.WLFDLE-BNDL1-GRP3' I assume this means the ISP is not providing the prefix to my network. The full packet is listed below. Any ideas? Frame 66: 214 bytes on wire (1712 bits), 214 bytes captured (1712 bits) on interface 0 Ethernet II, Src: Casa_9a:a1:99 (00:17:10:9a:a1:99), Dst: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea) Internet Protocol Version 6, Src: fe80::217:10ff:fe9a:a199, Dst: fe80::214:d1ff:fe2b:edea User Datagram Protocol, Src Port: 547, Dst Port: 546 DHCPv6 Message type: Advertise (2) Transaction ID: 0x557257 Client Identifier Option: Client Identifier (1) Length: 14 Value: 0001000123eb5e12001617a7f2d3 DUID: 0001000123eb5e12001617a7f2d3 DUID Type: link-layer address plus time (1) Hardware type: Ethernet (1) DUID Time: Feb 4, 2019 15:33:22.000000000 EST Link-layer address: 00:16:17:a7:f2:d3 Server Identifier Option: Server Identifier (2) Length: 14 Value: 00010001159bb6e50021285fd2b7 DUID: 00010001159bb6e50021285fd2b7 DUID Type: link-layer address plus time (1) Hardware type: Ethernet (1) DUID Time: Jun 27, 2011 17:47:17.000000000 EDT Link-layer address: 00:21:28:5f:d2:b7 Identity Association for Prefix Delegation Option: Identity Association for Prefix Delegation (25) Length: 72 Value: 000000000000000000000000000d003800064e6f20707265... IAID: 00000000 T1: 0 T2: 0 Status code Option: Status code (13) Length: 56 Value: 00064e6f2070726566697820617661696c61626c65206f6e... Status Code: NoPrefixAvail (6) Status Message: No prefix available on Link 'CMTS89.WLFDLE-BNDL1-GRP3' DNS recursive name server Option: DNS recursive name server (23) Length: 32 Value: 2607f7980018001000000640712552042607f79800180010... 1 DNS server address: 2607:f798:18:10:0:640:7125:5204 2 DNS server address: 2607:f798:18:10:0:640:7125:5198

Ok, so it appears I was getting a PD, but I wasn't seeing it in the logs because the DHCP6c debugging wasn't turned on. After turning it on, it was showing me the full PD of /60 being given to me and then the router handling the tracking. So, what I have done is enabled tracking only on one of my 3 vlan interfaces (the guest). Then after receiving the prefix, I can set statics on the other interfaces that I care about.

The default deny rule logs by default. There is a checkbox to stop this logging but it will affect ALL traffic hitting default deny not just the traffic you are specifically asking about. A specific rule higher in the list can block the traffic, not log, and processing will stop. The default deny rule (and the logging) will never be hit/processed.

I have exactly the same issue. SLAAC on the PPPoE WAN interface seems to work, but I can't ping6 any host on the internet. Also, clients seem to not getting RA's. But before 2.4.4 I was able to ping6 google.com when I logged in to pfSense via SSH. Don't have a solution unfortunately.

@earlish Hi, Do you still use pfsense? I'm facing the same problem as you using AsashiNET provider. Only the WAN gets the prefix, LAN It is not getting anything. Please let me know if you found a solution because my provider doesn't support PPPoE for IPv6. Thanks in advance.

Hi, thanks for the quick response! actually, I don't need IPv6, but, as we in Germany say, it is sort of a chicken - egg problem. If nobody uses it, then no services will be made available. If no services are available, no one will use it. Anyhow, the German Telekom started DualStack quite some time ago, and I want to use, if only for the reason of it being the future, and no immediate need. I expect current devices to use it where possible. But you are right, no necessary need has arisen, yet. To solve my problem: A guy in the german telekom forum asked the same questions, to which somebody else posted screenshots. They work perfectly for my setup. So I will leave the link here for documentation purposes: German Telekom Forum This setup does exactly what I want and it works without further config need. All the best, Thomas

So, turning off suricata for the WAN interface did not fix this. It doesn't happen every day now, but still pretty often. root 2183 0.0 0.0 6340 2380 - Is 21Jan19 0:02.81 /usr/local/sbin/dhcp6c -d -n -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_igb0.pid igb0 root 11215 0.0 0.0 6340 2376 - Is 27Jan19 0:01.57 /usr/local/sbin/dhcp6c -d -n -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_igb0.pid igb0 root 13704 0.0 0.0 6968 2804 - S 18:53 0:00.00 sh -c ps uxawww | grep dhcp6c 2>&1 root 14116 0.0 0.0 6564 2460 - S 18:53 0:00.00 grep dhcp6c root 38355 0.0 0.0 6340 2400 - Ss 19Jan19 0:11.03 /usr/local/sbin/dhcp6c -d -n -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_igb0.pid igb0 root 41023 0.0 0.0 6340 2376 - Is 15:15 0:00.04 /usr/local/sbin/dhcp6c -d -n -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_igb0.pid igb0 root 60339 0.0 0.0 6340 2376 - Ss 22Jan19 0:02.64 /usr/local/sbin/dhcp6c -d -n -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_igb0.pid igb0 root 83791 0.0 0.0 6340 2376 - Is 24Jan19 0:02.28 /usr/local/sbin/dhcp6c -d -n -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_igb0.pid igb0 root 98049 0.0 0.0 6340 2380 - Is Thu03 0:00.79 /usr/local/sbin/dhcp6c -d -n -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_igb0.pid igb0

@derelict yes, ping 6 working fine. [2.4.4-RELEASE][admin@pfSense]/root: ping6 fe80::21d:aaff:fe92:775c%hn1 PING6(56=40+8+8 bytes) fe80::215:5dff:fe01:20c%hn1 --> fe80::21d:aaff:fe92:775c%hn1 16 bytes from fe80::21d:aaff:fe92:775c%hn1, icmp_seq=0 hlim=255 time=0.755 ms 16 bytes from fe80::21d:aaff:fe92:775c%hn1, icmp_seq=1 hlim=255 time=0.739 ms 16 bytes from fe80::21d:aaff:fe92:775c%hn1, icmp_seq=2 hlim=255 time=3.010 ms 16 bytes from fe80::21d:aaff:fe92:775c%hn1, icmp_seq=3 hlim=255 time=1.028 ms 16 bytes from fe80::21d:aaff:fe92:775c%hn1, icmp_seq=4 hlim=255 time=0.840 ms 16 bytes from fe80::21d:aaff:fe92:775c%hn1, icmp_seq=5 hlim=255 time=1.603 ms

@inq Thanks. That was really helpful!

I'm pretty sure that the only way this could be done in pfSense is with a virtual IP (Firewall > Virtual IPs) on the respective interface... but if your ISP ever delegates a different prefix to you, that virtual IP would need to be manually updated with the new prefix in order to function again.

A packet capture on that provider would be interesting to see. One from a device that works and one that doesn't. As has been said, it works great but every ISP IPv6 deployment cannot possibly be tested. Some reliance on the community is required. I, personally, know that dhcp6c works flawlessly with Cox Las Vegas and it works in my lab with DHCPv6 served by pfSense. Unfortunately, ISPs take great liberties here and some seem to need special sauce to make it work. It's too bad ISPs are less-than-helpful when you try to get the recipe for THEIR SERVICE out of them.

It says unless your running forwarder/resolver.. Prob could be worded a bit more precise - or actually check to see if listening on actual interface if you have strict set. Normally people that run resolver/forwarder want their dhcp clients to talk to pfsense. This is what like 99% of use cases (number just pulled out of my ass <grin>) If you have a lot of interfaces pick the way you want to go about it that is least amount of work ;) I will try and duplicate so can put in request to have wording updated, or option changed so that if strict and not bound to interface don't hand out pfsense IP.

@derelict Thanks for your reply. This ISP has made some of possibly questionable implementation decisions in their network. First, the DHCP before RA feature was tested on this network. Their edge routers will not respond to an RS until after the DHCP solicit/advertise and DHCP request/reply sequence is complete. After that, the edge router will respond to an RS with an RA. I just fired up wireshark and captured some packets. The router lifetime in the is 4500 seconds (75 minutes), the reachable time is 0 and the and the retrans timer is 100 ms. These values are also used in the unsolicited RA messages, which leads to another interesting implementation decision. Second, the time between the unsolicited RA messages ranges from approximately 15 minutes to approximately 30 minutes. I determined this by capturing RA messages over several hours. This is longer than usual, but according to RFC 2461, MaxRtrAdvInterval is 1800 seconds, so they are operating within the allowable limit. I also looked at the DHCP reply. T1 and T2 in the IA for PD are 300 and 480. The preferred lifetime and valid lifetime in the IA Prefix are 600 and 900, respectively. The above are from my router which is working properly. Apparently on some fiber networks, the unsolicited RA messages are not being sent at all. This is a known problem that they are working with the router vendor on. I'm trying to help someone else figure out why pfsense is behaving as I described above. Based on these timers, I would think it should work for 75 minutes (or whatever the prefix lifetime is) until the prefix expires, then it should stop working. However, it seems to fail once after initially getting a prefix, then if the interface is restarted, it keeps working. I don't understand why it would keep working if prefix expiration is causing it to stop working after the interface is started. Maybe something else is going on. I don't have packets captured from this network, but I'll try to get some.

I know this is old but even on 2.4.4-p2 ipv6 only works for about 1 to 2 days and then all Facebook videos stop loading until I turn ipv6 off. I guess I will just have to give up on ipv6 with my ISP.

@alankeny said in Splitting a static /48 from Mediacom into subnets: With their static IPv6 allocation, the WAN side is basically a bridged network that can have 1,208,925,819,614,629,174,706,176 IPv6 hosts on it, and that's the only configuration option available. That's nonsense. A /48 is not usable in that manner. It's supposed to be split up into /64s, which are what is used on a LAN. For example, I have a /56. One /64 is used for my main LAN, a 2nd for a test interface and a 3rd for my VPN. MY ISP uses DHCPv6-PD to provide my prefix and WAN interface address. As Derelict mentions, take a look at what's on the wire. You might want to see if you can talk to 2nd level support. Maybe they might have a clue about how IPv6 works.

@heartofrainbow said in IPv6 not working on LAN: The WAN and LAN IPv6 addresses have the same prefix Doesn't work that way.. your so called passthru mode would be a bridge.. Why don't you call your isp and ask what they support or what is your ISP so we can look it up. What are you wanting to do with IPv6 exactly? If you don't even know how your ISP does it, why does it even matter... If you want IPv6 - just get a free tunnel from HE.. Then you can have a /48 and clickity clickity done... Doesn't matter what your ISP supports or doesn't support.

@nthly Glad to help.

@mikekoke said in DHCPv6 problem with Netgear router: Richiesta scaduta. Request timed out - what are you rules.. If you don't allow icmp then no you wouldn't be able to ping.. Do a traceroute - does it actually send it to pfsense IPv6 So what network/prefix did you put on your lan side network? You sure your actually even surfing via IPv6? What does say https://test-ipv6.com/ show you when you go there from a client