Open IPv6 Issues / questions

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

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

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

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

 

thank you in advance.

Parents
  • 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 looked into the capture file you provided and found that the box provided by your ISP directly sends out DHCPv6 solicit messages with IA_PD option, immediately after PPP IPV6CP is successful. The box provided by your ISP is probably configured to always use DHCPv6 IA_PD when connecting to the server.

    On the other hand, the Sophos UTM has a need to first do IPv6 Neighbor Discovery to understand if the server (ISP end) supports SLAAC or stateless/stateful DHCPv6. Based on the RA and prefix flags it receives from the server during IPv6 ND, it would then setup the dhclient6 appropriately to use SLAAC or DHCPv6 or both.

    In the absence of ICMPv6 RAs, the current code doesn’t initiate stateful autoconfiguration by default. We will look into addressing this issue asap as a bug fix in a future release.

    -Prakash

  • Thank Prakash. Really appreciate the response on the forum!

    In this case no Neighbor Discovery is possible. I tried it, but no response from the ISP network. So best would be a statefull autoconfig as fallback when no RAs are received.

     

    Thanks again! Can you keep me updated on the bug report?

     

    Regards,

    René

  • i realize there was easter holidays, but is there any ETA on the fix of the lost prefix? i am delaying a setup right now that would need it and thus trying to work a time table. Thank you in advance.

    ---

    Sophos UTM 9.3 Certified Engineer

  • Hi Ben,

    A "potential" fix should be available before EOD today (PST). Hope it works well this time... let us know how it goes.

    -Prakash

  • thanks for the swift reply Prakash

    Please feel free to install it on the sophos with the open ticket anytime. ill than copy it to my test machine aswell and report back here on both.

    ---

    Sophos UTM 9.3 Certified Engineer

  • I have installed the fix (/root/fix-2.1/ep-ipv6-watchdog-9.40-2.gce849c7.i686.rpm) on the UTM.

    The ppp0 interface did get the prefix correctly.  Let us keep monitoring the behavior now...

    Thanks,

    Prakash

     

  • Hi Prakash,

    Does this new version also solve my issue?

    Regards,
    René

  • OK good news; the patch seems to fix the rebind/renew and the IPv6 prefix is responding again

    bad news: the prefix changes on every reconnect, it seems to ignore DUID or generates a new one (speculation at this point) each time it connects.

    Before this version the prefix always stayed the same (and also does with other routes connected) so this must be some side effect of the fix.

     

    Edit: ok i made 2 wireshark dumps, with the old patch and the new patch, here are the differences:

    old patch on pppoe reconnect:

    solicit, advertise going on for the WAN Interface (solicit is without prefix delegation!), than a REBIND happens for the OLD Prefix, Cisco ISP Router replys and confirms the old prefix!

    new patch on pppoe reconnect:

    solicit, advertise happened (with prefix delegation!), it seems the cisco isp router than proposes a NEW prefix, Sophos sends a REQUEST with the new proposed prefix. sophos never tries to rebind on the old prefix.

    remarks: this only happens on interface reconnect, when just applying the patch and restarting the ipv6 watchguard the old prefix is beeing used. The new patch seems to just request a new prefix through the solicit without trying to "get" the old one. When applying back the old patch and restarting the ipv6 watchguard the prefix won't change.

    i have put these two pcap (one with the old patch 1.x, one with the current patch 2.1) on the sophos with the ticket in /home/login/pcap-testmachine1/ .. these are pcaps from my testmachine since i dont want to bring the connection on the other machine up and down as much.

    ---

    Sophos UTM 9.3 Certified Engineer

  • Hi Ben,

    I guess I know what could be causing the prefix to change on every reconnect.

    I have copied another fix to you UTM (/root/fix-2.2/ep-ipv6-watchdog-9.40-4.gce64053.i686.rpm) which might solve this problem. Please install it and let me know how it goes.

    Thanks,

    Prakash

  • Hi René,

    Please get the latest fix (/root/fix-2.2/ep-ipv6-watchdog-9.40-4.gce64053.i686.rpm) from Ben.

    It has the fix for your issue too. Let me know if it works for you.

     

    In any case, please collect the ipv6.log and system.log files from /var/log and also provide packet captures if possible.

     

    Thanks,

    Prakash

Reply Children
  • Hi Prakash,

    Good and bad news...

    The good news is, I am now getting an IPv6 prefix! YAAY

    The bad news. IPv6 traffic is not working yet :( 
    In the interfaces overview I am not seeing my link local address anymore on the pppoe wan interface. This was shown before.

    Log still shows I get it, but ifconfig does not show this local LL address.  
    2017:04:19-19:41:55 gateway pppd-pppoe[27608]: local LL address fe80::3567:15be:c320:d03e
    2017:04:19-19:41:55 gateway pppd-pppoe[27608]: remote LL address fe80::2a31:52ff:fe59:9fa6

    I am also missing an IPv6 default route.

    -- UPDATE
    After reverting to the previous version I see the ipv6 LL address again in the interfaces overview, but it does not show up in ifconfig.

    Using both versions I am able to ping the remote LL
    # ping6 -I ppp0 fe80::2a31:52ff:fe59:9fa6
    PING fe80::2a31:52ff:fe59:9fa6(fe80::2a31:52ff:fe59:9fa6) from fe80::8445:1d69:66c2:b895 ppp0: 56 data bytes
    64 bytes from fe80::2a31:52ff:fe59:9fa6: icmp_seq=1 ttl=64 time=1.14 ms
    64 bytes from fe80::2a31:52ff:fe59:9fa6: icmp_seq=2 ttl=64 time=1.08 ms

     

    -- UPDATE2

    After setting a default route connectivity works! :D
    # route add -A inet6 default gw fe80::2a31:52ff:fe59:9fa6 dev ppp0

    I also noticed the "Internet IPv6" network object is not bound to any interface.


    René

  • Hi René,

    Thanks for spending time verifying the fix and for your inputs.

     

    FYI... A few other modules underwent IPv6 related fixes and code restructuring for 9.5 Beta (not just the ipv6_watchdog).

    The problems you are seeing could be because of certain missing interdependencies (assuming you installed the latest 9.411 ipv6_watchdog fix over 9.5Beta).

     

    If this is not the case, I will need to take a look at the packet capture (just before and after the pppoe interface is enabled) and also the logs from /var/log  to understand the problem in more detail. Would it be possible for you to provide us the same (via Sophos support maybe)?

    However, it could be about a week or so before I can actually work on a fix again (sorry about that..)

     

    Regards,

    Prakash

  • i will test the patch with the 9.5 beta soon (tm), will report back on that also.

     

    edit: test with 9.5 Beta, looking good so far.

    ---

    Sophos UTM 9.3 Certified Engineer

  • Hi Prakash,

    When referring to previous version in my last post I mean the previous patched persion. That showed the LL address, so i think it should work correclty in 9.5.

    Regarding the missing default route. How is this generated in the watchdog script? Is it using the address of the RAs? In this case we don't have those and the default should point to the remote link local received via pppoe.

    Thank you for all the work so far! If you are able to fix the default route creation I think my IPv6 is fully working! :)

    Let me know if you still need some captures.

    René