@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 I restarted my device and my lan received an IPv6 address. I didn't change anything. WAN had received it's IP but I guess I needed to restart for the LAN to get it.

My devices on the LAN have IPv6 address. I did a test ping to google and it works.

The only issue I have now is the periodic disconnect. Internet is down until I restart the device. I had this issue before and now it came back. I'm currently monitoring how often this happens.

Thanks for all your help.

@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.

@jkmuk

Do a packet capture on DHCPv6.

To do this, shut down pfsense and disconnect the WAN cable.
Reboot and start Packet Capture
Plug in the WAN cable.
After a couple of minutes, download the capture file and post it here.

This issue is reproduced by Netgate support and tracked as https://redmine.pfsense.org/issues/12790

@jknott as I said this setting work for me perfectly.

@gertjan I applied it to all interfaces in a floating rule. Why Not right? Yeah. Its an alias. Netflix was sort of sneaky by not blocking everything. Had me fooled for a minute there. I also handed out static IPV6 addresses to everything connected to the pfsense including my XMPP chat server and phone server. Interestingly, that totally fixed NAT issues like broken video and broken voice even when only one side of the conversation was on IPV6 and the other side was on IPV4. Thats the main reason I want everyone to transition to IPV6. No more NAT. No more buying a public IP for every server. No more need for STUN, ICE, Jingle, WebRTC, TURN servers or crap like that.

@wbond
Ok, great.
The dull thing about "ISP router in in router mode" is : it should work, as my he IPv6 tunnels are all up right now @work and also the one @home.
I'm using the he.net POP in Paris.

Note : he.net is supplying me with IPv6, as my ISP doesn't know what that is (@work) - or, @home, they just supply on /64. so none are available for the LAN's.

Btw : always check the tunnel status. And if doubt, the forum on he.net.

Still an issue today

@pfsensation

Yep, it's green and showing online.

@jsmiddleton4 It's odd that I'm seeing these in my logs as well. According to that redmine, it was closed and targeted for version 2.5.1. And, this:

https://redmine.pfsense.org/versions/61

says it actually was in 2.5.1 (if I'm reading that right). But, I'm on 2.5.2-RELEASE (amd64) and still seeing them.

@keyser said in IPv6 via IPSec:

My understanding is that ULA is not 100% like RFC1918 - there is actually another range of IPv6 addresses for that.

Not that I'm aware of. ULA is the same as RFC1918 in that it's routeable, but not allowed on the Internet. However, you can't have a VPN over the Internet that uses ULA on either end. VPNs can certainly carry ULA though, just as they can RFC1918.

Thank you all for your answers and discussion. Unfortunately it’s a “real problem”. There is a person who I trusted before but this person is now in suspicion for a bad deed. While changing my passwords (way too late I did that) I saw a log in to my personal account that was definitely not made by myself. It’s possible that that person had an auto login but I also had the hunch this person spied my personal mailbox (which is of great concern because I was in touch with official entities). Well I think the chance is quite low I forgot to logout somewhere and that that device has the same /56 prefix as that person. So I can just hope that was an auto login or that person did not found anything. Thank you all.

@jknott I'll try this out when I can find a time my flatmates are all asleep (not often!). Going on a long drive today, but thanks for the tip :)

@jknott
I know you can use WAN and LAN, but that doesn't help if you want to allow a rule for a client inside the IPv6 pool.

My address for WAN maybe 1111:2222:3333:4444:AAAA:BBBB:CCCC:DDDD, but my client maybe
1111:2222:3333:4444:AAAA:BBBB:CCCC:FFFF. So, I need my firewall to point to the FFFF address in the forward and if my IPv6 address changes, then I have to manually go into the firewall and update them.

@elscorcho

Good. That setting allows you to choose whatever size prefix you want, up to whatever your ISP provides. So, if you choose 64, then you only get a single /64.

I also have a /56, with a /64 assigned to my main LAN, guest WiFi, test LAN, a downstream Cisco router and I can then route another /64 to the Cisco router.

With IPv6, you get gazillions of addresses, so no need to worry about how many you use.

@mrpete

HEY!!! Get your priorities straight!!! 😉 🎅

BTW, isn't OPNsense based on pfsense? A friend of mine runs it and seems to like it.

@magikmark

????

If if was connected before, why is it now a "new" device? Regardless, one trick is to power down the modem for a minute or so and then try connecting.

@bmeeks

I'm a lot luckier with my ISP. They've been providing native IPv6 for about 6 years and via 6to4 and 6rd tunnels for a while before that. They are also my cell phone carrier so not only does my phone get an IPv6 address, but so do devices I tether to it. Also, my IPv4 address is virtually static and the host name depends on my hardware MAC addresses, so I have no problems with connecting my VPN to my network.

@martywise

My IPv4 address is virtually static, but my host name is based on modem and router MAC addresses. If I change hardware, the host name will change. If I change my router or it's NIC, my address will change. On IPv6, my prefix has survived modem and complete replacement of the box I run pfsense on. I suspect it might take a nuke or two, to change it. 😉

@johnpoz said in Access my website from WAN IP:

That would be a feature request or bounty..

I am going with feature request. 😀