![]() ![]() ![]() ![]() |
|
Aaroona:
Unfortunately now back to having issues again :|
Sorry, a glitch in your Matrix again. Mine’s fine still.
Aaroona:
Unfortunately now back to having issues again :|
Can't seem to reproduce this on our end. The App store loads fine, and downloads complete as expected on an iDevice from a test line with v6 enabled. Perhaps the glitch in the Matrix is more local to your network, rather than Matrix wide?
IPv6pipe:Aaroona:
Unfortunately now back to having issues again :|
Can't seem to reproduce this on our end. The App store loads fine, and downloads complete as expected on an iDevice from a test line with v6 enabled. Perhaps the glitch in the Matrix is more local to your network, rather than Matrix wide?
SirHumphreyAppleby:
IPv6pipe:
SirHumphreyAppleby:
I lost IPv6 connectivity after my plan was upgraded to gigabit last week.
There's an email waiting for you. :)
I'm still waiting for a followup from your operations team. Looks like this has fallen through the cracks.
For the benefit of others, the e-mail suggested reverting to PPPoE, which failed as expected. Unless I have missed something, nobody has reported IPv6 on Bigpipe working with PPPoE and any version of pfSense/OPNsense.
IPv6 on PPPoE has generally worked OK for me. I haven't had any issues with it since installing the last few PFSense betas, and 2.4 release (touch wood)
OmniouS:
IPv6 on PPPoE has generally worked OK for me. I haven't had any issues with it since installing the last few PFSense betas, and 2.4 release (touch wood)
Thanks for the update. I will try the release build of 2.4 to see if IPv6 is now working with PPPoE. There was also an update for OPNsense (which I am currently using), but that's still not working with PPPoE for me, so I guess those changes haven't yet been merged.
I am now running pfSense 2.4 Release, configured for PPPoE. There is no IPv6 address being assigned to my LAN interface.
@OmniouS, since I am now using a combination which hasn't worked for me in the past, could you please post your WAN settings (DHCP6 Client Configuration)?
SirHumphreyAppleby:
I am now running pfSense 2.4 Release, configured for PPPoE. There is no IPv6 address being assigned to my LAN interface.
@OmniouS, since I am now using a combination which hasn't worked for me in the past, could you please post your WAN settings (DHCP6 Client Configuration)?
Here are my current WAN settings:
Dial on Demand is optional. I found that the WAN connection wasn't coming up after a machine restart due to an incorrect service start order in some of the earlier betas
What I might do when I get home later tonight is clear out anything sensitive, and then share my entire config.
Can you share yours with me to see if it is a config issue, or something else?
Cheers
Thanks for that. My WAN settings were the same as yours, with the exception that Send IPv6 prefix hint was enabled. I have now disabled that, but see no change in behaviour.
I see this repeating in my DHCP logs, which suggests I'm not getting a response to my request for an address. I was previously seeing an error, but that may occur when I get a reply.
Oct 16 01:18:36
dhcp6c
28286
Sending Solicit
@IPv6pipe, now that I'm using PPPoE, and OmniouS confirmed this works for them, can you look in to this? My ticket was again closed (and reopened) over the weekend.
I cleared out VPN/LetsEncrypt/AutoConfigBackup/Certificate/IPSEC settings via the UI and was getting ready to share the config but a lot of the settings are still in the backup file.. I'll review and post later on. I might raise this on the forums as well
It would be interesting to see the config file. I'm able to reproduce the symptoms @SirHumphreyAppleby has been having on a pfSense box, on a line that works fine with IPv6 with an alternate router (one running TomatoUSB-Shibby).
@OmniouS / @IPv6pipe. I have compared OmniouS' configuration and my own, and there really are no differences to speak of.
My pfSense configuration still had references to SixXS (when I had IPv6 working with Bigpipe IPoE, it was using a clean install of OPNsense), so I restored factory defaults and set up the basic connection again. Aside from using VLAN tagging, different network cards, and IP ranges, everything that appears relevant, was identical to OmniouS' settings both before and after the reset.
As Bigpipe has now reproduced the problem, I don't think this is a configuration issue. Something clearly changed to break my connectivity when my connection speed was altered, so I think that should receive further investigation.
Although this is about my experience connecting an OPNsense box to IPv6 with ICONZ rather than BigPipe, it might help those who are struggling to connect to BigPipe (or any other ISP offering IPv6 over PPPoE) with a PFsense or derivative:
And since (a) this has been driving me nuts all weekend, (b) everything Google offered up to help was no use at all, and (c) I finally fixed the problem, I thought I'd share...
The problem was: I couldn't configure my OPNsense box to successfully pull down an IPv6 prefix delegation from my ISP over my PPPoE connection. So none of the devices on my network got a global IPv6 address, they couldn't route IPv6 packets out onto the Internet, etc.
I did all the stuff that Google tells you:
- Set "IPv6 Configuration Type" on the WAN interface to "DHCPv6"
- Tick "request only a IPv6 prefix" (which allegedly may or may not help, depending on what your ISP expects);
- Tick "Use IPv4 connectivity" (because PPPoE...)
But I still wasn't getting the PD. Messing around with the other Interface settings didn't help.
To cut a long and frustrating story short, it turns out that the firewall was blocking the DHCPv6 responses for from the ISP. The firewall log was showing traffic coming from ff02::1:2, with a proto type of "options", being blocked. FF02::1:2 is a "well known" IANA multicast address for DHCPv6.
So I set up an "allow" rule on the WAN interface; initially (and for diagnostic purposes only) allowing all IPv6 traffic in. And yet the firewall was *still* blocking the traffic. Just to add insult to injury, the log files were referencing the "allow" rule that I'd just put in as the reason for blocking it!!
Then, after much digging around, I found, hidden at the bottom of the "advanced" options for the firewall rule, a field named "State Type". By default, this is set to "keep type". It appears that "keep type" is a Bad Thing(tm) for this kind of traffic. I set it to "none", saved everything, rebooted the OPNsense box and IPv6 sprung fully to life.
Yaay!!!
(I went back and tightened up the allow rule, of course. It's now only allowing multicast traffic (ff00::/8) in.)
YMMV, of course. But somebody might find this helpful.
Has anyone got any experience with FortiGates on Bigpipe ipv6? This is my config:
LAN:
config ipv6
set ip6-allowaccess ping snmp
set ip6-send-adv enable
set ip6-manage-flag enable
set ip6-other-flag enable
config ip6-delegated-prefix-list
edit 1
set upstream-interface "wan1"
set autonomous-flag enable
set onlink-flag enable
set subnet 0:0:0:11::/64
next
end
end
WAN:
config ipv6
set ip6-mode pppoe
set ip6-allowaccess ping
set dhcp6-prefix-delegation enable
end
I'm not seeing any IPv6 Gateway IP on the Routing Monitor.
Hi,
Alls been going great till 3:30am December 12
IPv4 went away, but IPv6 was still working, though it took a while to learn that as all my DNS resolution was IPv4 dependent.
Since then I've had numerous emails and "try this" from Support and I'm puzzled why a trial which previously worked flawlessly is proving so difficult to restore.
My service has been blown back to CGNAT, public IPv4 restored, more than once.
At present I'm repeatedly reminded that IPoE/DHCP is a trial, yes, one I've been on since June 2016.
The IPv6 trial has been running fine since July 2017 with IPoE/DHCP IPv4, but won't run at present with PPPoE IPv4 (for me.)
Presently I obtain an IPv6 prefix, but the default route supplied appears like this on the MikroTik RB850Gx2:
0 address=fe80::e2ac:f1ff:fe88:b204 interface=ether1-gateway status="failed"
The default has been wrong in the past, replacing it with a static to fe80::e2ac:f1ff:fe88:a204 has worked, but not this time.
Any suggestions about what I might be able to do locally, or how I might describe the problem better to a clearly overloaded Support team ("At the moment our Customer Care team is helping with an extra-high volume of customer enquiries, and it’s taking a bit longer than usual to get to your email.") in order to restore the status quo as of 11 December?
|
![]() ![]() ![]() ![]() |