@jknott said in Routing IPv6 ULA across interfaces:

@offstageroller said in Routing IPv6 ULA across interfaces:

They appear to create their own ULA addresses that have nothing to do with my router (pfSense), and since I don't run a consumer router that allows all by default and only has a single subnet, things start getting blocked.

Is your modem in bridge or router mode? The modem from my ISP provides both GUA and ULA addresses when in gateway mode.

My modem is in bridge mode.

My pfSense WAN interface has a link local and global address assigned to it. My modem does not appear to be offering a ULA address to that interface.

@tzvia yes Interfaces widget shows the public one. I was using Gateways just as a quick summary for Interfaces -obviously bad idea- because there are many VLANs, much better idea seems to be a second Interfaces widget showing only the WAN interface so that solves my request. I still dont know why I was seeing public IPv6 address as the gateway before but maybe I am confused and remember something else, I dont have 2.5.2 at the moment to check.

@steveits I noticed the ipv6 gateway isn't right on the vm

@dwren78

Hmmm this is frustrating, could you describe what is happening in more detail? I am confused why it works when you have the Smarthub ahead of the pfsense router. I am not familiar with configuring the smart hub as a bridge, so where is the pppoe authentication done, in the smarthub or pfsense?

Are you getting a v4 address?
Is the v6 interface up?
Are you getting a link-local v6 address?

Dumb question, but I am going to ask it anyway, are you using your bt business pppoe username/password?

cheers

F

@dem

Do they offer 6rd on wireless? My carrier, Rogers, provides native IPv6 on wireless, but only a single /64. This means the device connected to wireless will get an IPv6 address, but not any device behind it.

A bit of history. Many years ago, my wireless carrier was called "Cantel AT&T" when they partnered with AT&T. This goes back to when Rogers owned part of Unitel, a company I used to work for, and AT&T had a slice of it too. Even now, AT&T is the preferred company for Rogers to roam on in the U.S., though I think T-Mobile is the other choice.

@johnpoz said...

I don't think so. Your interface should have a /64 on it... What you delegate would be under the delegation pool range.

Your downstream device for example would grab an IP out of the /64 range, and then request a delegation for networks for it to use and hand out behind it.. Its wan would have an IP out of the /64, and it would get a say a /56 that it would use for delegation for stuff behind it.

Meaning, what it delegates would not overlap with what it has itself... which is not allowed.

Try it for yourself; I just did:

Whatever the size you provide to the interface...

Is the TOTAL range available to that interface, including all delegated ranges.

If /64, then only /64 or smaller is available for any use under that interface.

By using /56:

I can set a /64 range for DHCPv6 of the interface AND I can allocate a lot of space for delegation (say, /60)

In practical terms...
if /48 is aaaa:bbbb:cccc::
and /56 for an interface is aaaa:bbbb:cccc:9900::

Then for that ifce DHCPv6, it has ...9900 through ...99ff available.

So I can use ...9900 for my own /64 dhcp and ...9910-991f would be a nice /60 delegation etc.

