THX!

The Problem was an impropper configuration of the IPV6-LAN-Interface. I just forgot to set an vIP and different IP's for the two pfSense.

So both of the DHCP gave their very best to provide even more adresses that the other one. As I fixed that the battle stopped and now this is working fine

I'm bridging because the way my house is set up I have APs in different spots around the house, I need seamless transition from one AP to the next and if you change network ports I change networks.  A bridge lets it be one flat network between the three 802.11ac points so as devices transition as they move throughout the house network connectivity doesn't go goofy.

VPN clients will disconnect, etc if I change underlying networks.

This is the way I've done it since early 1999 or so, and if it wasn't broke not in a hurry to fix it but Is there another method besides bridging that will allow me to continue a flat network on each port?  Based on my knowledge I have to create four subnets and have four different DHCP ranges and this causes issues.  I'd prefer to have a single device that does both my network switching & internet firewall/routing.

I'd prefer not to step it down to a single LAN as my connectivity via wifi sucks without distributed hot spots, and also to be honest what I'm doing was handled just fine by my lower performance router i replaced because of my update to faster internet.  It's not that I'm having trouble distributing the IPV6, I'm not getting one and DHCLIENT6 is not running.  It'd be one thing to me if I was getting an IPV6 on my WAN port, but I'm not even getting that.  If I do get that, my IPV4 stack crashes and requires a reboot to recover.    The WAN port isn't bridged in anyway, its' off by itself.

My Network Diagram of the physical layer.

Based on everything I've read about the way TWC works for IPV6 is they give you a /64, so that's what I was going with.

Screen shots of my extremely basic configuration (checkboxes checked) is here http://imgur.com/a/EyljQ

@hda:

Hi David, great to read from you again :)

<github.com pfsense="" commit="" ec0643f7f1537ab6a18ed05fc015ecba598fcffc="">does yield, but from head on:

From 682d280755ee7bd2140dca84b5ee21659a4ae580 Mon Sep 17 00:00:00 2001 From: David Wood <david@xxxx.org.uk>Date: Thu, 24 Dec 2015 05:50:16 +0000 Subject: [PATCH 1/8] Make ppp-ipv6 the only way interface_dhcpv6_configure() is called on PPP interfaces ... snipped</david@xxxx.org.uk>

And following code content is very different from your last patch (4th)  ;)</github.com>

For some reason, System Patches chooses to use the .patch GitHub URL, which gives all the history including the many code snippets I later reversed. If it used the .diff GitHub URL, that produces a flat patch with no history, which is really what you want.

In this case, I suggest using https://github.com/pfsense/pfsense/commit/ec0643f7f1537ab6a18ed05fc015ecba598fcffc.diff as the URL.

And I'm not going to have an answer on that

Do you thinks that what I wrote could work ?

Pretty sure that's just log spam because the sysctl is set after radvd starts. Is everything working and it's just something you noticed?

Yep… time to give this some testing when I get home tonight!!

You can change it in /etc/inc/services.inc
Ugly fix but it works.
See my other threads about this…

How exactly do you have the router advertisements tab setup on pfSense?

For the lines you show in rc.conf, it would attempt to configure itself via SLAAC, which would only be active in Assisted or Unmanaged modes on the RA tab. For FreeBSD to use DHCPv6 it requires some extra config depending on the DHCPv6 client in use.

@razzfazz:

OK, so what does your routing table look like afterwards?

Edit: Never mind, looks like it's not treated as a local segment:

Destination                      Gateway                      Flags      Netif Expire 2601:x:y:a::/64              link#2                        U          igb0 <--- local segment for this interfaces 2601:x:y:b::/64              bc:5f:f4:xx:yy:zz            US        igb0 <--- manually added route

Are you sure the :2c: prefix your provider gives you is intended for the WAN side, not the LAN side? I.e., you can't just use an address from the :1: prefix on the WAN interface? Using a non-local gateway seems like a very non-standard (and arguably broken) configuration. Is this what your provider tells everyone to use, or is this something specific to your particular setup?

This is an OVH & Hetzner type setup, ie. "standard" for all.

