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 Ben,

Since the architecture for XG is fundamentally different than the UTM, these changes are not easily portable to XG, and will have to be worked on separately.

Please be assured though we are also working hard to improve the functionality on XG, it's just the fixes won't be a direct/easy port from UTM to XG.

Hi SanderRutten,

   Thanks a lot for allowing ssh into the UTM.

   Here is a quick summary:

   1) When I inherited the system from this morning, the ping6 to google.com did not work despite

        the facts all seemed to be fine with UTM.

        a) ip6table logging indicated that the ip6table passed all the ICMPv6 to the hardware interface

        b) The tcpdump indicated that it captured ICMPv6 on the hardware interface

        However there were never responses from google.com 

         UNTIL

    2) About 5 hours into debugging the system, i.e. verifying system thru:

        a) dmesg to see the ip6table logging of ICMPv6 traffic

        b) ip -6 route see the default route for PPPoE

        c) tcpdump -i eth1 for pppoe traffics

        d) tcpdump -i ppp0 for ICMPv6 traffics

        e) ps -elaf | egrep 'dhc|watch|ppp'

         They all indicated that the traffics were sent to the other end of PPPoE connection but there was no response,

         THEN out of no where, ping6 started to work like a charm. It has been going strong for over 1 hour now.

         I will let it go for a while and let you know when I am back tomorrow.

         Hence at this point, it is a puzzle while it started to work; everything from UTM seemed to indicate that it should

         work. So going forward, is there anyway can you confirm that the ICMPv6 packets do get on the wire, i.e.

         port mirroring on the upstream switch (if there is a switch between UTM and ISP) or somehow working with ISP to

         determine it; I just want to make sure that UTM sends out the ICMPv6 packet to eliminate upstream issue.

          That's all for now. Please let me know your comments, ideas or questions.

          Again, thanks so much for your help.

Hello Le,
Thanks again for looking into the problem!
Can try a port mirror, although I have never used it. (I'm not a standard home user but neither a network tech :P)

My network setup is: ISP > Switch Port1 > Switch Port2 > Sophos SG125w WAN port
I have setup a port mirror for port 2. When I'm home tonight I can hopefully capture with my laptop attached to the mirrored port and run wireshark.

I sure hope we will find something, but to be honest I doubt that we will find a cause here.
When I connect my OpenWRT router, IPv6 works. If I power on my OPNSense firewall, it also works. When testing PFSense for a short while, it also worked.

Hi SanderRutten,

   Thanks for your help.

   The ping6 testing is still going strong for almost 16 hours now. Every ping was fine (about 56000).

   I am in the same boat with you, i.e. I don't feel comfortable when things start not to work and start to work

   without any apparent reasons. So I am not letting up this issue. On my side, I am still looking for possible hypothesis

   as to why it does not work. I will update ASAP.

   Thanks for the port mirroring work. Good luck.

    Also, please let me know your thinking. It is appreciated. Thx.

Edit:

New additional info updated at 2:00PM Vancouver time and 10:00PM German Time:

1) The ping6 is going strong for full 24 hours now; sending out close to 80K pings without problem

2) At this time, the prefix renew was also successful for the same prefix after 12 hour renewal interval from 10:00AM to 10:00PM German time

So far so good.

Hi Le,

Little update on the 6rd: 

I was in touch with a fellow sophos community member. He is using "Deutsche Glasfaser" which offers IPv6 via 6rd.

We managed to get an IPv6 Address for the WAN Interface so far which is working fine. What does not work is getting a route for the Internal LAN Interfaces (but we didnt really try cause of time issue)

For the 6rd i think we can manage to establish that with a small script that calculates the own prefix via the CGN IPv4 and the Provider /32 IPv6 network. 

If an integration into the UTM Webadmin was to happen it would probably be required beeing able to enter the Provider IPv6 Prefix, 6rd IPv4 Gateway and Netmask into a GUI mask. Since the Kernel requirements and basic working is allready in, maybe it would be easier to considerate integrating this.

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.

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

Nice! Thanks for tell us it.