Open IPv6 Issues / questions

Hi Ben, please see my answers inline below:

Ben said:

- will the fix for issue NUTM-7187 be included with 9.5?

 [BL]: The fix for NUTM-7187 is not included in this current UTM 9.5 beta version. We are actively working on the fix right now though, so as soon as we have a confirmed fix it will be included in a subsequent release.

- is there a fix in the works for IPv6 Connections where the WAN Port is supposed to use an address out of the delegated prefix? Currently users of such ISPs do not get any IPv6 address. (for esxample KPN netherlands)

[BL]: This should be supported today, unless the ISP is doing both stateless & stateful. Is that the case for you? If so, we are fixing that as part of NUTM-7187 as well.

- what about the ability to change/edit the UID for IPv6 Delegation Requests?

[BL]: Unfortunately this isn't part of this 9.5 release.

- what about long standing feature requests such as 6tunnel integration, lets encrypt - is that on the roadmap? Users, myself included had high hopes for 9.5 but this seems to be more than a maintance release.

[BL]: Lets Encrypt is on our current roadmap, but it's mainly planned as a WAF feature. As for 6tunnel integration, it's currently not planned for any specific release.

 

thank you in advance.

 

Hi Bobby,

Normally the ISPs router will then request /48 prefix and use a /64 from that prefix for the wan interface and a /64for the lan interface. So there are no other global ipv6 addresses than the ones from that /48.

On the Sophos UTM, in my case I will only receive a link local IPv6 address via PPPoE. Using a tcpdump I have verified the UTM is not sending out a prefix request after the PPPoE has been established. Is it waiting for a advertised IPv6 address for the WAN interface first before it will do this? Because in this case it will never get it... And thus a IPv6 prefix will never be requested.

If you want to have a look at my Sophos VM, or need some tcpdumps of the PPPoE setup let me know!

Rene

Hi Rene,

   I really appreciate that you can give us some update wrt your default route issue.

   Is there anyway I can have access into tour UTM to debug with you?

   Thanks for your time and help.

Hi Ben,

   Thanks for your suggestion and I think I sort of understand it;

   But team decision is needed on this and I will pass it on.

   Your input is much appreciated. Thanks again.

Hi All,

Have not been following the thread for the last week. What is the current status?

As I can see there is an issue for SanderRutten that causes traffic to stop sometimes?

Did you manage to resolve the static route issue? Or is that just working now for you?

I think for me the only issue is the default route. I have not noticed any disruptions in traffic once I add the default myself. 

Regards,

René

Updated Summary:

SanderRutten System:

   This system has been working for almost 3 full days now without problem. We can see the DHCPv6 renew and traffics are flowing.

   Le: Still looking for explanation as to why it did not work prior to April 25, 2:00PM Vancouver Time.

Rklomp System:

   The default route is the issue. and it had been added by manual.

   Le: Manual adding default route is good for now. But we need to make it work without having adding the default route manually

   Rene:

       1) Can Le get into your system and debug without when the default route is missing? Thanks

       2) What is the static route issue? More info, please. Thanks.

Ben System:

   It had been reported this system is fine

@  SanderRutten

Updates wrt SanderRutten System

One potential cause of the ICMPv6 did not work prior to April 25 2:00PM Vancouver time is following:

The "pppoe" negotiation between the UTM and ISP somehow did not succeed, i.e. the UTM did not have an local link IPv6 address (LL) on the ppp0 interface;

Only from this LL, dhclient6 can ask for a PD. Since there was no LL, there was no PD. Hence no IPv6 traffics was possible due to DSP not giving a PD.

This scenario can be verified by various system log messages:

i)  dhclient6: no link-local Ipv6 address for ppp0

ii) dhclient6: send_packet6: Operation not permitted // even though the ip6table looks fine

Action: Even the system is working fine now for almost 3 full days. Le needs to reconnect (PPPoE) to watch the negotiation.

Are you (SanderRutten) OK with me to push the "button" to reconnect Interface on PPPoE? Thanks and please let me know ASAP.

Hi Le,

Sorry for the delayed reply, has been quite some busy days at work last few days so I haven't had time to capture my switch port yet. Do you still want me to do that?

And about reconnecting my connection: Go ahead! Even multiple times if needed.