I'm also hitting this same problem, and an issue to use IPv6 with pfSense… else I'll have to consider the HE tunnel mechanism ;(

@awebster:

With CARP, you will need additional rules to make this work.
Typically, create an alias which contains VIP+WAN IP for each firewall, then use that alias in firewall rules, for example to allow ping.
Something like this…

I am happy to say that the issue is now fixed! It turns out the main problem was with ISP. They have assigned wrong /48 to the routing. As soon as they gave me the correct block IPv6 came to life in the network behind pfsense.

Thanks to you awebster i was able to pin point the issue and confront my ISP by running traceroute and ping from outside through an online website. I tried everything from inside and did not even think of testing it from outside.
Also thanks to the pointer about alias of VIP+WAN IP for rules. That actually solved the Ping issue from outside into client node.

Track Interface does the following…

Sets RA type to Assisted Enables DHCPv6 with an address range of ::1000 to ::2000

The assisted RA type means that a device will use SLAAC if it is able to use it. Nearly all IPv6 devices use SLAAC, but some may not be able to, or might be configured to specifically use DHCPv6. For devices that only support DHCPv6 or are configured to only use DHCPv6, they will get an address from the DHCPv6 server within the address range.

It has been said that in pfSense 2.3, interfaces that use the Track Interface setting will be allowed to customize RA and DHCPv6 settings. That capability is not yet present in the beta version, though. There is no doubt that there are some tricky circumstances surrounding the ability to allow that, especially with a prefix that can change at a moment's notice from your ISP.

@johnpoz:

you shouldn't be getting a /128 on your pi…  The smallest prefix with ipv6 is /64..  And its not just linux that works that way its every OS there is that can work with IPv6..

anything other /64 is going to break all kinds of shit from working correctly..

I dusted off my raspberry pi over the weekend, and installed latest NOOBS + raspbian, sure enough it comes up with /128 in addition to /64.
The /128 is the address assigned by the DHCP server; the /64, I guess it is deciding thru SLAAC on its own because of RA.  I have some android clients on the network, so need SLAAC too.
radvd on pfsense 2.2.4 is set to Assisted, with the RA Subnet set to WWWW:XXXX:YYYY:ZZZZ::/64
Win2K8 DHCP server is handing out IPs in WWWW:XXXX:YYYY:ZZZZ::/64
Resolv.conf on PI ends up with Domain Controller IPv4+IPv6 IP as well as pfSense IPv6 IP, not ideal since it doesn't have any knowledge of the domain.  Strange that it ended up with the pfSense IPv6 IP because the DNS Servers entry is blank in the RA config tab.

eth0      Link encap:Ethernet  HWaddr b8:27:eb:35:53:31            inet addr:10.2.95.18  Bcast:10.2.95.255  Mask:255.255.254.0           inet6 addr: WWWW:XXXX:YYYY:ZZZZ:fcef:f7d6:12c3:f393/64 Scope:Global           inet6 addr: fe80::bd6c:2ed5:a452:1eff/64 Scope:Link           inet6 addr: WWWW:XXXX:YYYY:ZZZZ:c439:ca13:15f5:31a9/128 Scope:Global           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:80378 errors:0 dropped:5856 overruns:0 frame:0           TX packets:4106 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:6121679 (5.8 MiB)  TX bytes:662612 (647.0 KiB) wlan0    Link encap:Ethernet  HWaddr 34:08:04:a0:5d:3d            inet addr:10.2.95.20  Bcast:10.2.95.255  Mask:255.255.254.0           inet6 addr: WWWW:XXXX:YYYY:ZZZZ:927a:28a4:a3e3:73f8/128 Scope:Global           inet6 addr: fe80::b69e:3850:a1d0:6935/64 Scope:Link           inet6 addr: WWWW:XXXX:YYYY:ZZZZ:d9d4:1377:f075:8c05/64 Scope:Global           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:315611 errors:0 dropped:17236 overruns:0 frame:0           TX packets:325 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:121355585 (115.7 MiB)  TX bytes:63491 (62.0 KiB)

@Vetal:

So, on VPS, VPN tunnel (tun mode) is

VPS end: prefix_64:8000::1/64 pfSense end: prefix_64:8000::2/64 LAN: prefix_64:8000::1001/116 DHCPv6, Router Advertisements - Managed

So far, so good, everything is pingable within VPS <=> pfSense world. …
...

I am testing similar setup, trying to follow https://community.openvpn.net/openvpn/wiki/IPv6 - the only sample I found so far.
gateway is getting IPv6, I can ping VPS eth0 but not outside.

From prefix_64:8000::1 icmp_seq=1 Destination unreachable: Administratively prohibited.

net.ipv6.conf.all.forwarding is enabled.

Would you mind sharing your openvpn config files?

I am told this the way IPv6 can legitimately operate.
there is no problem setting up route manually in Linux on the same network:
https://clients.inceptionhosting.com/knowledgebase.php?action=displayarticle&id=8

The FreeBSD variant of Linux ip commnds

route add -inet6 -net prefix_48::/48 -interface vtnet0
route add -inet6 -prefixlen 0 default prefix_48::1

produces virtually the same routing table as DHCP6 (probably via routing advertisement) created one but there is no IPv6 connectivity.

Update: on Little Happy Cloud CentOS 6 static IPv6 configuration looks like:

cat /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
IPADDR=nnn.nnn.nnn.XXX
GATEWAY=nnn.nnn.nnn.1
NETMASK=255.255.255.0
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6_DEFAULTGW=prefix_48::1
IPV6ADDR=prefix_48:XXXX::X/64

Could anyone explain how to configure pfSense to achieve the same configuration?

Just curious, what hardware are you running comcast connected pfsense on?