@johnpoz: That is a pretty OPEN rule ;)  If your wanting to lock down access to the gui.. And only access it from a specific vlan great.  But that that seems pretty wide if you ask me ;) Glad you got it sorted. yea..I will configure a rule according to the link below. :D https://doc.pfsense.org/index.php/Restrict_access_to_management_interface Thanks!!!

If I recall the formula is something like 33434 + (max-ttl * numberofprobes - 1) Since each port going to use a different port, where 33434 is the base port.. So for example ding a sniff while doing a traceroute to something behind pfsense I get attached.  So yeah opening up the ports should allow your trace to work when using udp. [image: udptraceports.png] [image: udptraceports.png_thumb] [image: tracerouteviaudp.png] [image: tracerouteviaudp.png_thumb]

I have found the solution! instead of configuring the lan interface to 'track interface'  ,  I used a static ipv6 address and now it works also those messages in the log are gone now

@virgiliomi: The two items I bolded in your original post are why you will need to adjust the indexes. LAN1 and WAN are currently set to use the same /64 address range (assuming the xxxx:xxxx is the same in both, since you didn't use different letters), which won't work. Fix the index used for LAN 1. That's what I figured.  Thanks, I appreciate the confirmation.

I renew this old thread because, at today (2.3), I think would be useful  a way to set the right MTU in a 6rd ipv6 environment. Currently mtu is hardcoded to 1280…. but in case of ipv4 mtu 1500 on the wan, the right (and optimal) value should be 1480... (wan mtu minus 20). What do you think about?

What johnpoz is talking about is that with IPv6 tunnels the traffic is fully routed and the remote end must know which IPv6 prefix (usually a /64) it should route to the client end for two-directional traffic between the LAN network on the client and the IPv6 internet. Also that same prefix must be used on the local LAN for hosts by some method, manual or automatic configuration. OpenVPN as far as I know has no provisions for automatic configuration of IPv6 other than the one client IPv6 address that gets assigned to the local end of the tunnel network.

It's possible. Just not with the exposed pfsense gui. Here are some logs after some heavy editing in dhcpd6.conf (rog is a W10 client): bind debug log client 2a02::1#23748/key dhcp_updater: updating zone 'example.com/IN': update unsuccessful: rog.example.com: 'name not in use' prerequisite not satisfied (YXDOMAIN) client 2a02::1#23748/key dhcp_updater: updating zone 'example.com/IN': deleting rrset at 'rog.example.com' DHCID client 2a02::1#23748/key dhcp_updater: updating zone 'example.com/IN': adding an RR at 'rog.example.com' DHCID AAIB6pZPrA7zoDg1s+EYgl0GGo0yjS0hKNuiDIcN0lyFMHs= client 2a02::1#23748/key dhcp_updater: updating zone 'example.com/IN': deleting rrset at 'rog.example.com' AAAA client 2a02::1#23748/key dhcp_updater: updating zone 'example.com/IN': adding an RR at 'rog.example.com' AAAA 2a02::b9c7 Pfsense dhcpd log: May 13 08:33:57 srv dhcpd: Sending Reply to fe80::4854:ff3c:xxxx:xxxx port 546 May 13 08:33:57 srv dhcpd: Added new forward map from rog.example.com to 2a02::b9c7 May 13 08:33:57 srv dhcpd: Added reverse map from 7.c.9.b.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.a.2.ip6.arpa. to rog.example.com May 13 08:33:58 srv dhcpd: Renew message from fe80::4854:ff3c:xxxx:xxxx port 546, transaction ID 0xA7A3900 May 13 08:33:58 srv dhcpd: Reply NA: address 2a02:::b9c7 to client with duid 00:01:00:01:1d:4e:73:c9:10:bf:xx:xx:xx:xx iaid = 51429192 valid for 1920 seconds ```  Updated zone record: $TTL 600 ; 10 minutes rog A 10.0.200.7 AAAA 2a02::b9c7 DHCID ( AAIB6pZPrA7zoDg1s+EYgl0GGo0yjS0hKNuiDIcN0lyF MHs= ) ; 48819 13 32 The problem is that the pfsense dhcpd server is very picky about dhcp clients. I couldn't register any apple ios device in ipv6 ddns zone. On the other hand i had no problems with a HP printer. ISC dhcp 4.3.4 might fare better.

Thanks for the info – much appreciated!

It may have been you were seeing a Cox modem firmware bug that was impacting IPv6 that has now been fixed. There was some discussion of that bug over at: http://www.dslreports.com/forum/coxhsi

Your issue is the same than https://forum.pfsense.org/index.php?topic=109278.0

Running both IPv4 and IPv6 over the same IPv4 only GRE tunnel actually seems to work over the same tunnel now! The IPv6 link-local addresses that are set on the IPv4 GRE tunnel works fine to use as p2p link for IPv6 traffic. I needed to set the remote IPv6 link-local address as IPv6 default gateway, then everything started working. Remote end (Cisco router) is using static IPv6 routing with the Tunnel interface as route, thus using all available IPv6 addresses to route the traffic to pfsense, including the pfsense link-local address on the GRE interface. Success! //Staffan

I've started using RA in Stateless DHCP mode and have enabled DHCPv6 to hand out DNS addresses. This seems to work fine for Windows 8.1 machines on my network but Windows 10 doesn't get the IPv6 DNS server addresses. Is this a problem with Win10 or pfsense?

Yes the tunnel was up. Thats what I couldn't understand. Its been working for days without issue. Anyway, I worked through the pfsense IPv6 tunnel guide and I found the problem! Under the gateway settings this option was UNTICKED: This will select the above gateway as the default gateway. So I ticked it and its all working now! I have a public static IPv4 address so it wouldn't be this. I'm just not sure WHY this box was unticked and it stopped working. Very odd.

@razzfazz: System -> Advanced -> Networking -> uncheck "Allow IPv6"? This fixed the issue. I didn't wait long enough  :-X

Thanks to everyone that helped. I purchased an Arris modem TM822G, and I'm happy to say it works! virgiliomi. How about more, Router advertisements and DHCPv6.

@Inq: If you only have a /64 delegated by your ISP 0 is the only valid option for prefix id. That would be great to add to the text on the web page just as it stands and it would explain the 0-0 option being shown.