(BTW, I've learned to allocate from the left in a quad (abcd)... because :1: means :0001: not :1000: ... that took me a few moments to realize!)

@4920441-0 Does tcpdump show you anything? That's where I typically begin...

@derelict well said, and sums up my thoughts.

Respective DUID state is nice, and it would be even nicer to track and adjust relatively on the pfSense side.

Thanks for your time.

@netblues Quoting my self, recreated the bridge, enabled
f2d80342-4a62-46ff-9e35-8e57d7b0eff7-image.png

in bridge advanced config
and I know have a global ipv6 that works.
I also checked it works on all bridged interfaces

Will monitor this for stability

@jknott

As suggested, I disabled DHCPv6 and switched SLAAC to "Unmanaged", and although the Android device picked up the correct IPv6 details (as it did before), it still was not able to ping the global IPv6 address of the pfSense interface for that VLAN, so the issue remained.

At that point I decided to change the global IPv6 address of the pfSense interface for that VLAN (from ending ::1 to ending ::2) and I was able to successfully ping that address from the Android device. At that point the Android device was also able to successfully utilise the DNS server on that same address, so the Wi-Fi connection stayed up. Problem solved 😃 . I still don't know though why the Android devices on my network didn't like the ::1 address. As I said previously, no such problems with my Windows 10 and iOS devices.

After that, rather than keeping the interface address ending ::2, I decided to follow the SLAAC approach and I updated the VLAN interface global IPv6 address to the combination of the network prefix (/64) with the EUI-64 interface identifier. All was still well after that; I could ping the address from my Android device and I could utilise the pfSense DNS Resolver.

For the avoidance of doubt, all devices (Android, iOS and Windows 10) are now happy. DHCPv6 remains disabled and I'm only using SLAAC in "Unmanaged" mode. Only peculiarity to note is that as long as DHCPv4 is active on the same VLAN, Windows 10 does not pick up the IPv6 DNS servers, it uses the IPv4 DNS servers instead. As soon as I disable DHCPv4 though, Windows 10 picks up the IPv6 DNS servers (via SLAAC). From what I've read, this seems to be a Windows 'feature' 😉 .

@flo-0

You could get a /48 and it will be be static. I'm using two of them, and they are fine for years now.
But there is probably a trade of : speed.

See https://www.tunnelbroker.net/ and Configuring IPv6 Through A Tunnel Broker Service.

I'm using a existing domain name on my LAN's and the hots names with IPv6 are written into the DNS server and thus are known globally. Some RFC 2136 scheme is used for this.

@ahsunh

Setting up DHCPv6 on a VLAN is exactly the same as on the LAN. Just make sure you use a different IPv6 Prefix ID for each interface. However, why are you using DHCPv6? It won't work with Android devices.

@dwighthenry

I have not set up a DHCPv6 server, as I use SLAAC. However, ULA addresses start with fc or fd. There was a distintion between the two in that the fc block was supposed to use some server to co-ordinate assignments, though I don't believe that went anywhere. I don't know what could cause that error. What protection are you referring to? Given that ULA addresses are not to be passed over the Internet, there's not much to attack you.

OK, I think I figured it out looking at the tunnel interface MTU on the firewall. BY DEFAULT it sets to 1280 unless you set it to match the MTU on the other end of the tunnel - 1480 per HE. When I set to 1480, it no longer sent PMTU for 1280, but for 1480 like it's supposed to. Not at all intuitive...
tracepath google.com
1?: [LOCALHOST] 0.029ms pmtu 1500
1: 2001:470:e073:101::2 0.392ms
1: 2001:470:e073:101::2 0.407ms
2: 2001:470:e073:101::2 0.425ms pmtu 1480
2: tunnel202636.tunnel.tserv13.ash1.ipv6.he.net 29.177ms
3: 10ge2-2.core1.ash1.he.net 13.809ms
4: pr61.iad07.net.google.com 12.468ms

tracepath google.com
1?: [LOCALHOST] 0.033ms pmtu 1400
1: 2001:470:e5bf:1001:cafe:dead:beef:1 8.834ms
1: 2001:470:e5bf:1001:cafe:dead:beef:1 0.516ms
2: 2001:470:e5bf:3000::2 1.576ms
3: tunnel161881.tunnel.tserv13.ash1.ipv6.he.net 7.791ms
4: 10ge2-2.core1.ash1.he.net 7.385ms
5: pr61.iad07.net.google.com 7.862ms

@jknott I went back and looked things over for a couple of day. Looking at Wireshark, I wasn't seeing any ICMPv6 traffic at all coming over to the wired side of my network from the wireless side. So, I assumed it was something wrong with bridge mode on that Amplifi HD wireless router. I ordered a small netgear wireless access point to replace it with. But, today, as I was preparing for that WAP, I noted my prefix in the WAN interface wasn't what I thought it was. I used to have it set up for a /56. But, it was set for /64 and wasn't even set to send a hint. I changed that and now have IPv6 addresses on the phones. I made no other changes. Oh, well. Sorry for the trouble. Thanks for the help.

@kimble said in IPv6 Gateway monitoring broken in 2.6.0?:

Maybe it's clever enough to bind to a LAN address in that instance? I've no idea.

You have to specify a source address by using the -S option in ping. I just did it, using my LAN global address.