Thanks a lot SanderRutten,

    Thanks for your help.

    No need to do mirroring.

    Since no PD, hence no traffics (outbound is OK, mirroring will show this. However, inbound is not since DSP does not know how to route).

Hi Le,

1) I will send you a private message with login details of the system. Go ahead and troubleshoot on it. You can initiate some reconnects if needed.

2) With the static route issue I meant the default route. So only one issue :)

- René

Nice! Thanks for tell us it.

Hi Rene,

   Thanks so much for your help and also for letting me debug the system.

   The reason for no default route on your system is that no router responds to the RS request on the ppp0 interface.

   The system (fe80::2a31:52ff:fe59:9fa6) on the other end of ppp0 connection does not respond at all to RS on ppp0. Also, it does not send out

   regular RA. So no default route for ppp0 is a reasonable thing.

   But this system (....:9fa6) serves as DHCPv6 server, i.e. it will dish out PD if request.

   UTM's behavior wrt to "no default route" is correct.

   Will update more tomorrow.

   Thanks Rene. Your help is much appreciated.

Edited: rdisc6, radvdump can be used to send out RS on ppp0 and see what happens. Thx.

Hi Rene,

   Thanks so much for your help and also for letting me debug the system.

   The reason for no default route on your system is that no router responds to the RS request on the ppp0 interface.

   The system (fe80::2a31:52ff:fe59:9fa6) on the other end of ppp0 connection does not respond at all to RS on ppp0. Also, it does not send out

   regular RA. So no default route for ppp0 is a reasonable thing.

   But this system (....:9fa6) serves as DHCPv6 server, i.e. it will dish out PD if request.

   UTM's behavior wrt to "no default route" is correct.

   Will update more tomorrow.

   Thanks Rene. Your help is much appreciated.

Edited: rdisc6, radvdump can be used to send out RS on ppp0 and see what happens. Thx.

Hi Le,

Thanks for the efforts troubleshooting. I indeed already noticed that there are no RAs in my situation. Even with the capture I made when using the ISPs supplied box it did not send any RAs

# rdisc6 ppp0
Soliciting ff02::2 (ff02::2) on ppp0...
Timed out.
Timed out.
Timed out.
No response.

OK and Thanks Rene.

Can I use your system for another day or two? Thanks.

Sure no problem.

Hi Le,

I see you have been rebooting my UTM a few times the last days and assume you are still working on the issue? Do you have any updates? Could you share with us what you are working on?

Regards,

René

Have 6 tunnel and native on UTM waiting for 6 tunnel and native on XG.

Native 6 is no longer a high priority because the progressive ISP was taken over by a regressive ISP.

But, when the NBN arrives I might change ISPs to one that assigns native 6 to home users.

Le has been quite busy yeah :)
Many many reboots later, I think that he completely solved my problems. IPv6 after a reconnect or reboot takes about a minute before it is working, after that everything is now okay.

Le is still monitoring my UTM and rebooting it a few times. Maybe some small adjustments or just to see if everything keeps working.

Le has been busy on a test sophos i provided. the nightly pppoe auto reconnect breaks ipv6 every time with the latest patch. he is investigating why that does happen.

two thumbs up, he wants to do a proper patch that fixes all problems and doesn't leave us with any bugs.

Hi All,

   Sorry for not updating the progress since I am busy finalizing all the changes, i.e. making sure it is really well done.

   Thanks for all of your help.

   Quick Summary:

   1) SanderRutten system: everything is good to go

   2) Rklomp system: Same as 1

   3) Ben system: There is one small issue that I just put another newer rpm on it to see if it can resolve this issue (RA is not automatically sent by router - this is the hypothesis: to be confirmed by the reconnect by 4:00AM Ben's time).

   Once Ben system is good to go, then at lease the issue of "reboot and reconnect" is fixed for PPPoE connection.

   Thanks and sorry about the delayed update.

looking good, ipv6 still up and working after last nights reboot.

thanks for the awesome work Le!

Great to hear that it is OK with Ben's system. And I also just checked it now. It looks good.

Thanks so much for all of you help. It would be almost impossible without your help.

You fellows (SanderRutten, Ben and Rene) are great to work with. It is much appreciated.