With the exception of the DHCP setup, the following works for me for a little while, but I suspect the issue on my end is something else.

https://techielibrarians.com/index.php/2017/06/08/native-ipv6-with-comcast-business-and-pfsense-2-3/

Those instructions are for the old gateway modem type, but I'm on the Cisco and it seems to work.

Ok, so the final update, I have everything fixed now (at least till now)☺

So the final trick is to set my switch to tag port 5-8 which connect to my 4 APs

apparently the tp-link APs will receice packages on it's selected wirelss VLAN + anything that's untagged (without vlan header)

after change my switch to tag vlan1 on port 5-8 it ensures all the vlan1 tag won't be removed when outbound the port, which fixes the RA flood issue.

Thanks everyone for the help

Even if your ISP doesn't provide IPv6, you can still have it, using a tunnel from hurricane electric. They are free, they perform well, they are very reliable and they work. I used one for years before my ISP implemented IPv6. There are lots people here who can help you set it up.

Thanks for the sanity check.

I got a few IPv6 digits reversed. Fixing the typo fixed the routing. :)

@Derelict I am certain I have come across some sort of bug in pfsense that when IPv6 is enabled, IPv4 performance decreases by about 2mb/s both up and down.

I have done lots of testing tonight and Telstra's router does not suffer this issue, only pfsense.

The moment I turn off IPv6, I get my full speeds back. The moment I turn on IPv6, I lose 2mb/s down and up on IPv4. I cannot replicate that on Telstra's router. I maintain full speeds on IPv4 with IPv6 enabled on Telstra's router.

What additional information would you need to help isolate what this bug would be?

I guess this feature is not available on pfSense. It is a sad news as the situation will become worse over time.

IPv6 over IPv4 was the 1st phase of IPv6 implementation. Now we are on the second phase were we are moving to IPV4 over IPv6, as ISP started increasing their IPv6 capable gear. We will see this increasing and this phase will last years IPv4 will eventually go away. However, looking at the trend, I wont be surprised if it takes over 30 years to get there.

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.